GameDev

This one goes out to the hobbyists and the solo devs, as I’d guess anyone employed in the industry is already using such basics.

But it does seem to be a particular problem among less experienced game developers, to avoid using version control (also known as source control) and risk losing progress if not their entire project.

Just in the last few weeks I’ve seen a video from a well-known indie dev admitting he got himself into a tangle through not using it, another one with a guy trying to make a game in a weekend only to have his files irretrievably corrupted on the last night. And endless Discord conversations in which someone has lost a significant amount of work and needs to be talked down from a ledge.

Plus it came up in the game jam advice thread, so it’s been on my mind and I thought it deserved its own post.

Why is this so prevalent in game dev? I have a few ideas, mostly around misunderstandings and perceived complexity. But it’s a bit heartbreaking to see people lose such huge chunks of work, not to mention demotivating for the person involved, so a PSA it is!

Why you should be using version control

• Backups - Each commit is an emergency backup of your code at a particular point in time. Hard drive fails? Well, luckily you’ve only lost the work done since you pushed the last commit. Note: I do recommend taking regular backups to store elsewhere and not relying on just this, but it’s a good start.
• Experimentation & rollback - You can feel free to try new things, break stuff, safe in the knowledge that if it all sets on fire you can just roll back to the last commit and pretend nothing happened.
• Teamwork - Sharing code and working together without overwriting stuff can be a bit of a nightmare. Version control helps to prevent issues and keep things running smoothly in a team situation.
• Branches - Maybe you’re working in a team and want to try adding a new feature without bothering anyone else. Or maybe you’re working solo but want to keep your wild experiments separate to your stable codebase. Either way, sorted.
• Paper trail - Ever discovered an obscure bug and wondered when it crept in and how (or maybe even whodunnit)? Now you can find out.
• Versioning - Clue’s in the name really, but once you start thinking about game releases and versions the ability to differentiate between stable release branch and work-in-progress branch is gonna come in clutch.
• And probably plenty other reasons that I can’t think of right now off the top of my head but hopefully you get the idea.

How to get started

There are two things you’ll need to start, the actual version control software and a place to host your project.

The most popular source control software is Git, and the most popular host is Github. Honestly you might as well learn these first because even if you decide to move to an alternative later, they’re massively popular in the industry and most teams and places of work will expect this knowledge anyway.

This post is long enough already without trying to add an actual tutorial in here but info on the exact process is easy enough to find. You’re smart, you’ll do fine.

You can interact with your project through the command line, but you can also install a more user-friendly GUI. The two most popular tend to be SourceTree and Github Desktop.

You can also find engine-specific help and .gitignore files etc online, so do make sure to search for those.

Before you start your next project. Before you work on that new feature for your work-in-progress game. Before you lose something you’d really rather not have lost. Please, please use version control.

End post.