I currently serve a Producer for three 2D student-created games at the Guildhall at Southern Methodist University. The first in four blog posts demonstrates source control is necessary for any project size.
I am pleased to work currently as a producer for three 2D student-created games at the Guildhall at Southern Methodist University. Each team consists of four underclassmen and I.
Revenge of the Dragon King is a game based on Journey to the West, one of Four Great Classical Novels of Chinese literature. The Dragon Ball manga is also based on the same novel. In Revenge of the Dragon King, players control the Dragon King in a side-scrolling “bullet-hell” game—a game where players must move about the screen in a cautious manner to avoid the bullets of enemies. Raging Sushi: Enter the Roll is a side-scrolling beat-‘em-up in the same vein as The Simpsons Arcade Game, Teenage Mutant Ninja Turtles: Turtles in Time, and X-Men arcade game where players move about the game screen in a pseudo-3D manner. Salvage Runner is a game that looks like Galaga in an asteroid field, controls like SkiFree, and plays like a “bullet-hell” game. In Salvage Runner, players try to dodge asteroids and debris while outrunning an oversized antagonist who constantly pursues the player.
The underclassmen are working on their first games at the Guildhall. Therefore, some individuals have never before used source control. I would argue that source control is necessary for any project size.
TORTOISE SUBVERSION FOR SOURCE CONTROL
For all three student games, the teams use Tortoise Subversion for source control. Below, I demonstrate an example of the Tortoise SVN tutorial from Salvage Runner’s Asset Development Plan document. This tutorial explains how to use Tortoise SVN in detail since some people have never used any form of source control. After the tutorial, I follow up with an example of the importance of source control and then wrap up with final thoughts.
SVN Repository
Enter SMU username and password to login
Initial Check Out from the Network Repository into the Local Working Directory Repository
Right click on Salvage Runner and select SVN checkout
Enter http://ghsrv.ecsrv.smu.edu/svn/c19_Salvage_Runner into URL of repository text box
Enter the location of the working directory C:\Users\(pc)\Desktop\Salvage Runner into Checkout directory text box
Click OK
Local Repository
Right click on the local working directory folder on the desktop to open the menu
Select SVN Update
Updating Latest Files
Move the file to the correct location in the local working directory folder on the desktop
Right click on the file to open the menu
Select TortoiseSVN
Select Add
Adding a File
Right click on the file (or folder for multiple files) in the local working directory folder on the desktop
Select SVN Commit
Enter comments detailing the contents or changes to the contents
Make sure all the files in the commit screen are checked
Click OK
Committing a File
When a conflict occurs, the SVN client creates 3 version of the file in conflict
filename.filetype.mine is the file modified with changes
filename.filetype.rold# is the original file checked out before changes
filename.filetype. rnew# is the file actually on the current network repository
Once resolved amongst the team members, remove .mine or .rnew# suffix and save over the original version
Right click on the corrected file to open the menu
Select TortoiseSVN
Select Resolved
Software Configuration Management
Roger Pressman, Software Engineering: A Practitioner’s Approach, states that SCM “is a set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made.”
During the course of my studies at the Guildhall, I have had the opportunity to use Tortoise SVN and Perforce. Despite their differences, they both allow for software configuration management by controlling change in the project. Source control offers the prospect of controlling change by versioning items. It therefore becomes important to have a solid naming convention for files. The team should decide on a specific and unique naming convention for their game project. In the case of the three projects I currently produce, each team’s specific naming convention resides in that team’s Asset Development Plan document.
Quick Example from Raging Sushi: Enter the Roll
Source control allows users to roll back to previous versions of files in case a committed item breaks the current build of the game. During this past week, the programmer on Raging Sushi: Enter the Roll committed a script that essentially broke all of the collision in the game. This meant that players could walk through enemies, walk over item pick-ups without the ability to pick them up, and through the level boundaries. One might classify the severity of this bug as a “show-stopper”! Luckily, the programmer practices good software configuration management skills and commits changes in the code to SVN regularly. The programmer was able to roll back to a previous build and make the required changes relatively easily.
Wrap-Up
I would argue that source control is important for teams of all sizes. Although these three teams consist of only five developers each, source control has already been a boon. Even better, developers that have never used source control before on all three teams have commented that they already see the benefit of source control.
Read more about:
BlogsYou May Also Like
