Hi fellow developers!

So I've been trying to setup my own game engine but have a small problem.
These are my repos:
Game
Renderer
Physics
Utility (templates, helper macros, math, prints and so on)

Problem is, Utility repo is still quite new. It's frequently changed with new templates, new helpers and so on.
I currently have this kind of connection:
Game
Submodules:
Renderer
Physics
Utility

So if I change Utility by adding new template which either Physics or Renderer uses, let's say MyVector<Type>,
then I'll need to update the Game repo. It becomes a 2 step update which I think becomes a little bit unecessary.

I tried doing maybe something like this:
Game
-Renderer
--Utility
-Physics
--Utility
-Utility

Problem is then that visual studios doesn't approve of having multiple projects of same name.
But it would at least solve the problem of the commit dependency (if that even is the correct term).

Please do ask for more information if I wasn't clear enough.

EDIT:
Realized that I didn't write about the build dependencies in my solution (it was obvious to me but maybe not to you).
It looks like this in the build order in my solution from first to last:
Utility
Physics
Renderer
Game

Don't know why I didn't realize it before but a solution (not sln) I thought of just now is that
I simply add the static lib that is generated from Utility Project to a Property Sheet instead of building it with the sln.

That means I won't be having Utility project in the solution, but considering that it was depended on by all the other projects in solution, this is the best solution I could come up with.

Just wanted to update in case other people have come to this problem (Do note however, there might be a better solution (not sln :P)).

Why do you need submodules? Submodules in git are there if you have a third-party dependency in your project that you need from a special revision. In a game engine project you always should have all sources in place, especially if you develop that on your own. So make every repo also an own Visual studio project file and keep them all in an overall solution file will prevent from fiddling around with git all the time

Oh, I didn't know that submodules was mostly for third party.
I was trying to replicate how it works in bigger studios since that's what I wanna do in the future.
I cannot imagine 100-300 people sitting in the same repository because people would then just keep interrupting each other with commits (although, I guess it would be the lead devs that decides when it's commited).

Every repo is their own project. I forgot to mention that as well.
So I got projects which are Game, Renderer, Physics and Utility.

Zansin said:
I was trying to replicate how it works in bigger studios since that's what I wanna do in the future

Bigger studios don't care of submodules or something like that rather than have one repo for the whole project most of the time. I'm working in such a studio and we use perforce and a single workspace for our project. The engine has a workspace as same as the game.
What we do is what everyone else does, in perforce you can lock files so they are displayed as “in use” to other people while in Git or SVN based environments you'll open a branch for your work then reintegrate it back into the master when you're done.

Zansin said:
I cannot imagine 100-300 people sitting in the same repository because people would then just keep interrupting each other with commits

No! Or at least not if they are coordinated well. It is a rare situation that two or more commits target the same file at the same time rather than different files in the project so if you put more effort into the right project management than the right Git setup, then you'll be safe anyways.

Our game engine project for example makes use an atomic module approach. Every module in the project fulfills a unique task and bigger modules are assembled from smaller ones

Shaarigan said:
Bigger studios don't care of submodules or something like that rather than have one repo for the whole project most of the time. I'm working in such a studio and we use perforce and a single workspace for our project. The engine has a workspace as same as the game.

Oh okay. But then, if you have several game projects that uses the same engine, how do you handle that connection?
Because as I understood it as, if you would make changes to the Engine, you would commit that to let's say, Game1 Repo.
But if you have Game2 Repo, you need to basically copy changes from Game1 Repo to Game2 repo?

Shaarigan said:
What we do is what everyone else does, in perforce you can lock files so they are displayed as “in use” to other people while in Git or SVN based environments you'll open a branch for your work then reintegrate it back into the master when you're done.

Ah okay! So that's how it works. I worked before with conflicts all the time and we had to merge quite a lot.
We knew about “locking” but never put it in use.

Thanks for the info :D

Zansin said:

Shaarigan said:
Bigger studios don't care of submodules or something like that rather than have one repo for the whole project most of the time. I'm working in such a studio and we use perforce and a single workspace for our project. The engine has a workspace as same as the game.

Oh okay. But then, if you have several game projects that uses the same engine, how do you handle that connection?
Because as I understood it as, if you would make changes to the Engine, you would commit that to let's say, Game1 Repo.
But if you have Game2 Repo, you need to basically copy changes from Game1 Repo to Game2 repo?

Call me basic, but I just have my engine in a separate repository entirely, and each game in its own. No submodules at all. I use a windows system-variable to tell the games where to find the engine; but technically they are always in the same root-folder on my PC.

Yeah, that would have downsides, as making an upgrade to the engine is always automatically applied to all projects. But the way I see it, thats kind of the way I want to have it anyways. If I were to require different working version, I'd start doing it like Unity/Unreal and make explicit versions of the engine that projects can use.

Juliean said:

Zansin said:

Shaarigan said:
Bigger studios don't care of submodules or something like that rather than have one repo for the whole project most of the time. I'm working in such a studio and we use perforce and a single workspace for our project. The engine has a workspace as same as the game.

Oh okay. But then, if you have several game projects that uses the same engine, how do you handle that connection?
Because as I understood it as, if you would make changes to the Engine, you would commit that to let's say, Game1 Repo.
But if you have Game2 Repo, you need to basically copy changes from Game1 Repo to Game2 repo?

Call me basic, but I just have my engine in a separate repository entirely, and each game in its own. No submodules at all. I use a windows system-variable to tell the games where to find the engine; but technically they are always in the same root-folder on my PC.

Yeah, that would have downsides, as making an upgrade to the engine is always automatically applied to all projects. But the way I see it, thats kind of the way I want to have it anyways. If I were to require different working version, I'd start doing it like Unity/Unreal and make explicit versions of the engine that projects can use.

Sounds like a great solution, the only thing that bothers me there would be having the system variable.
I was thinking of the easiest way to just “download a repo and start developing” so having to add a system variable would basically
increase the steps needed to start developing, in case of a new developer joins the project.
I assume that artists, level designers and more don't actually know what system variable even is.

Sounds like a great solution, the only thing that bothers me there would be having the system variable.
I was thinking of the easiest way to just “download a repo and start developing” so having to add a system variable would basically
increase the steps needed to start developing, in case of a new developer joins the project.
I assume that artists, level designers and more don't actually know what system variable even is.

You could always abstract that process by having a sort of installer, or batch script. Big engines like untiy and unreal have a dedicated installation process for a reason, anyways. I suppose at one point you will have to perform some setup-step like installing dependencies (for example, you would always need to install the DirectX-SDK up until windows moved it into the windows-SDK). Or installing the IDE or something. So you'll likely have to have at the very least a list of things you need, and you could just have guide where some point says “execute Setup.bat before starting the IDE", or something like that I suppose.