CS/INFO 3152: Introduction to Computer Game Development

Assignment 6
Content Repository

Due: Saturday, March 5th at 11:59 pm

In working on a project with a large group of students, you need some way to collaboratively manage your software development. You need a single place to store your code. You want some way to undo changes when another group member accidently deletes all of your hard work. Content repositories should also be used by your designer. It should contain all of your up to date art assets

In several ways, the repository replaces the Game Script from previous semesters. That was a living reference document that kept track of all the group decisions. This was a wiki that had notes on gameplay, mechanics, and level design. The artist would upload their art to this wiki, and musicians or audio engineers would put samples on this wiki as well.

What we discovered was that no one ever updated these wikis until the night that we promised to spot-check them. This sort of negates the purpose of having such a wiki. On the other hand, all of the programmers had an SVN or similar repository for storing the code. So we have decided to make this the focus instead, and encourage you to put everything into a repository.


File Sharing vs. Version Control

The simplest form of a repository is one that simply shares files. The most popular form of file sharing right now is DropBox. Everyone can get a free 2GB dropbox account, which is pretty good as long as you are not trying to share large media files (which unfortunately does happen in this course).

To use DropBox to share files, one person makes a folder in the DropBox account and then shares it with other users. When this happens, everyone gets a local folder on their computer with these files in it. This folder is synchronized with the DropBox server, so that when the files change on the server they are automatically changed on in your local copy. Even though the DropBox central server only retains one copy of the folder, sharing counts against the quota of everyone in the group. So if you have a 1GB shared folder, everyone sharing it has 1GB less to use on their account. Not ideal, but this is DropBox company policy.

A much bigger problem with a file sharing service like DropBox is collaborative editting. You are relatively big teams, and it is very possible that two of you might be working on the same file at any time. What happens in that case? Well, in a file sharing service, one of you uploads to the service and that gets pushed out to everyone else. If the second person has the file open in a program, those changes may or may not appear in that program. And once that person saves, those new changes (without the work of the first person) get pushed out to everyone. Hence the second person wins, and the work of the first person is lost forever.

This is one of the primary reasons for version control. In version control, the central storage service keeps track of when a file is updated (and by whom). However, unlike DropBox, it does not automatically push the changes to the local folders. You must first request an update by fetching it first. Hence, if you want to edit a file, you first fetch it. When you are done editting (for the time being), you check in all of the changed files to the central repository.

Because the respository tracks changes, it knows if you have tried to check in changes without first fetching the file. Because this means that you might be deleting the changed made by the person before you, the service first tries to merge the files. Because the vast majority of what goes into a code repository is source code or text files, it is often pretty good at doing this. If it cannot, it will refuse to check in your file and force you to handle the merge yourself.

Because the repository tracks the complete history of a file, you can always rollback or revert to a previous version of a file. This is really useful if there is a mistake or the new version contains bugs. Nothing is lost as long as it was successfully committed to the repository.


Version Control vs. Binary Files

Version control works because softwares source code is primarily text files. Each time you upload a change, it does not store the whole file. It only stores the differences in the file. This allows you to rollback to any point in the past without taking up a lot of storage space.

However, these are games, and you are not just working on source code. You have art and music assets. And sometimes you might accidentally stick a compiled binary in your repository. Version control systems really, really do not like "binary" files (e.g. a file that does not hold text, and stores binary information for execution or access by a specialized program). It cannot merge changes ever. And the only way that it knows how to track changes is by storing a brand new copy to the server every time you commit. If you have made 100 changes to that PNG file, then the repository is storing 100 different PNG files, not matter how small your changes.

Binary files are where the file sharing service is ideal. You cannot get version control anyway, and you do not want to fill up your entire repository disk quota with multiple copies of the same binary file.

Unfortunately, for you, that means that you will need to have two different repositories. You need one for your source code, and one for your binary files (art, music, executables). There are people still looking at ways to seamless integrate binary files into version control systems, but there are no good answers right now.


Course Repositories

We want access to your source code repository and would like access to your binary assets, but the latter is less important (see below). This means that you are required to set-up two repositories.


GitHub

We want you to use GitHub for your version control of your source code. While GitHub will support binary files, it has all of the problems that we mentioned above. In addition, you will have roughly a 1GB quota on this repository and you do not want to eat up all this space with 100 versions of the same Photoshop file (or worse, binary executable).

Before you do anything at all, you will first need a GitHub account. Register for an account on the sign-up page. You can either sign up for a student account or an open-source account. The benefit of a student account is that you are given up to five repositories that you can use for class projects. The open source account means that all of your repositories must be open source; you probably do not want this.

After you get your GitHub account, you have a choice. You may use one of your own repositories or we can provide you with one (so it will not count against your five). If you would like the latter, please send your account name to Jessica Depew. We will then add you to a repository, at which point you can start to check in files.

In addition to the account, you will need a program (or programs) to work with GitHub. Git is actually a suite of programs, primarily designed for the command line. However, another nice feature of GitHub is that it has its own Native GUI to make everything easy for you. You should download this application and follow the set-up instructions on that page.

Assets and Binaries

As we said, you should not be using GitHub to store your media assets or your binary executables. You should use another file sharing service for this. You are welcome to use DropBox for this but in that case, we do not want you to share your DropBox folder with us. Your instructor's meager free DropBox account would not survive sharing with the 18 teams in both introductory and advanced game development this semester.

You are also welcome to use other options such as Google Drive or Microsoft Skydrive. We are not picky. Use whatever file sharing service best suites your productivity.


Submission

Due: Saturday, March 5th at 11:59 pm

We want two things from you. First, we want access to your GitHub repository. If you have your own repository, invite your instructor (GitHub ID: WalkerWhite) to join. If you need a repository, e-mail Jessica Depew. so that we can give one. There is nothing to do in CMS for this step.

Second, we want evidence that you have set up a file sharing service for your assets. If you use either Google Drive or Microsoft Skydrive, feel free to share the link with your instructor. Otherwise, what we really want is just a screenshot of the shared directory uploaded to CMS. That way we can confirm you did something.