Game Structure

Almost every project I begin ends horribly. Usually my code becomes complicated to the point where I have to hack things in to add functionality, and it takes all the fun out of programming.

Put simply, I'm terrible at structuring my games and making them modular.

Any advice? Articles? Tutorials?

Also, a description of how you set up your games would be neat, too.

Plan first, program second.

kinda like what i kept on (but eventually gave up on) saying to this guy i unfortunatly know with writing

he pipped up once
"im going to write a screen play"
"whats it about?"
"i dont know yet"
"without some idea of the story your just going to be putting random words into random peoples mouths in random settings"

hell a single a4 plot line would suffice
start - conflict/resolution loop - goal
then knowing what was to follow, bridge collapse, whirlwind romance, bank robbery he could stand a better chance
and a bit of character design never hurts

but no in the end he had the intro mapped in his head of this family with every minute detail leaving a house getting in a car and eventually getting on a plane or ferry as the credits roll and a specific song plays over it all

and that was all he had

He doesn't write for Eastenders, does he?

lol tbh i dont think he could write a post card

Planning may solve things, there's however 1 major problem: he's the one who comes up with the game concepts, and he's the coder of them. The problem is that it's *so* incredibly tempting to think of a new feature during development, a feature you didn't think of at forehand, because the possibility of such a feature is only a result of seeing new possibilities during the programming of the planned features. In that situation you can do 2 things: stick to the plan (and swallow all your frustrations of not being able to expand), or gradually add things as the ideas pop up during development. The latter may work, but only if you have a well thought-out program base that allows for easy expansion. This is tough tho..

The problem of adding things is esp. relevant when you are creating a creative tool (e.g. a drawing tool or something). By working with the planned functionality you see patterns and you may wish to add a dedicated new feature that replaces those. In the end, your functionality becomes like a tree: you start simple but you end up with tiny twigs and leaves.

<setup all functions/globals whatever used in all levels>
<initialize stuff>
<Load stuff for specific level>
<begin main loop>
<update your animations stuff>
<update your AI logic>
<update your VFX/particle, billboards,reflections, whatever/>
<update your player controls/menu commands>
<update your HUD stuff/health bar, points, whatever/>
<update your Checkpoint system/save system>
<update stuff I missed to include>
<Render stuff>
<end of main loop>

http://www.gamasutra.com/features/20050414/rouwe_01.shtml

I have the same problems as Torrente.

Check out my Dax Robot game in the showcase. It comes with Source. It's just one big mess and it suprises me that it even compiles and works. :)

The best thing I can say to you is to power through it and try and hack it all together. Try to avoid rewriting it and leave the stuff you've learnt for a second version or "My Game 2" sort of thing. If I make a Dax Robot 2 I certainly wont be coding it the same way I did the first one.

you could rewrite it
but more just make the code more understandable re-edit than start from scratch with this is what i did this is how im going to do it

just keep the old code for reference and check off whats been redone

but if no one ever needs to see your souce code and it compiles whos to care if all your handles are pr0n star names and menu's from chineese takeaways

thats what ive done with my driving game as i had a good idea what i wanted to do and had a plan it was only when i had to change things to get feature to work that it got complicated. As some of the problems where unforseen I had to change large chunks of code. i found rewriting the code very quick as i knew exactly where i could stream line things, plus i had the chance to make it more expandable with the option of a track editor at a later point. I still feel that the first version was a valuble learning process.

Planning. All is said. I also found yet again that starting on something that is not first in full detail on paper will get you stuck at some point, demotivate you when you have trash tons of code, and kill you if... neh.. it wont get that dramaticly would it?

Tutorial - How to be a game developer as quick as possible

1. Write a simple game based on someone else's idea.

2. Write a slightly harder game also based on someone else's idea.

3. Write a game with your own ideas.

4. Repeat step 3.

learn from someone elses mistakes as much as your own ;)

if tatio bloke didnt think "wouldnt it be nice if the bricks in break out shot back" we wouldnt have space invaders

pong > break out > space invaders

pac man > gauntlet > bards tale > dungeon master > captive etc
pac man > gauntlet > wolfenstien > doom > every fps known to man

ok other games came before wolfenstien but its the ones that caught the momentum and are best remembered
eg if doom sucked would we be in fps saturation?
and without sf2 would we be left with double dragon-esque walk n fight em ups?

I hope this can clear a little bit more:
http://www.moraldigames.com/Temp/GameStructure.pdf

Well, my personal advice would be, appart for planing everything, don't hesitate to rewrite the whole game if needed (it doesn't take as much time as the first time). Structured programing is always worse at scalability than OO programing.

GameStructure.pdf : where's 4? You have two 3s. Surely the second 3 should be a 4?

markcw: yes you have right the second 3 is 4. sorry. I will change it ASAP

Thanks for the replies, everyone!

I think the common idea that I see here is to plan ahead, which I will definitely try. I must admit, I hardly ever plan. I just sit down with a vague idea of a game, and go from there. I don't think I'd like programming a game if I couldn't add new features when I think of them.

Orca: That's a neat article.. seems confusing though, and perhaps even overkill for a small project. I'll have to look into the model-view-controller architecture a bit more.

Interest PDF there, Moraldi. Isn't that *too* simple, though? Also, how does that translate into code?

One major problem I have is handling different "states." For instance, the Main Menu, Game, Paused Game, High Score Table, Game Over, etc...

Also, should I render all of the objects at the same time? Currently, I have each object inherit from a base object with a Draw() method. Then, for each type, I call Type.UpdateAll(), which loops through each instance of that type (contained in a global list in the type), updates its position, checks for collisions, and then calls Draw(). Is this the wrong way to go about it?

A few more things: Say I need to check for collisions between two types, of which there are a lot of instances. Where do I put this code? In a collision() method of the first type? In a collision() method of the second type?

Both collide, so both react, so both instance types of your game characters use their own collide code. Each reacts in a different way, different explosions, different HP loss, different 'being hit' animation etc.

Well for me, if there's anything ugly in my code that I don't really like then it's probably not and should be rewritten. It's called revising.