在程序C ++中更改包含/目标文件

Question

Me and some buddies are trying to construct a game engine that can run multiple games in c++. The games are similar enough that they all share similar mechanics and interfaces that I want to make some files that apply to each game. Many of the source files will be the same like our GUI's or Game Engine files. However, some files that deal with individual game mechanics will change from game to game. If this expands to a large library, I don't want to simply include every file from every library to play one game. I also don't want to have a duplicate of GUI and game engine files in every folder in the library.

I am currently thinking about the idea of a launcher that will change the #include tags to match the choice made by the launcher, although this may require recompiling. Is there a way to make this/ is it a good technique, or is their a better way. (keep in mind i'd prefer int main to remain in game engine/ a shared file, and not make a main for each game)

Answer 1

Summarizing your requirements:

• You have some game engine code that is sufficiently general to be shared between several different games;
• However the engine depends also on some game specific code that is specific to each game;
• You currently solve this, hardwiring the game specific behavior at compile time;
• You'd like a solution where it would be easier to share the game engine between different games, for example to bundle several games an let the user chose at startup (through a launcher).

If this is correct, here some thoughts to help you further:

• There's no way to elegantly change compile time elements (the includes) at run time.
• Building a launcher that accesses all the source code to recompile on the flow seems not to be a valid solution (because the user would need to have a compiling environment preinstalled, with all the libraries, dependencies, and toolchains installed, and anyway, it would take too long to launch the game).
• The right approach would then to make more use of polymorphism , and refactor your game engine to rely on encapsulated game specific objects (using a clear interface, and keeping the coupling as low as possible, for example using SOLID design).
• Once such degree of polymorphism is achieved, you can at game startup injecting game specific elements into the engine (for example an abstract game factory that would let the engine initiate families of related game objects without having to know the game specifics). Up to you to chose whether having a separate main for each game (compile time choice of game), or leaving the user choose between several ones at startup (run time choice).
• Alternatively, you could also architect your system around a clear API between the game engine, and a dynamic library (eg DLL under windows), that is dynamically loaded at run-time (and which could then load newly delivered games, packaged as DLL+game assets, and added to the already installed games when needed. ( John recommended this nice link in the comments, there's also this one , and certainly a couple of others. But be aware that this is a level of additional difficulty that needs to understand very well the limitations of DLL - so maybe keep this as a later step for your refactoring)