In this article, I want to talk about shared code. If you are a studio working across a couple of projects, unless you are using radically different technologies, it is good to keep a repo of code that could be shared and reused in multiple games. I am going to talk about this in the context of Unity as that is what I am most used to, but this can apply to Unreal and custom engines.
The first thing to note is that, whatever project you are working on, I guarantee you are going to end up solving the same problem, over and over again. You will be surprised by the amount of what I call “cross-code pollination” in vastly different genres. A lot of code that is made in Space Shooters, for example, has made it into Horror game prototypes, and code that is in a complex CCG can end up in match 3 games.
To reiterate, regardless of what game you are working on, there are gonna be problems you are solving again, whether it is UI code for menus, extension functions you added to make life easier, custom data structures or new coroutine functions that hook into threading. Even if you are not working on multiple projects right now, it is good to go through your codebase once in a while and check if there is code that in theory could be applied to other projects.
On top of that, if your team gets into a mindset that code could be shared, they should start looking at problems a bit more, shall we say, holistically, and potentially improve their system design skills, or at least approach it in a potentially more effective manner.
Actually going about sharing the code is the interesting one and depends on your set up.
My advice would be to keep it all in a repo, but if you have the tech, have a build job that creates releases in a zip format that people can pull in. This would be a zip of the raw code files, not a DLL. If you have a DLL, you are potentially bloating an app with code people don’t need, with a zip and raw code files, they can pick and choose the code files they need.
Similarly, you could have everyone in your organisation have access to the repo, which is also a good way to pick and choose code files and also commit new ones. However, avoid anything like submodules. Even if you are all using Git, perforce, etc, if there is even the slimmest of chances that another project is going to be using a different source control system and you decide to use something like a git submodule, you are going to make their life harder in integrating shared code.
Regardless of how you do it, I think it is worth getting into the habit of retrieving more code that solves common problems, as essentially it will make building games quicker. I have one that I have been building over about 10+ years of using Unity and in some cases, it has made my development speed on par to Sonic running through Green Hill Zone