gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Beginners > Code design

#83900 - xproductions - Fri May 19, 2006 1:22 pm

I'm not sure what I'm doing could be called. A few weeks ago, I tried making a simple Pong game and jump right into coding. This was extremely painful, I'd constantly reorder the code, etc. For my next project, I am considering "code design" methods (note difference from "game design"). I'm not sure which method would be best for a small game.

How do you work on your game?
_________________
If you would not be forgotten
as soon as you are dead and rotten,
either write things worth reading
or do things worth writing.

-- Benjamin Franklin

#83922 - poslundc - Fri May 19, 2006 6:06 pm

First off: read up on finite state machines.

Now, here's the deal: you treat your game as a finite state machine that changes state every cycle of VDraw/VBlank.

So you want a main loop that cycles once for every passage of VDraw and VBlank, and during those phases runs tasks specific to one or the other.

Those tasks will include getting input from the player, processing the input and applying it to the current state of the game in order to generate a new state, and then updating the screen to reflect those changes.

State-based solutions to games are the easiest I've seen to both understand and maintain.

Dan.

#83926 - xproductions - Fri May 19, 2006 7:05 pm

By code design methods I meant stuff like flowcharts, UML, p-code, etc.
_________________
If you would not be forgotten
as soon as you are dead and rotten,
either write things worth reading
or do things worth writing.

-- Benjamin Franklin

#83941 - keldon - Fri May 19, 2006 8:33 pm

There is more to designing than UML diagrams and flow charts. There are what is known as design patterns aswell, and the analysis stage too.

On top of that I think it is important to know about algorithms, OOP, FSA's (like postlunc stated) and data structures first.

#83946 - sajiimori - Fri May 19, 2006 9:26 pm

Flowcharts, UML, and p-charts are not design methods in themselves -- they're ways to write down designs. Actually coming up with designs is the hard part.

Pretty much any technique you use will involve breaking the program into its major components, and then breaking down those components, until the pieces are small enough that you feel confident to jump right in and write them.

Refactoring existing code is a healthy practice that will help you predict what kinds of things tend to work. No pain, no gain. :)

#84005 - sgeos - Sat May 20, 2006 4:24 am

You learn by doing. Make a few game/programs. The architecture of the first ones you put together will completely suck. If you take the time to figure out what went wrong, you'll get better.

-Brendan

#84044 - keldon - Sat May 20, 2006 9:12 am

sgeos wrote:
You learn by doing. Make a few game/programs. The architecture of the first ones you put together will completely suck. If you take the time to figure out what went wrong, you'll get better.

-Brendan


Some people learn by doing, some by reflection, some by theory and some by practicality. Often by one followed by the other.

#84264 - SevenString - Sun May 21, 2006 6:29 pm

I always start with a game design doc (not a code design doc), then i do a tech-spec from that. The tech spec says what the engine and tools need to do, along with how the code will be organized. Also, I often put pseudo-code in the spec to rough out areas of the code that might be tricky.

Once I have a reasonable tech spec, I then start work on the headers for each "module" in the code. The bulk of my code design revolves around the methods, objects, and data structures defined in the headers.

From there, a lot of the actual coding becomes "filling in the blanks".
_________________
"Artificial Intelligence is no match for natural stupidity."