In May of 2009, Alex Seropian, DePaul's Game Designer in Residence, had the idea of creating the "DePaul Game Elites," a game development project that would recreate the experience of working for a professional game development company.
Forty DePaul Game Development and Animation majors applied and interviewed for the team, and this group was narrowed down through testing and interviews to fourteen (a fifteenth member was added later in development), led by Alex and four other faculty advisors.
Our mission was to create and submit a game to win the Independent Games Festival Student Showcase, and also be commercially viable. Our mandate was to create not only a fun game, but also an innovative experience that had never been seen before. The resulting game was Devil's Tuning Fork.
The team started a concept boot camp in June of 2009, which lasted almost four weeks. We brainstormed ideas, cultivated concepts, and then began prototyping the most promising options. When the prototyping phase came to an end, one idea stood out. That idea, with the working title "Echo", attempted to visually translate the echolocation ability of dolphins. This concept proved to be both interesting and innovative. From there we moved into true production, submitted our game to the IGF, and released our most complete build, v 1.21, in early December.
Throughout the accelerated development cycle for Devil's Tuning Fork the team overcame obstacles and learned valuable lessons. Some things were done right from the beginning and some things just never seemed to come together. The following is a presentation of both the ups and downs, the good and the bad, of the Devil's Tuning Fork development cycle.
What Went Right
1. Concept boot camp
Right from the start, Alex Seropian, our project advisor and DePaul's Game Designer in Residence, put us through "concept boot camp". Concept boot camp occupied the first four weeks of development. Our research of past IGF games showed that most shared a common trait-an innovative game mechanic-so we made this our top priority. During this stage, each member of the team had a responsibility to bring at least two ideas to the table in the form of one page pitches, accompanied by a rough sketch. Some ideas were elaborated into what Alex called "eight pagers", which include titles, one-liners, game procedures, technical estimations, and concept art. Once the "eight pagers" were completed, the team voted on two games to take into the prototype phase.
This stage not only gave the team a chance to get to know each other by putting individuals into brainstorming groups, but it also produced some truly interesting ideas. Often the initial pitches sparked other ideas, which helped get the ball rolling. After ideas were presented, the team was split into smaller strike teams to get different perspectives on them. The process encouraged different perspectives on each concept, and helped us make ideas stronger.
This process was repeated until we narrowed down to the two most promising concepts. The team was split into two groups that worked intensely for a week to make a playable demo. This allowed us to see if the ideas could actually be implemented. At the end of the boot camp we were satisfied that Devil's Tuning Fork could accomplish all the goals we'd set.
Had we not succeeded at this stage, our project would have been lost. We listened to more than two-dozen ideas and only developed half of them. Concept boot camp not only produced the idea for our game but also prepared us for how to be a team. It was our first step, but it was the most critical-without an innovative game mechanic idea we'd have no shot at the IGF.
2. Team communication
Because some people on the team had never worked with one another, communication could have been a problem; however, the team took it upon themselves to create a friendly, cooperative, and professional working environment that would allow a successful completion of the project. We facilitated team communication through proximity, weekly Skype meetings, and our team wiki.
First, we all worked in the same room. This allowed each discipline to easily pose questions to each other. Designers were able to explain puzzles to programmers and artists could communicate problems they were having with level layouts. This immediacy allowed us to quickly iterate and keep each other up to date.
Second, we held two Skype meetings every week, one on Sunday night and the other on Wednesday night. During the meetings, each department updated the others and asked any questions they had. The hour-long chat was essential to figure out where each discipline was at in regards to progress made and if there were any bottlenecks that needed to be discussed. Since everyone's time was spread between school and work as well, the meetings were a quick and easy way for us to communicate important information.
Lastly, we had a wiki page where we stored all of our information. Any team member could access this information at any time. We stored meeting conversations, task lists, videos, level layouts, concept art, schedules, and contact information all in one place. At the end of the project the wiki page turned into an archive of the project's history. Each development phase was documented showing the journey from our hiring to the project's finish.
There are plenty of other examples of team communication to go along with the above mentioned three and they all helped us become a tighter, more cohesive team. There was always room for improvement, but the communication between team members became a major benefit throughout the development.
