programming approach...

do you guys usually do a top-down approach or a ground-up? i know it's a matter of circumstance... but for example, making a video game... (which we are doing, soon's Anal Sure! gets us going... :)) aran wants it top-down (he throws me ideas in generalisms...) but i want ground-up (i keep bugging him saying... gimme the tile sets and i'll start already!!!)...

okay, that aside... what do you all think? thank you very much! i know many of you have a lot of experience with this sort of thing... and i believe a discussion on the subject is due time! :p

With my only experience with a sizable project (gravity sim for programming contest), I started with a bottom up approach. I coded the vector3 class, then the particle class, and tested it by using the earth/sun and outputting coordinates of both after a year, to see if they were in relatively the same spot. It worked nice.

I then proceeded to write a nice generalized 3d camera class, used the vector class a bit, and got that working nicely as well.

However, 3 days before the contest started, I had to just hack it through top down to get it running. For those 3 days, I had about 8 hours of school, followed by 6-8 at home hacking the project together. During this time I was really "productive", getting a lot more done in that 20 hours than I had in any previous 20 in coding the project. It did ok, placed in the contest and earned me enough money for a new processor/motherboard/ram combo ;).

However, having gone back and "ported" the program from MSVC to Dev C++ (it's suprising how much I needed to change... damn nonstandard for loops all over :( ), the code that was written bottom up was much better written.

I now plan on going and adding some more features to it, and honestly, the top down hacked crap is almost worthless. I am going to get rid of most of it and replace it with a more elegant code.

Bottom line, go bottom up unless you absolutely need something done really quickly. Code written bottom down tends to be very hard to extend as well as debug (after you've let it sit for awhile).

my development startegy:

Firstly: gather all of the information you'll need for the project and put it into a doc or xls or something so you can easily access it, therefor you make the framework of the project.

2: Look at the framework and decide what programming elements and solutions will be used/are neccessary to do waht you want to do.

3: Write the basics of the project (classes and the basic functions and whatnot)

4: Use those basics to construct test programs that make sure that all of your ideas can fit together and fit together well.

5: write the code based on everything else you've done.

i'm tired, so if some of that doesn't make sense you can blame it on the fact that i've been awake too long..... :o

There are some books on application development. They describe different methodologies that you can use, mostly for business applications. Top down design is also known as waterfall methodology. The stages are panning, analysis, design and than implimentation (P-A-D-I). Each stage is significant for example planning will define your strategy, goals, time it will take to complete the project, etc. Analysis involves using modeling lanuages to describe the inputs, processes, and outputs. You could use an object oriented approach for this. Design and implimentation, well I'm not too sure yet!

With a game you might want to get user input at certain stages. There are desgn strategies such as rapid application development (RAD) using prototypes that allow you to show users the interface without details. It help you make decisions without completely commiting to the interface. RAD cycles through the design phases such as (P -A-D-I -A-D-I -A-D-I)
example (planning is done once only but the other stages are cycled though):
Planning -Analysis -Design -Implimentation (version 1)(user input)
-Analysis -Design -Implimentation (version 2)(user input)
-Analysis -Design -Implimentation (version 3)(Done)

You should break the projects into tasks and figure out how long each task will take and that way you can assign people to work on different tasks at the same time. You can figure out how much slack time you will have to complete certain tasks as well as determining your critical path.

hehe, in other words... compile it, test it, change it... compile it, test it, change it... and so far as setting up milestones and so forth, i would but fact is i program for fun and unless i could see myself having fun to a schedule, i can't see myself having a board of milestones... that, and i have certain vindictions about mixing my code with, for example... allegro... (in my own VESA-ing, i had a text setup, which i cannot easily implement with allegro's own devices... and if i put a wrapper to support my old text setup, that seems very hackish!) well... thanks all... i would have thought i would have gotten more of a response... but ah well... :p

One good thing to do during the analysis phase, before you start to code, depict the flow of data. Figure out all the data stores such as files that are created and used by processes and how the data will flow through the program. You can break processes up into child processes but the flow of data has to be maintained so that you can actually figure out all the objects and information that you will need before you write any code.

Often people need a schedule or else they never finish their projects. A game is a professional project and it might be better to research program design rather than write anything because in the real world companies have discovered that this is necessary. Why not aim for a professional game?

Also compile, test, change, no, no, system design involves much more, infact I explained it very poorly.