Games are complex systems. They mix 2d and 3d artwork, sounds, game logic and rendering engines. These systems are most often created by teams. The biggest games are often worked on by hundreds of people. All these people are making changes, adding pieces, and fixing problems. It is essential to keep track of all these actions in order to maintain the integrity of the whole. Such tracking is facilitated by systems referred to in game development as 'version control.' At the start of a game jam such as the one that Unknown Worlds held this weekend, teams will often make selecting a version control system one of their first priorities. Without version control, work cannot begin in an organised manner. Here are two version control systems that teams used this past weekend:

Subversion

Team one, featuring Brian and Chris, chose a trusty old friend. Subversion is a robust version control system used for large software development projects, including Natural Selection 2. Its name is often abbreviated as 'SVN.' Available at apache.org, Subversion is open source and compiled (ready to use) versions are available free of charge. Partly because of its open source nature, there are a plethora of clients available through which a developer can interact with a Subversion server for their project. One very popular client, and the one Brian and Chris were using on the weekend, is called Tortoise. Rather than featuring a full GUI (Graphical User Interface), Tortoise manifests itself as a Windows Shell Extension. This means that when you right click on a file in your file system, Tortoise Subversion options are displayed. Subversion's great strength is the ease with which it can be set up. This is as much to do with its ubiquitousness as its design: So many people use Subversion for such a wide variety of projects that information about it and possible use-cases is widely available. No system is perfect, and Subversion can fall short when a team is trying to synchronise complex code. This weakness can be mitigated by organising code well: Making it modular, easy to parse (read and understand), and aesthetically clean. In a game jam situation, such organisation is often not present. So Brian and Chris sometimes found themselves untangling SVN synchronisation, rather than working on their game!

GitHub

If you like your version control with a dose of royalty, GitHub may be for you. Created by Linux mastermind Linus Torvalds, GitHub makes an immediate impression on new users with its welcoming, modern web-interface and step-by-step instructions. Whereas Subversion requires a little bit of knowledge and work to set up, GitHub will walk you through setup, hand in hand. Github is not a version control system in the strict sense - It is a website that allows you to host Git 'repositories (places where project assets such as code are stored). Think of it as a bit like a very slick wrapper for the system itself. Team 5, featuring Max, Dushan and Brian, chose to use GitHub for their project. One reason they chose to go with GitHub was its hosting. Users can host as many public repositories  as they like. You only have to pay if you want your repository to be private. Because the UWE Game Jam is a public event, this hosting is perfect. Speaking of perfection, that's something GitHub, like Subversion, does not achieve (Who, or what does?). Git caused some headaches for Max, Dushan and Brian when it threw 'merge conflicts' (errors produced when GitHub attempts to consolidate multiple people's contributions into a whole) when team members modified the same files. In a Game Jam situation, this can happen often, as code is often not well organised, and team members are working as fast as possible. You can see the public GitHub repository for Team 5's game, 'The Grid,' here.

It's the player not the racquet

Whatever version control system you choose to use for your project, there are a few practices you can follow to make sure your project stays well organised. First, make sure you and everyone on your team understands the system and how to use it. If someone does not understand the system, they could cause merge and synchronisation problems. Second, keep your code clean and keep an eye on the big picture. The more hacky and inter-dependent your code becomes, the harder it will be to navigate your version control repository and the more problems you will encounter. That goes for art and other non-code assets as well! Third, play around in new version control systems with small projects before big ones. Max and Charlie would never have chosen to use Subversion for Natural Selection 2 if it was their first rodeo with the system. Experiment on non-critical repositories!