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
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
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.
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.
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
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
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.
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
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.