Game repository structure with Xlinks

Description

Game projects typically share some key structural elements:

  1. Game code
  2. Engine code
  3. Art (a.k.a. processed|compiled art)
  4. Raw art - as created by artists

Different game projects will share the ‘engine’ code that will evolve with the contributions of a core engine team and the different game teams.

Benefits

While in other version control systems it usual to define a monolithic big repository in Plastic the best way is to use a different repository for each component and then link them using Xlinks

Smaller and cohesive repositories end up being a more logical way to design the repository structure and provide additional advantages:

  • Smaller repos are easier to handle.
  • Individual repos can be hosted on different servers, which helps in heavy load scenarios.
  • Smaller repos make code reuse simpler.
  • Replica of different repos is faster than a huge single repo.

The following sections describe how to model common game scenarios using Plastic and Xlinks.

Game “1” repository structure – Development:

Each game sharing a common engine will use a similar structure:

  • An “engine” repo containing the code of the engine.
  • A “game art” repo containing ‘processed’ art.
  • A “game code” repo containing the code of the game.
  • A “game project repo” used to “xlink” to the previous 3 repositories. This “mounting” repository can be optional but it is very useful to keep the “game code” independent from the engine and art repos.

Alternatively the “game proj” repo can be avoided and the team can use a simpler structure like this one:

Each different game in the studio will follow a similar repository pattern, reusing as many shared components as required.

Game “1” repository structure – Engine Developer

An engine developer will typically need a “sample game” in order to test different improvements with real code during development.

In order to model this requirement he will use in the following way:

Game “1” repository structure – Engine Manager

In order to test the “engine” with more games, the structure will be as follows:

Game “1” repository structure – Artists

Artists will use an ‘art’ repository (normally ‘raw art’) and will work on a single branch.
They will use “locking” to prevent concurrent access to the files they’re working on, which are typically unmergeable.

The structure will be as follows:

  • One “raw art” repository where the artists will checkin their changes.
  • One “game art” repository (one for each game, although the actual structure will greatly depend on the team) with the ‘compiled’ art in the right format for the game engine.