How to share an engine repository between different video games

How to share an engine repository between different video games

Tuesday, August 05, 2014 calbzam 2 Comments

If you ever wondered how to set the dependencies between different Plastic SCM repositories or you have been struggling to share common repositories using Xlinks , you will probably find this post helpful.

Initial setup

Let´s review a scenario where a video game company has a shared engine that is being used at the same time by two different game studios (in different locations).

Each game studio will have an "engine" repository and a "game" repository.

The "engine" repository will be synchronized to the remote main "engine" repository in New York.

The "game" repository will be local an independent per game studio.

The goal is to share the engine code between the two studios and, at the same time, the engine developers internally continue evolving it in New York.

How does a workspace look like?

This is the workspace of a developer who works in the Game A at the Vancouver studio. There is a folder containing the game code and also an Xlink pointing to the local "engine" repository.

But let´s now review in deep how the engine repository should be configured to succeed in this scenario.

Engine repository configuration:

As the engine might be different in each game studio, the “engine” repository has internal branches to handle the specializations. We create a new branch per game. This set up allows each game studio to use the engine code and modify it independently.

In the Vancouver studio they create a new branch for this purpose.

The good point of using specific branches per game is that interesting fixes or new features can be merged or cherrypicked between branches and then easily replicated to the remote sites.

In our example, the studio located in Vancouver develops a fix in the engine that is considered indispensable for his colleagues in London (and other future studios). In order to share the fix, they perform a merge from his specific branch to the "main" branch of the "engine" repository.

Finally, they just push the new created changesets to the engine central repository in New York. Now the new engine version (including the fix) is available for all the studios. So the other studio in London just need to pull the new stable version of the engine and rebase it to their working branch (remember that every game studio has a specific branch in the "engine" repository).

Games repositories configuration:

The game studio locations also need to configure their local setups. There will be a “gameX” repository containing the local game source code and a local “engine” repository. This repository will be a replica of the New York´s engine.

The way the Plastic handles repository links are creating Xlinks. So we create an Xlink in each "game" repository pointing to the "engine" repository.

Notice that the Xlinks are pointing to the specifically created branches per each game.

When the Xlinks are created, we also have to properly adjust the branch auto expansion rules. This way, we can keep the independence between the two games although they are actually using the same Xlinked "engine" repository.

Xlink branch expansion rules on the GameA repository --> source branch: "/main", destination branch: "/main/GameA".

Xlink branch expansion rules on the GameB repository --> source branch: "/main", destination branch: "/main/GameB".

Note: We select both options:

Writable: Because we want to perform changes in the Xlinked "engine" repository.

Use relative server: The Xlink tries to get the repository from our local server. This option is necessary because we are working on a replicated local repository and we don´t need to access to the remote server.

Share the engine changes between games:

This game independence doesn´t limit the propagation of the changes performed in one game to the other. It can be performed in two easy steps:

Cherrypick/merge the desired changesets from one game branch to the other in the "engine" repository.

Update the Xlink target to the merge result changeset.

Finally, It´s interesting to realize that using this workflow, we can avoid replicating the entire "engine" repository per game studio location. We can just sync the desired branches on demand avoding unnecessary disk and network usage.

It means that the Vancouver studio doesn´t need to sync the "/main/GameB" branch because they are only working in the GameA.

Carlos Alba

I joined the Plastic product experts team back in 2013.
As a Plastic SCM product expert, I try to help teams moving from other version controls on a daily basis, decide strategies, train developers, answer questions, run benchmarks ...
I love soccer and rock music. You can reach me at @albazamanillo.