Sorry your browser is not supported!

i sometimes have a bit of an argument over how to begin to write the code for a program. after knowing what i want to make i always start on paper... i first write down what sections i will divide it into - gosubs, functions, general code etc. i then decide on what images i will need. and then i start to write the code ON PAPER. i always thought this was the best way to do it but i couldnt explain why. im just wondering who agrees with me and who dissagrees
Naf

sometimes a snippet can become an idea.

sometimes a snippet becomes a game.

If a snippet grows and got out of control,
Id use paper.

its almost like "what came first the chicken or the egg".

usually what i do is write down a rough outline and figure out which is the most important part.

So say i'm working on an fps, best to start with making movement - then worlds - collision - adding enemy generic code and then finally all the fancy graphics

find its the easiest way to keep ahead of the bugs that can arrise

I use paper but usually to write down new ideas or important data.

Normally, I'll start with the main loop and write my gosubs and functions as I need them.

I don't use paper very much at all, except for working out some angle formulae or something, or drawing maps. I tend to start by making an engine using matrices and cubes, getting the controls working is the first step. Then I add stuff (media, ai etc.) to it until I'm bored and start something else, or I don't have the media file I want, then I'm stuck.

When it comes to design, there's a lot to be said for paper. Just is so much better to have everything laid out around you, all at one time, which doesn't really happen on a computer (unless you have like dozens of PC's in one place I suppose... ish).

On the other hand, apart from general ideas etc. I normally just dive in. Designing pseudo-code, structure diagrams, etc etc. has always just got in the way, and apart from large projects, with multiple programmers, I've never really found this level of design to be advantageous (ie. I might as well program the routines rather than writing them down in a diagram-pseudocode). Interestingly this has always been the method the company I work for uses. Essentially the charge a bomb anyhows, so keeping the design to a minimum is a good thing. Apart from a general specification (including screen layouts) we don't get any deeper. Even with a 7000 program system there is never many problems.

My 2p.

Cheers

=============================================
Quote:

"sometimes a snippet can become an idea.

sometimes a snippet becomes a game."
=============================================

Thats actually what I did for my mini-game im working on, it was actually just me getting tired of not working on DB for awhile and then just wanting to come up with something. It actually started as a text battle engine..then I started going..hey, ill throw in some features here, few pics here, hehe..then it turned into something "bigger", lol.

Hi All!

The answer to this is unfortunatly alot harder than you think, even for the most Imaginative of us all!

First when you want to write a program thats of any signifigant size Never just start writing the program! there is much to do first! Here is the step by step!
1: Think of the program you want to write - what do you want it to do?
2: Start a list of things you need for the program!
3: Think of how many people you will need for the project
4: Estamate how long it will take you to make
5: Assemble all the things and people you need to acomplish your project
6: Oginize all the things you have
7: Make as many flow charts of your program as posible and start naming your main variables, in the program, in the flow chart
8: begin psudocoding!
9: start your first draft at the program
10: test program
11: rewright program
12: perform a desk check (which is basicaly when you test the program exept this time your goal is to do your best to make the program fail! try to find buggs do wild things that might not even ever occur and try and make the program fail!)
13: perform a Beta test
14: compare the results of the Beta test to the results of to the un Beta tested version
15: Once you do 14 enough so that you can't find a problem you are ready to release your program
16: now last you must be ready to fix any bugs that may arise from your released copies
And That is it!
But most of all you must find your own stile of production you will have to do what I said but in what order and to what extent is your choice!