Hi All,

I am writing a new game engine / game based on a previous project I have which does a few basic game 'things' (such as loads a map, player can move, enemies shoot at the player).

Now for my new project typically I would open up Visual Studio, go to source file, add new .cpp file, call it winmain, copy the winmain from the old 'working' project over (which is pretty much this template from the microsoft MSDN). Now winmain pretty much just creates a game object, init()'s it, then gets into its run() loop.

So then I will copy game.cpp and game.h over, because at this Game class level most things are the same, as in a fixed time step, Game::update(), Game::render(). But then I will have to start deleting things in the game specific areas such as Game::CreateSystems()...

Is this an okay way to go about things? It feels a bit messy because now I have e.g. 3 winmain.cpp's in different folders (m e.g. C:\C++\Game1, C:\C++\Game2, C:\C++\Game3 to which I may have done slightly different things for the different games)...

I am trying to learn good habits of modularity and refining files until I am happy with them and can slot them in and out as I please (I understand there will be a limit to this depending on the game...)

I would ideally (wayyy down the track), like to have everything pretty modular that could be loaded into any game I make (any that uses the same soft of style e.g. just sprite based 2D for now). So for instance I would like to be able to load in a base AI and Pathfinding class that can be built upon in game for my game specific requirements.

Comments and thoughts are appreciated. Thanks

In itself is copying a file a perfect way to copy functionality to a project. The simplicity of copying is however paid by difficulties in applying code improvements or bug fixes over all copies. On the other hand, if you have a single winmain file and you share it, then making unique changes for one game in it is more complicated.

The question you have to ask yourself is thus how often do you do each of these things, or, is it important that you can easily do one or more of these things.

A second consideration for games is, do you care about the old code? If you published Game1, then all bugs in it are also published. You can consider those bugs to be part of the game (unexpected extras), or you can consider those to be bugs that need to be eliminated. In the former case, game code is basically fixed after publishing, which means you never have to hunt down all copies for fixing or improving.

I think a way to make things more modular is to be more explicit in what code is generic and what code is specific. It could be as simple as naming anything generic as Generic (eg GenericPathFinder), or put it in different files, or in different directories, up to making a new project that you add as library dependency.

The tricky part here is to choose "generic" correctly. The more you divide generic and specific, the harder it becomes to make custom changes in "generic". Build escape routes like allowing derived classes, or adding additional hooks.

The larger the code of "generic" becomes and the older it is, the more need you'll have for some form of documentation. The entire point is that you don't want to spend time on the generic part (right?). In time, that means you will forget all the little details, and additional hooks etc of it. You become a user of your own code, much like you are a user of any other library that you use.