I have written a few small hobby-ish games in SDL and SFML, but I haven't really spent much time on thinking about the design. It was all just for ........s and giggles.
I've began writing a simple 2D tile engine in C++, and I've been using a source from gpwiki that is unfortunately incomplete. I don't want to look at an example and basically write that exact code anyway, so it was good in a way that I got to fill the holes, as that is the only way to learn(To design and implement yourself).
I have a few classes:
Entity - contains members for position, velocity, image, sprite and so on. It also does some work like loading the aforementioned stuff from XML files and so on.
It has a render member function as well(Takes a surface).
UnitManager - manages units. Loads the the units.xml file, and creates as many units as there are in that file and passes them the file for that unit, which is an attribute of the unit XML elements.
TileManager - basically the same stuff as above, just for tiles. Loads and renders tiles.
Engine - The engine itself. It contains a UnitManager and a TileManager.
There are a few more classes, but they are, I think, beside the point. All classes, however, derive from a BaseEntity because they all need to have a render, load and think function.
What I have come to you gurus for, is design advice. As a novice game programmer, it's way too easy for me to jump outside the proper design and add functionality because I needed it then and there - but then I end up with strange, inconsistent design. I'm trying to avoid just that.
Example: I find out whilst implementing the design at some point, that I need to access a certain unit in a certain class' member function. The player unit or something.
It just so happens that class does not have anything to do with the units, but because there is no other way to solve my problem, I'll have to either rethink my design or add strange functionality to allow some class access to the pointer to my player unit.
The main points I am wondering about are:
- How do I do the game logic? Do I create a Game class and derive from that? What does the game class contain? How does it interact with the engine, and where does it in general come into play? Does the engine do the input or the game class? How do I interact with my player unit? Should it just a pointer to one of the units in the UnitManager's vector of units, but apart from that, not a special unit with its own class?
- Should I be creating special classes for all new units? In most cases, a unit would just differ from another unit by texture and so on. But do I have to subclass for each unit? Would that be a good idea in case I have to do extra functionality that a standard unit doesn't have?
- This is perhaps a bit of a repetition from the first question, but: If I have a game class and an Engine class, how do they interact? How do I initialize stuff?
I'm sorry if it's messy and incoherent, but this is really blowing my mind. I really, really don't want to start writing this and then end up with a messy engine and classes that need to violate design boundaries to work properly. My head is spinning from all this thinking, heh. It's like trying to wrestle a 3D tetris puzzle with 10 blocks a time - how does it all fit together in the best way?
I thank you in advance for all and any input on this matter. It is definitely not my strong point, and I know we have some avid game programmers on this site.
