Game projects typically share some key structural elements:
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 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:
The following sections describe how to model common game scenarios using Plastic and Xlinks.
Each game sharing a common engine will use a similar structure:
Alternatively the “game proj” repo can be avoided and the team can use a simpler structure like this one:
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:
In order to test the “engine” with more games, the structure will be as follows:
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: