Flexible use of game libraries
When developing a new game, the first thing you should consider is your high level game architecture. You’re probably going to use some 3rd party libraries, maybe you already have some in-house libraries that you’re going to use, or develop them for future use. How these things fit together seems obvious, but when you consider following architecture, it will save you a lot of time and frustration later on.
The high level architecture that I’ve developed over the years has 3 layers:
________________________ | | | Core Game | |________________________| | ___________V____________ | | | In-house Game Library | |________________________| | ___________V____________ | | | 3rd party libraries | | - Sound | | - Graphics | | - GUI | | - ... | |________________________|
The Core Game only contains code specific to the game. Try to move as much generic code to your in-house game library, this way you can reuse it when you’re working on other games.
The in-house game library contains on one hand the generic code that can be shared between multiple games, and on the other hand acts as a facade on top of 3rd party libraries. This means that the core game never calls the 3rd party libraries directly, but always passes through your in-house game library.
Since your core game is only using your own inhouse game library, you have total control over the API that it calls. Switching 3rd party libraries or custom made has no impact on the game code. You can also extend the external libraries with some functionality that you can write on top of them. When interface changes are made in newer 3rd party libraries, you don’t have to find/replace in your game code, adapting the in-house game library is enough. Porting multiple games also becomes easier, because once your in-house game library is ported, no major adaptions are needed in the core games.