When starting out in game development or software development in general, most beginner tutorials and classes jump straight into programming. Writing code is important, of course, but before diving in, it’s worth having a foundation in project management. These skills set you up for success as projects grow in size and complexity, and they’re highly valued by employers, even if they’re often overlooked in entry-level teaching.
Version Control System
One of the most important project management tools you’ll use is version control. In the early days, this was called source control because projects mainly consisted of code files (source code). As projects became bigger, including not just code but also images, audio, 3D models, and other assets, the idea of “source control” expanded into version control. Instead of just managing lines of code, version control helps track every type of file in a project.
Traditionally, teams tried to keep track of file changes by giving them version numbers or names like final, final2, or final_reallyfinal. As you can imagine, this quickly became messy. Version control systems (VCS) are applications that solve these issues by keeping a complete history of your project, all in one place.
VCS Multiverse
A great way to picture version control is through the lens of the multiverse, similar to how it’s portrayed in Marvel’s Loki series. In the show, the sacred timeline represents the “main” reality, while branching timelines allow alternate realities to exist and explore different possibilities.
Similarly, in a VCS, each project lives inside a repository, think of it as the container that holds everything: code, assets, and the full history of changes. Within that repository, your main branch represents the sacred timeline, the central storyline of your project.
Every time you commit changes, you’re adding snapshots to the history of that branch. These snapshots let you revisit specific points in time whenever you need, almost like rewinding the timeline.
But the real multiverse appears when you branch. Branches are alternate universes of your project, where you can test new features, fix bugs, or experiment freely without touching the sacred timeline. If an experiment works, you merge that branch back into the main line. If not, you can simply discard it, leaving the core project untouched.
In this way, version control gives you both a clear history of your project’s timeline and the flexibility to explore alternate realities without losing your place in the main story.
Why Use Version Control
You might be thinking, “Sure, version control sounds great for large teams, but why would a solo developer working on a small project need it?”
Even for a single developer, version control is invaluable. Its history and branching features mean you always have a backup of your project, so if something goes wrong, you can easily revert to a previous state. Branches also let you test new features or experiment with changes safely; if an idea doesn’t work out, you can discard the branch without affecting the main project.
Regularly using version control also helps you build good habits and skills that are essential in professional development workflows. By committing frequently, organizing branches, and managing merges, you gain experience that will make collaborating on larger projects much smoother in the future.
Centralized vs Distributed Systems
As mentioned earlier, a VCS stores projects in a repository (or “repo” for short). This repository lives on a server, which can be local (e.g. your own computer or network) or remote (often in the cloud). Although there are many different VCS tools, they generally fall into two categories: centralized systems and distributed systems.
In both models, the main repo that contains the entire project (i.e. scenes, assets, scripts, etc.), which lives on the server. Developers create a local clone, often called a working copy, on their own machine. Changes to the project are committed, meaning they are recorded in the history of that working copy. Once the changes are complete, an update is performed. An update is a two-way process: the developer’s commits are sent back to the main repository so the server always has the latest version, and at the same time, any new changes already added to the main repository by other team members are copied back into the developer’s working copy.
Centralized VCS
In a centralized system, updates are applied directly to the main repository. To prevent conflicts, developers often check out files before making changes. This locks the file so that only one person can modify it at a time. Once the developer checks in the file, the changes are written to the main repository, and others can update their own working copies. This model provides strict control and avoids conflicting edits, though it can also slow down collaboration if multiple people need the same file.
Distributed VCS
In a distributed system, each developer has a full local clone of the repository, complete with its own history. Changes are committed locally and can be updated freely without requiring locks. Once work is finalized, developers push their changes back to the main repo and then pull any updates from the main repo back into their local clone. While this model is more flexible and supports offline work, it increases the chance of conflicts. These conflicts don’t always occur on the exact same file, often they happen when two related files are changed at the same time. Such conflicts can be resolved, but they require careful coordination.
One drawback to a distributed system is that each local clone contains the full history of the repository, which can take up a significant amount of space on a local machine.
Popular VCS Tools
Git VCS
In software development, Git is by far the most popular VCS. Its distributed system, open-source nature, and lightweight handling of text-based files make it ideal for typical software projects, which are often composed primarily of code.
Although Git is primarily command-line based, GitHub provides a web-based platform for hosting cloud repositories and offers limited free storage, contributing to Git’s widespread use. For users who prefer a graphical interface, GitHub Desktop allows easy local management and synchronization with GitHub.
While Git is not specifically designed for projects with large game assets, many indie and smaller-scale game developers still choose it due to its accessibility. In these cases, Git Large File Storage (LFS) can be implemented to manage large files by replacing their history with text pointers, reducing overall storage requirements.
Perforce P4 VCS
The game industry standard VCS is Perforce P4 (formerly Helix Core), which was designed specifically for game development. This enterprise software handles large binary files alongside code, making it ideal for studios with asset-heavy projects. While its centralized system ensures strict control over file edits, licensing costs can be a barrier for smaller teams.
Switching from a distributed system like Git to a centralized system such as P4 can present a learning curve. For beginner game developers, starting with Git is recommended due to its accessibility. However, gaining experience with both Git and Perforce is valuable, as familiarity with both systems is widely sought after in the game development industry.
Unity VCS
Unity also offers its own Unity VCS, which supports both centralized or distributed workflows. Designed for game development (not just Unity development) the Unity VCS also includes an in-editor interface making it easy project integration. However, the free version is limited to a three-member team, which can be restrictive even in a classroom setting where the typical group size is 4-5. Additional seats can be purchased, but the added cost and shorter industry track record make Unity VCS less popular than Git or Perforce.