Sharing code between multiple MonoGame projects - Best practices

Hi all,

I just wanted to know what advice do you have for organizing reusable code between MonoGame projects? I mean I guess everybody has his own code base with little helper methods, maybe C# extensions for the MonoGame classes and maybe input controllers and little (or big) frameworks and so forth. How do you manage this code to be able to use it between different MonoGame projects and hopefully future projects while still being able to continue developing this reusable framework code base as needed without breaking older MonoGame projects due to this reusable framwork code changing over time?

In other words: One issue I found is that if you use code between projects and your framework code is evolving with your game code or with one specific MonoGame project your working on then often this breaks another project because it is relying on an older version of this framework code base where things were working differently.

Also what advice do you have on how to setup the overall solutions and projects structure not only for a single MonoGame project / game. At the moment my idea is as follows but not sure this is the right way to approach it:

Have a Visual Studio solution per framework with only a “MonoGame Shared Project” each inside each solution and maybe one or more MonoGame sample projects for some platforms showing how to use the framework code. Each framework residing in one folder.
Then everytime you want to make a new game or create a new multi platform MonoGame project you would create a new folder where you would setup a “MonoGame solution”. With “MonoGame solution” I mean the standard or recommended way to setup a multi platform MonoGame project / game. I think it works this way: The project / game would consist of a “MonoGame Shared Project” and one or more MonoGame projects (one for each platform that you would like to target). To be able to use the code of one of your frameworks in this new game you would then add the framwork code only as a reference by adding the shared project from the framework solution to the game solution. Not totally sure how this works with Shared Projects inside Visual Studio. I think it works with either “add existing item” and “add as link” to add it to the different platform projects in the new game solution from inside Visual Studio. If this is possible this way with “MonoGame Shared Projects”? Do they work that way? I still have to try this out. Or do they work like this, that I have to add the frameworks “MonoGame Shared Project” project to the game solution (so not directly to the adding the framework project to the platform projects!) and only then when the game solution has the framework Shared Project added (as link?) with “add existing project” and “add as link” or so add a reference to the single platform projects to both the framework shared project and the game shared project to be able to work with all the code but keeping things more managable or clean if you will?
Assuming at this point we found the correct way of setting this new game up with Visual Studio we would then have access to the shared game code residing in the game solution and inside the game folder itself as MonoGame Shared Project and also access to the framework code residing outside this folder in another folder.

I guess it is not possible or at least not easy to NOT eventually break exisitng code if the framework is evolving while working on a new game / project. Each older MonoGame project has to adapt to the changes which will happen to the shared framework code. So this would mean alot of work to keep all projects working all the time.

Now starting with version control… If the framework code is under version control with git and of course the game(s) on top of that also… An issue IMHO with this structure would then be that the framwork would be a seperate git project right? Then how to make sure that a commit for a game will work when the code from the framework is under its own version control? Would this then mean that you have to use git submodules for each framework a game uses to make sure a game compiles at some git commit at some point in time although the framework code itself has evolved and changed over time? I mean the MonoGame code itself had this approach with git submodules in the past at least but not sure if it is still the case and if this turned out to be a good solution.

Let me know what works best for you and what you guys and girls think what is the best solution for this all! :slight_smile:

If you are using git for source control, the traditional way to do this would be to have a repository for the shared code separate from your game, and a fork of it per game. Then you make changes to it in a game branch, but whether or not you contribute that change upstream or when you pull changes downstream is fully under your control.

The annoying thing here is that its another project to manage… somewhat alleviated if you have it setup as a submodule and use something like sourcetree.

Another question, to which I don’t have the answer, is whether this shared code is literally just code files and each game includes whatever files directly into its project it needs … or the shared code is a ‘shared code project’ … or it could be a normal library project …

I checked GitHub it seems like I cannot fork own repos. So I am not that firm in git terminollogy but I think forking is cloning a repo on the server side from another public repository or in git terms a fork means cloning upstream (right?). But following your idea this can of course be done by creating branches I guess? So then I would have a branch per game for the framework. I think this could work. But it is not so easy to keep track of all this. So the tidying up on the source side then would come with more work on the managing the source code management side, right?

I think(!) these MonoGame Shared Projects are just the standard Shared Projects but with MonoGame references already added to them? Anyone here can confirm that it is like this? I don’t know if I get the second part right you have written. A Shared Project (and so a MonoGame Shared Project) holds the C# source code to be shared. Any project (e.g. the MonoGame platform projects which are targeted for a game) just have a reference to these code files. So this is from the git side under source code management in a multi platform game if we are talking about the MonoGame Shared Project for the game itself. In contrast to that a framework code residing in another directory and being a seperate git project is not under source code management automatically together with the game although you might have access to the code via Visual Studio I guess because inside Visual Studio the framework Shared Project is only added as a reference or added as link. At least think this is how it works?

A #if preprocessor directives may work, if works on me for Windows and Android if may works on you if put MG Version like image below ^_^Y


To stay sane I like to make it so that checking out a project from source control also gets me all the dependencies so I don’t have to run around looking for other files and can just do a build. So I would make a copy of the shared code for each project and put it in that projects source control.

Then if you really want to take a new feature and add it to an old version you can run something like windiff to help you.

It also might help to keep a text file in reusable code project that logs any features or changes to make it easier to spot the differences between versions.

I see. I think this is not the optimal way but I have decided to just add a separate project for now. Later when I want to use it somewhere else I can see which option makes sense the most and reorganize it.