What is the importance of Source/Version control?
Version control, or source control, is the name of a type of file management system that is intended to keep backups of every file you submit. You can quickly share the updated files with a large number of people because the source control keeps a master branch that can be used to update files for the whole team.
At The Game Production Company, We have been using Perforce for quite a while now and as an individual, I am quite happy to use any system for source control that is requested. In the past, I have also used Github and TortoiseSVN.
There are two types of source control that generally all source control software follow, The first is Git. This involves creating new branches of changes and then merging the changes back to the master branch when they are done. This is great for code but has complications when dealing with sound and art assets which generate conflicts when multiple people work on them, with the upside that code can be worked on at the same time, increasing work efficiency.
The second system is Subversion which fixes all these issues with a major downside. With subversion, the files get locked when being edited and must be checked in after they are done with. This avoids conflicts occurring when two people edit the same file. The file locking is really useful for ensuring you can work on what you need without people changing things. Because of file locking, Subversion works especially well for art and sound files but means only a single person can work on code at a time.
My preference and why:
I prefer Subversion for the work I do, having a file locked means I won’t have to deal with file conflicts and that ensures I can focus on the task at hand. File locking also means people won’t change my own work while I have it checked out and makes it easy for people to know what files I am working on and have edited.
As I tend to work on smaller projects with close-knit teams, I can usually send a message to whoever I need asking for a file to be checked in when they are done, although forgetting to check in files is certainly a downside to Subversion systems. That said, I would happily use any system if asked as the two types both do an excellent job at source control.
I can also see why some teams prefer Git. Being able to work on files and decide late which changes to use makes coding much faster, and allows multiple programmers to work on the same file. Locking out a programmer from a file they may need can be both expensive and much harder on the programmer. I would imagine a lot of redundant code is created to get around file locks.
No matter what system is used, an important aspect to remember is to comment what changes you have made. All too many times do I have to look back into the history of our source control to see when a change happened and what was changed, especially when fixing bugs, good comments make all the difference.
Feelings about source control:
I feel that source control is a hassle overall, but a necessary one. You have to remember to manage it but it could save you when you need it. It also could be a good part of team management and tracking what people are working on which I really like. It brings more structure to the process of development and allows individual developers to take better ownership of their tasks.
An evaluation and analysis of source control in the games industry:
Using source control is an industry-standard practice that has integrated itself into every studio’s workflow. Some newer developers don’t use it as much as they should but that’s a mistake you only make once. We at the Game Production Company have had computers stolen in the past before we used source control and have experienced losing work firsthand so I know how important it is to keep good backups.
Source control has also worked it way into project management, you can see who has which files checked out in a subversion system and who has made what changes in a Git system. It’s good that all of the different branches of game development can be tracked together within a system designed to protect developers and projects and it would be silly not to use these systems, some of which are free.
Finally, it’s important to remember that it’s not always the developer’s fault when source control is needed to be called upon to restore a backup. Yes, a computer may break causing files to be lost, but alternatively, a new idea may just not work and the changes need to be reverted. So while anything that can go wrong must be assumed to be inevitable in order to prepare for it. Source control can not only change how you develop your project, being free to try ideas in a risk-free environment, while also protecting you from external problems such as hardware failings or theft.
Source control is effectively a file management system at its core and this has some business advantages too, (Gershenfeld, Loparco and Barajas, 2013) claims that studies have shown that “most game developers will put up with a severe crunch mode for one, or at most two, projects and then they start looking for another company.” This turnover could potentially cause issues with getting up-to-date files to new employees, an issue that is essentially solved with a source control system in place.
Looking at an alternative angle, Some would suggest that source control is another thing that can go wrong as an additional component in a larger system, and because of how important it is to backup work, I must stress the need for good, reliable source control. (VandenBerghe, 1999) tells us about issues caused by their source
control system, SourceSafe 4.0, “It worked effectively as a code database, but was a less effective choice for a revision control system. It gave us one nasty shock during the PSX port: we lost all of our revision history due
to being unable to move the revision database from one server volume to another”. Luckily they didn’t need to rely on their system to restore a project but it shows how much damage could have been done by relying on a system not fit for their needs. A fine example of why you need not just any, but good source control.
Self-Crit
What I did
To try out different types of source control, I reflected on my experience with Perforce and TortoiseSVN both different Subversion systems. I also tried out GitKracken and Github Desktop.
What went wrong
I was already quite experienced with source control but I can tell that its very confusing for a newer user who doesn’t yet know many of the concepts of source control, especially if you decide to use the console instead of the GUI. I was only able to grasp the process of using the console because I understood what was actually going on on the server.
How can I overcome what went wrong
My advice for any newcomer to version control is to try it out, When I first started I had to figure it out myself. I watched a few videos and quickly understood how it worked, then through trying it quickly picked up the rest. It’s not super difficult after you have used it a bit.
When I start a new using a new source control system, I usually ask for a quick walkthrough of how to get the initial files and quickly try out creating and uploading a non-vital file to check I can both check-in/out or create a branch. Then once know what I am doing, I can safely begin my work.
I think it’s important with source control that if you have an issue, don’t necessarily try to fix it if you don’t know what you’re doing. While the source control system is designed to protect you, it’s also the last line of defence between yourself and the project being accidentally deleted. I am 100% sure that whoever is managing the source control will prefer that you ask for help than messing around with the backup for the whole project.
What went well
Through my experimentation, I was able to successfully set up a Github depot, and access it through both Github Desktop and GitKracken, I also played around with the console but the GUI is a lot more convenient.
I already know how to use SVN pretty well and have had to use it to restore projects before so I didn’t need to look into it too much. Instead, I thought about how it protected me and what would have happened if it wasn’t being used, I also thought about the ways I could have lost work as a reminder of how important it is to backup work properly. I finally considered the projects I have worked on and how easy it was to get set up on projects using proper source control. And I noted that source control made the team feel overall more professional and in control.
What I achieved
I realized not only how important source control is for backing up a project, but also how it helps a development team work together. I found that just having a set place where the “current” files are kept and a system of management over who can work on it encourages different work styles among team members, often encouraging better communication and team management at the same time.
What can I improve and how
I found that I have mainly used Subversion clients in the past, and while I do have a bit of experience with Git, it’s not as familiar to me, and knowing how to use it better may make the difference between success on a project and struggling. To remedy this, I intend to improve my use of Git by using Github Desktop on a future project, possibly in the next unit.
Action Plan:
- Use Github for source control on a project
- Continue using Perforce
- Advise teams I work with that don’t have source control of the benefits of source control
Conclusion
Source control is an important and core part of game development, providing not only better security against lost work but also a useful framework for teams to be better managed. The time it takes to set up for new developers is greatly reduced, and while some would argue that it’s a waste of time constantly checking in/out files or creating branches, I would argue that they have probably never lost work to a faulty hard drive before and that they are blind to the other benefits of the system such as progress tracking and accountability. I’ll be continuing to use source control systems, and recommending them to anyone who currently doesn’t use them.
Bibliography
Gershenfeld, A., Loparco, M. and Barajas, C., 2013. Game plan. 1st ed. New York: St. Martin’s Press.
VandenBerghe, J., 1999. Postmortem: HyperBole Studios’ The X-Files. [online] Gamasutra.com. Available at: <https://www.gamasutra.com/view/feature/131811/postmortem_hyperbole_studios_the_.php> [Accessed 8 July 2021].