So, I’ve got the main bit of my game done. That’s the logic, collisions; everything needed for it to function, engine wise.
I never anticipated that the rest of it would be a nightmare, i.e. Hiscore table, lives, restarting levels, saving progress etc.
Networking; My God!
User Interface; Flaming Nora!
Not enough coffee.
So, it’s either I abandon the project when the guts of it are done, hang my head in shame and call it a day; never to learn if I could finish it, or, grit my teeth, steam in, set workable goals to destroy the mental fatigue elicited by the boredom of the mediocre coding that is left, release it and then be happy; whether it makes money or not.
I’m going to go for the latter. It pains me to think of it but hiding from it will do me no good.
What I have been learning the past few months for architecture is that – it’s better to make clear cuts on the codebase early on and call them “subprograms” or “modules” or “libraries” and let them do their own thing have their own state.
One great example is comes from using a physics engine (BEPU/chipmunk/box2d) where there is the World and you add Bodies. And therefore you can update the World (which updates all the Bodies) or having a reference to a Body you would control it (move it around etc). This you can call it a library. Another example is with the Audio engine contraption. Where you load a bunch of sounds in a list and then you simply call the play sound method. This you can call it a module.
This approach is the “modular” approach which means is exactly what you would do in C where there are no classes etc. On the other hand if you go with an Object Oriented approach you code will be an endless composite fractal which might give you confusion. So by expanding upon this idea you can simply let each subsystem do it’s own thing without mixing them all together.
P.S. After studying the Doom 2 source code and other lots of C games – I have gradually reduced my OOP to exactly only where is essential.