Why games need extra care
A small game can be built by one person with a single folder of files. Add a second person, and the folder becomes a hazard. If two people edit the same file and copy it back, one person’s work silently disappears. Emailed zip files and folders named “final_v3_REAL” make things worse. A system that tracks every change, lets people work in parallel and combines their work safely is a basic need, not a luxury.
That system is called version control. Games add a complication: besides small text files of code, they contain huge quantities of art, audio and level data that behave very differently.
What version control does
At its core, version control keeps a history of a project. The main ideas are few.
- Repository: the stored project along with all of its history.
- Commit: a saved snapshot with a short note on what changed and why.
- Branch: a separate line of work, so a risky feature can be developed without disturbing the main version.
- Merge: combining one line of work into another.
- Revert: going back to an earlier snapshot when something breaks.
The benefits go beyond collaboration. Even a solo developer gains the ability to undo mistakes, see when a bug first appeared and experiment freely. If the game worked on Monday and is broken on Friday, the history narrows down what changed in between.
Text files merge, binary files do not
Code is plain text. When two people edit different parts of the same file, version control can usually merge the changes automatically, and when they edit the same lines, it flags a conflict for a human to resolve.
Many game assets are binary: images, 3D models, audio and some scene or level formats. A tool cannot look inside two edited copies of a painting and combine them sensibly. If two artists change the same binary file, someone’s work has to be thrown away or redone by hand.
There are three usual responses.
Locking. A person claims a file before editing, and others see it is taken and wait. It prevents conflicts at the cost of some flexibility. Some tools used by larger teams are designed around this.
Splitting files up. Teams break large scenes or levels into smaller pieces so that different people rarely touch the same one. Many engines can store scenes in text-based formats, which restores some merge ability.
Communication. On a small team, simply saying “I’m working on the forest level” can be enough. This is fragile as the team grows, so it is better paired with one of the other approaches.
The size problem
Text files are small, and history for them is cheap. Art and audio files can be large, and every changed version is stored again, so a repository can grow quickly. A project that has been through many revisions of big texture files may become slow to download. Some tools address this by storing large files separately and keeping only a small pointer in the main history. Others keep assets in a different system from code. Which approach suits you depends on your team size and storage costs, and it is worth deciding early, since moving later is awkward.
Several practices help regardless of tool:
- Save generated or temporary files outside version control, since they can be rebuilt. An ignore list tells the system which files to skip.
- Avoid storing finished builds in the repository.
- Keep a consistent folder layout and naming rules.
What an asset pipeline is
An asset pipeline is the route a piece of content takes from its creation to its use in the game. An artist makes a character in a drawing or modeling program and saves a source file. That source is then exported or converted into a format the game can load efficiently, and finally placed into the engine, where it may be compressed, resized or packaged. The details of how art moves from idea to finished piece are discussed in the art pipeline, and this article looks at the file-handling side.
Keeping the stages organized pays off in several ways.
Source versus exported. Source files are the originals with layers, history and editable parts. Exported files are what the game reads. Teams generally keep sources safe and tracked, even if the exported versions are stored elsewhere, because losing a source means redoing work.
Automation. If converting files requires fifteen manual steps, mistakes are inevitable. Scripts that run the conversion the same way each time reduce errors and save hours. Even a small team benefits from a single command that rebuilds everything.
Consistency. Rules such as maximum texture size, naming and animation frame rate can be checked automatically. A file that breaks the rules can be rejected or fixed before it reaches the game.
A workable setup for a small team
A reasonable starting point for a small team might look like this, with the specifics adapted to your tools:
- Put all code, scripts and text-based data in version control from the first day.
- Decide where large art and audio will live, and write that decision down.
- Commit small, frequent changes with clear notes, instead of large unexplained ones.
- Use a branch for risky experiments, and merge only when the game still runs.
- Keep a backup of the whole repository on a separate device or service, since version control on one machine is not a backup.
- Build the game from a clean copy occasionally, to prove that nothing depends on a file only you have.
Where team members have defined responsibilities, as discussed under team roles, it also helps to decide who is allowed to change which kinds of files.
When things go wrong
Most problems are manageable: a merge conflict is visible, and a broken commit can be reverted. The dangerous failures are silent ones, such as overwritten binary files and single unbacked-up copies.