I view programming as a tool, and am not interested in it for its own sake. A lot of people get hung up on being evangelists about certain styles. There are always tradeoffs, and if you’re the only programmer on a team you better value time-to-implement and ease-of-understanding-for-you over most anything else. That being said, reusability is still important as you hope to be lucky enough to make more than one game.
The runtime stuff is being written in C++. I’m not sure if there’s a “best” way to organize code when making a game. I found it nice to break out stuff as follows (each a library except for the executable):
- Core - Platform-independent stuff (vector/matrix and file/memory parsers, some macros to ease memory allocation/de-allocation), and interfaces for stuff that will be platform specific.
- Platform specific – provides concrete implementations to stuff like audio, input, windowing, error handling, timer. It adheres to the interfaces laid out in Core. The name of this library contains the platform (for example MS_Windows).
- Game engine – game-independent and platform-independent framework (entities, messaging, collision, animation, scenery, spawners, path-following, simple scripting, lighting, triggers, asset management, camera (and other generic entities and some AI helpers).
- Game – game specific code
- Executable – small as possible
- Core – depends on nothing
- Platform specific – depends on Core
- Game engine – depends on Core
- Game – depends on Game engine and Core
- Executable – depends on everything, but care is made to have the least amount of code here as possible.
Everything other than “Game” and “Executable” are meant to be reused from game to game.
Coming soon, why I think smart pointers are dumb.