Game projects typically share some key structural elements:
Art (a.k.a. processed|compiled art)
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.
While in other version control systems it's 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
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:
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
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.