| |
|
| Entry #11: Stick it to The Man |
|
| November 16th, 2008 | Neil Rodrigues |
| |
Despite being a completely different phase of development, last month’s entry was still closely tied to working directly with the game. This month’s entry looks at game development from a different perspective. For the most part, I’ve described game development using a step-by-step model. Each game element was based on its predecessor, and concept eventually becomes the end product. In reality, it’s not such a smooth workflow. There’s a lot of shuffling back and forth between phases, and some things get finalized long before others. The whole decision-making process behind these actions is called project management.
This entry will explore the different tools and strategies we’ve used over the years to manage The Silver Lining. I’ll give a brief glimpse and overview on how each system worked, as well as the advantages and disadvantages to using each one. Keep in mind that a system is only as good as the needs it serves, so something that didn’t work for us might work very well for you, or vice versa. |
| |
| |
Reference Material
When managing a project, there are two key things you must continually monitor: tasks and staff. A task (a.k.a. an assignment) is a unit of work directly relating to a game element. A staff member is a person assigned to completing a task. In the real world, staff members will complete one or more tasks weekly because they are paid to work a specific number of hours each week. With TSL staff, productivity is very unpredictable. Our staff members are unpaid and can only work when they have free time. As a result, one week they might complete all their tasks and more, while the next they cannot even complete one. This inconsistency makes project management extremely difficult.
When a staff member is able to complete a task, that task must be approved by a director before it is deemed complete. Once it is approved, the staff member continues on to his or her next assignment. This sounds simple and straightforward, except when you consider that a staff member could be working on several tasks at once, and that each director manages a department with many staff members. The director also has his/her own tasks to complete each week, and may need to seek approval from other directors for sign-off on certain tasks.
Without the approval process, game elements might get placed into the game when they were not done correctly. This results in work that must be redone by the original developer or someone else that can find another creative way to fix the issue. Or, it results in bugs that testers or end-users will eventually find. The only way to stay on top of all these things is to have a system in place to manage this communication of information. |
| |
| |
Yahoo Groups
Outside of MSN Messenger and e-mail, the first groupwide tool used for team communication was a private Yahoo Group created specifically for TSL in 2001. The group had some webspace for uploading files (around 20MB), a section for polls, member list, and photos. But, the major selling point for the group was its message board. It functioned more like a mailing list than a message board, and whenever a new member was added to the group, they were also automatically added to the group’s mailing list.
Figure 1: Screenshot of TSL Yahoo Groups
Whenever someone posted a message, it would simultaneously get converted to an e-mail and get sent out to everyone in the team. Whenever someone replied to an e-mail, it too would automatically get broadcasted to everyone, while also appearing on the message board as a reply to the original message. Similarly, when posting or replying to a message on the message board, the message would get converted to an e-mail and be sent out to all.
This seamless integration between e-mail and group message board greatly helped the team stay connected. There was no need to remember to Reply to All, or constantly login to the groups to see what was new. Every time a new file was uploaded, a new message would get sent out. Every time someone commented on something, or wanted to discuss something, everyone was immediately notified. Rather than staff having to seek out information, it was pushed directly to them.
There were also several disadvantages to using Yahoo Groups. The webspace of 20MB was very limiting. It would quickly fill up from people submitting assignments for approval, so files would constantly need to get saved elsewhere and deleted. E-mail webspace had a cap of 1 or 2MB at the time, so large files could not simply be sent via e-mail like they can today.
Besides storage space, bandwidth was also an issue. Yahoo placed a limit on how many times a file could be downloaded daily. Once the daily bandwidth quota was reached, no one else was permitted to download the file. I don’t remember what the limit was, but usually once 9 or 10 people downloaded a file, the groups would deny anyone else access to the file for the rest of the day.
Since the team was moving from black and white sketches to coloured drawings, this storage and bandwidth limitation was quickly becoming a nuisance. It was becoming more and more apparent that it was time to move the groups from a free site to an actual website. |
| |
| |
KQ9 Groups
In February 2004, we had scrapped the old and outdated Perl-based public website and switched to a new PHP-based one. Along with this change we created a second private website, accessible only to team members. When building it, we tried to base the functionality of the team-based site off the Yahoo Groups. It mainly consisted of a Team page to list members contact information, a Forum for discussing topics, and a Files section for uploading assignments.
Figure 2: Screenshot of KQ9 Groups
The bandwidth and storage limitations were no longer an issue since it was using the same web server as the public site, whose limits were far greater. Additionally, it was easy to customize and modify how each part of the site would work, since I had built and integrated them together myself. For example: we were able to add a chatroom (reminiscent to the TSL Chamber) for weekly meetings, display who’s currently logged in on each page of the site, store login credentials per session so that you weren’t constantly being harassed for a password, etc. It was not possible whatsoever to add features like these in the Yahoo Groups. We were only permitted to add content.
Unfortunately, the KQ9 Groups had their own share of problems. There was no seamless e-mail/forum integration. The Forum had the ability to notify everyone when a new thread was created, but the content of that message did not appear in the e-mail notification. Additionally, no notifications for replies were sent out until the user logged in and read the thread. Replying to e-mail notifications was futile since they went to the webmaster e-mail address, so staff would manually have to be rewrite their message again. Due to this hassle of being forced to login to check what’s new, the Forum quickly became inactive. We instead used e-mail forwarders to contact everyone in a department or everyone in the team at once.
Additionally, with there being virtually no limits as to how much people could upload or download, the Files section of the site quickly turned into a landfill. The Yahoo Groups had files organized by department. We initially mimicked the same structure here, but it was deemed too cumbersome for directors to have to navigate through many folders to find assignments. Instead, we opted to having one folder called “NewFiles” where everyone uploaded their assignments. Despite the files being automatically prefixed with a date stamp and username, it swiftly turned into one big mess that no one had any desire to sift through and clean up. |
| |
| |
Assignment Table
One thing we quickly discovered from the disorganization of e-mails and files is that we needed a better way of tracking assignments. From 2003 to 2004, the directive staff would discuss over MSN and e-mail what the current status is on assignments and areas of the game. We created several Excel docs, listing all game elements with their development phases, and the status of each one, namely: Unstarted, Work in Progress, Re-use (from elsewhere in the game) or Done.
Figure 3: Screenshot of Chapter 1 Excel Document
These seemed to be very effective at showing team progress, but the files had to constantly be manually updated every time a new assignment was submitted. With a team of 30-40 people and several files being uploaded daily, it became next to impossible to keep these spreadsheets up-to-date. It also became a problem, because when two people made changes do the spreadsheet in different places, someone would have to manually merge the changes or copy from one file to the other. Otherwise, the changes would be lost. We needed something more centralized and easy to maintain.
To solve this, in 2005 I created a page in the groups with a table of assignments. It was based on an Excel sheet which listed the months of the year on one axis and the staff members on the other axis. Each staff member had four entries, which corresponded to weeks. The intersecting value would represent an assignment for a staff member, on a particular week of a month of the year. 
Figure 4: Screenshot of Assignment Table
Each cell in the table had an associated colour to it, which represented the current status of the assignment. Based on the 4 status states from the Excel sheet were the following 8 more detailed states: Unstarted, Work in Progress, Pending Approval, Late (with a justified reason), Past Deadline, and Done. The assignment table was broken down for each staff member, but there was also an overall tally to show overall progress.
The assignment table was used off and on in 2005 and 2006. Every director had the ability to add/remove/modify assignments, and update assignment status. Status updates were provided by the staff through the use of weekly progress reports. At first, it was each department head’s responsibility to update the assignment table for their own staff, but it eventually became the responsibility of the project co-ordinators to remind staff to submit weekly reports and to update the table.
While the table was very good at presenting an accurate look at overall status, there were more assignments entered in than worked on, which ended up skewing the numbers. For example, as you can see in the above screenshot, about 72% of assignments are unstarted, and only 4% were completed. The rest were usually marked as work in progress. This status usually happens when staff members take longer than expected to finish, due to hectic schedules in real life having higher priority.
We first used Late and Past Deadline for these sorts of situations, but some people would instead work on future assignments when they get stumped, or take longer because the assignment itself is more complex than originally anticipated. In these situations, the same assignment would be duplicated, and end up having both a WIP status one week and a Done status the next.
The other problem with the assignment table is that it was only able to hold one year’s worth of data at a time. When a new year started, unfinished assignments would need to be re-entered somehow, while still including the previous unstarted assignments. Needless to say, the assignment table eventually became too much of a burden to maintain, and showed status that reset yearly rather than accurately displaying overall progress. |
| |
| |
Wiki
Once we realized that the Assignment Table wasn’t really cutting it, we decided to use an alternate way of tracking team progress. Instead of looking at team progress as the overall status of staff assignments, we decided to look at team progress as the progress of scenes themselves. In 2007, we started to use a Wiki which had pages for each scene status. On the status page would be details on all required game elements for that scene. Everything from characters, animations, music, dialogue, etc. specific to that scene would be listed in one easy to find location. This saved a lot of time which would otherwise be spent in trying to contact people for information, or having to rework something where people originally guessed & made assumptions due to lack of information.
Figure 5: Screenshot of Wiki
After six months using the Wiki and seeing some positive results, we tried a slightly different management process. Rather than having individuals submit assignments for things all over the game, we tried dividing everyone up into three teams – each responsible for a set of scenes. Each team had its own 3D artists and programmers, but there was some overlap in other areas. For example, narrations could only be recorded by the narrator, Amy, so she had to be on all 3 teams. Similarly, music tasks for all 3 teams were handled by Austin.
In theory, this plan should have worked. People would have 1/3 less work than before. Unfortunately, not everyone has the same amount of free time to work and not everyone has the same amount of expertise. Adding to this the unbalanced workload I mentioned in the previous paragraph, and the result was a mishmash of progress with no single team completing any scene 100%. However, one team goal was accomplished: almost every scene was fully playable. It was finally possible to travel to and from all scenes in the game, and see dialogue for most characters and almost every object. It was an exciting time because finally the game started to feel like an actual game.
After reaching this milestone, we started to notice all the minor bugs on each scene which were ignored because they didn't prevent a player from completing the game. There was a section on the scene’s wiki page for listing bugs, so we first started reporting them there. The bug lists were simple. Each bug had a description, assignee, reporter and status. The problem was that not all scenes had completed wiki pages yet, and with the bugs existing in almost every scene, the lists quickly became difficult to monitor and maintain. People would forget to report bugs or forget to update the status. Or, they would be unable to report certain kinds of bugs because they affected all scenes or a user interface screen, rather than any scene in particular. |
| |
| |
Redmine
Finally, in August 2007 we were able to find a project management tool that solved all our problems. Redmine is essentially a database-driven issue tracking system. Issues (i.e. assignments and bugs) are logged into it, and assigned to staff members. Staff members can add feedback, change issue status, add attachments, etc. Notifications are sent to everyone as soon as an issue is created or updated. It also has the ability of integrating with Subversion, which is our centralized repository where development on the game is done.
Figure 6: Screenshot of Redmine
Redmine has other handy tools as well, such as a wiki, files section, forum, calendar, a roadmap (which lists all issues tied to a specific milestone/release) and an activity section which lists overall recent activity. The most used feature is, of course, the issues section, which can list all issues or filter them by some criteria (i.e. all open issues assigned to me, or all issues set to re-test). Having the ability to quickly find, update and resolve issues is invaluable to productivity. There no more time wasted wondering about the current status of something, or on what’s left to be done.
While Redmine turned out to be the best management tool for TSL, it also had its share of problems. It was tricky to install, kept crashing daily for the first few months due to a software glitch, and felt like overkill to use for creating assignments. However, once development shifted from implementation to testing, it proved to be the most reliable and accurate system to date for keeping everyone up to date and organized. Since the tool is database-driven, historical data is constantly being stored. This data is particularly useful in creating productivity statistics which are used for highly accurate reporting of overall progress, as well as for planning upcoming milestone dates. |
| |
| |
If there’s one thing for certain, it’s that managing a large project like TSL is far from simple. We constantly used different planning techniques and tools over the years, mainly because as the project’s needs changed from phase to phase, its management had to change with it. When the project was in its infancy, the focus was mainly on maintaining team morale and staying close-knit. As the project got more and more elaborate, so did our means of tracking tasks and progress. Now that the project is nearing completion, the focus is less on assignments, and more on finding and fixing issues.
We were able to accomplish this with Redmine, but that’s not all it allowed us to do. I briefly mentioned that another benefit to using Redmine versus any other tool is that it allows us to peer into the future and actually predict the unknown. Next month’s entry, which also happens to be the last in our Journal Special, will talk about this in great detail. We will discuss an important topic that greatly impacts game development but is often overlooked. Don’t miss out, because I will finally address the questions that you, the public, really want to know about the game.
>> Comments |
| |
|
|
