Introduction
Team Mishap formed slowly, through recruitment efforts sustained by a few students with dreams of competing in the IGF student showcase. In March of 2010, I started pestering faculty and students at Savannah College of Art and Design, in hopes of getting a project started. After the message hit enough avenues, more online and on-campus students started joining up, and in some cases bringing more students with them. As is typical of most student projects, recruits sometimes came and went, but despite the odds, Team Mishap emerged to create Julia’s Magnificent Mishap (JMM,) a puzzle/platformer spanning two interrelated timelines.
What Went Right
1. Submitted to IGF!
First and foremost, we should be proud to have pulled this project through to completion! As a student team, without the structure of a class, without any mentor or guidance, we worked completely independently, completely remotely, and we came through with a playable concept. Often times, without money or grades as a motivating factor, many students are reluctant to work on additional projects beyond their classes. However, the benefits are there for those who are dedicated: experience working on a team, a development cycle to learn from, more work for your portfolio, the exposure of submitting to a competition, and more. Thankfully, we reached enough students who could see the long-term benefits and work together towards a common goal!
2. Developed a unique concept
People who play JMM generally report not having played anything exactly like it. There are definitely games out there that involve split realities of some sort, or puzzles related to the flow of time, but the exact execution of our concept was delightfully experimental and unique. We received a lot of great feedback for our work!
Furthermore, one of the helpful factors in our game mechanic development was prototyping early with Game Maker. Even non-coders were able to put together some playable ideas, which everyone could check out and discuss. We were able to identify early on that controlling multiple protagonists in an action-based game with hostile enemies wasn’t on-target with the casual qualities we were aiming for. Thus, our puzzle focus was born.
3. Strong core team members
One of the deciding factors in Team Mishap pulling through and submitting, despite numerous “mishaps” along the way, lies in the persistence of the core team members. It’s unavoidable on student projects that participants may come and go. Don’t get discouraged. Many times, just a few ultra-dedicated people can really pull the project to completion. When you refuse the possibility of failure, you will get it done. By prioritizing and make tough decisions about what would make the cut, we got our demo finished. We achieved our goal of submitting, learned a great deal, and through our hard work, cultivated a sense of collaboration and trust on the team.
4. Technical strength
Artists and designers were some of the first game development students attracted to the team. In fact, finding a programmer was something we struggled with for many months. During preproduction, we talked about possibly moving forward with Game Maker, but that went against our goal of making the game available to the broadest audience. We wanted to produce something players could easily enjoy in their browser.
Month after month, we put out ads on campus and online, went through our student networks, asked faculty for possible leads. At long last, during the Fall quarter, we gained the star pupil of the scripting class two of our team members were taking. He had created his very own Flash engine from scratch, which also happened to be based on Game Maker! This helped the rest of the team better grasp how the pieces would come together, since we had already been prototyping in Game Maker. Additionally, our project wouldn’t require any middleware to function.
5. Faculty Support
As previously alluded to, on-campus ads were being run for us, regardless of most of the team being eLearning students. By keeping in contact with faculty and staff early on, we gained important support and resources. Beyond the advertising, we gained tools, such as access to Adobe Connect, as well as hosting and domain support. Less obvious was the overall exposure. There was a bit of a buzz about us. We were even mentioned in a faculty presentation about how students collaborate outside of classes!
What Went Wrong
1. Documentation
Solid design documents are a hub of information about the current state of a project. Everyone needs to be on the same page and constantly working towards the same objective, so everything must be clearly cataloged and highly descriptive. With a remote team, the importance of successful design documentation is even more critical. After all, it may be more tempting for a teammate to speculate about missing details than to email someone and ask. Thus, we had some occurrences of incorrect assets being produced, which resulted in frustration for all parties involved.
Despite our best intentions, there was not enough detail or clarity in our documents. Later, bringing on additional team members made this painfully obvious. Time not invested in the game design document early on was later paid for many times over in the form of lengthy chats for clarification and unfortunate misunderstandings.
2. Varying levels of commitment and communication
Having part-time team members was not worth all of the resulting setbacks, but the cost of this practice wasn’t immediately apparent. Part of this problem also draws from circumstance. With a project built on student volunteers, there tends to be a certain degree of anxiety about keeping people on board. This unfortunately helped “part-timer” problems drag on longer than they needed to. The hope that having many hands to share the work would save core team members time eventually became shattered by the reality of having to constantly sink enormous amounts of time into coaching disconnected part-timers who weren’t following the team dialog. If and when part-time team members checked the documents, they still needed chat sessions due to the vagueness cited above.
3. QA was everyone’s job
Lacking a formal QA role to oversee testing, core team members had to dedicate extra time to finding, reproducing, and fixing any encountered bugs. This certainly added more strain to our development process, as the most critical bugs seemed to pop up in the midst of crunch, which also happened to fall on finals.
Our lacking in QA testing also likely took away from our final presentation. While many enjoyed the overall concept of JMM, we later found out that progressing in the demo was confusing to some players. Testing with a diverse player group may have revealed this sooner.
4. Slow team formation, not enough time
Recruiting and team formation took significantly longer than originally anticipated, which meant we started full development with only 1-2 months to work on JMM while balancing our normal assignments and obligations. In hindsight, there really wasn’t much that could be done about this. We can only recommend beginning to recruit for student teams as far in advance as possible, as it may take months to bring together all of the different roles needed for a game project.
5. Bottlenecks in development
Only a few people came into the project with enough Flash knowledge to lay out level objects or properly set up imported assets. Rather than sink extra time into training, it seemed more practical to just get it done. However, at times, the limited team members who could really work with the level files resulted in delays in integrating assets.
A portion of the problem may have been using Flash for a collaborative project. To make progress, only one person could work in the most recent FLA at a time. We had minimal issues coordinating check-ins and check-outs, but there were times team members were held up waiting for other team members to finishing working on the project file.
Conclusions
Both graduate and undergraduate students agree: we learned a great deal about game development through working together to produce our own game demo. Of those who originally participated, the most dedicated members reunited this year and have been working on a new project for IGF 2012. Many of the lessons we’ve learned will certainly help our development efforts.
In particular, there are a few specific areas we’re looking at this year:
Documentation Crackdown
The documentation needs to be able to speak for itself or it has lost its purpose. We’ve been casting a more critical eye on our docs. Is the GDD communicating every detail about the intended design to team members without needing additional clarification? If not, it needs immediate attention.
Regrouping
We’re running a smaller, more dedicated team this year. Our weekly meetings are mandatory, to keep everyone on the same page. Team members who aren’t following along are addressed immediately and production is far less tolerant of participation issues. After all, having additional people on the team means nothing if they aren’t contributing.
Modular elements with less focus on story
Our previous approach, in which various level objects each required their own unique art and purpose based on narrative elements, caused development to be rather slow and resulted in few reusable assets. We plan to focus more on gameplay than narrative this year, and design with reusability in mind so we can get the most out of our work and provide more levels for players to explore.
Scheduling extra polish and testing time
This year, a polish phase has been officially included in the schedule, which should give us some time before the deadline to work out any bugs and overall improve our final presentation. Additionally, we now have a QA person who will be coordinating our testing efforts.
Final Notes
Perhaps one of the most astounding results of working with an independent student team has been the tiny community of friendship and support we’ve developed as a result. Above and beyond meeting times, team members will pop onto Skype to share funny links with each other, discuss the trials and tribulations of being a college student, seek homework help, share our latest independent projects, and otherwise participate in the good-spirited connectivity. Team Mishap may not physically inhabit a common location, but we’re united nonetheless!