The Misadventures of P.B. Winterbottom is a game set in a silent film world filled with mischief, time travel, and delicious pie. By harnessing Winterbottom's time altering abilities, players can cooperate, compete against, and disrupt their past, present, and future selves.
Winterbottom was started as my graduate thesis project for the University of Southern California's interactive media program. The concepts were developed throughout various courses at USC during the three years of the program. Looking back through my coursework, many of my past projects explored themes of replay, alternate timelines, and looping.
As a first-year student in Steve Anderson's Survey of Interactive Media class, I was shown the short experimental film Tango by Zbigniew Rybczyński. The film consists of one stable shot that layers looping characters on top of each other until the scene is full of complex choreography. The film resonated with me, and I started to think of a game system based on looping to generate content that would build in complexity.
At the same time, I had a pipe dream of a game that would capture the essence and the charm of an early silent film. I studied film production as an undergraduate and always wanted to put as much of my previous leanings into games.
At some point around thesis proposal time these two ideas merged, and Winterbottom was born.
The game's style is macabre, much like the drawings of Edward Gorey, full of unfamiliar proportions and quirky obstacles. Although the game is 2D, 3D models were used, allowing for a very stylized aesthetic. Many early films influenced the look and feel of Winterbottom, from early silent shorts like Trip to the Moon and Metropolis to the silent comedies of Keaton, Chaplin, and Lloyd -- Safety Last, Modern Times, The Freshman, and Steamboat Bill, Jr. Needless to say, during research the team got to watch a lot of awesome movies.
The music, composed by David Stanton of USC's Thornton School of Music, builds from rag-time piano to a polychromatic landscape. Blending a gothic sensibility with the early jazz idioms characteristic of silent films, the music is both dark and lovable in the world of ever-present paradoxes.
In 2008, Winterbottom was selected as an IGF Student Showcase winner. It was a great achievement, but getting to that point was not a smooth run. The game iterated through many phases (including a build in XNA and Flash), survived interdepartmental struggles, and housed a rather large cross-disciplinary student team. Through all the ups and downs the producer Paul Bellezza and I fought to do what was right for the project at all times.
What Went Right
1. Student Team dynamic. When collaborating with students who are only working out of passion (and without pay), it becomes crucial to keep them motivated in the right ways. Pizza only goes so far. At a design school where everyone has his or her own projects to work on, it can be a challenge to get a team together outside of a class. Team Winterbottom consisted of graduates and undergraduates of the interactive media program, a composer from the Thornton School of Music, engineers from the Viterbi School, one Marshall School of Business student, and a high school student applying to USC.
We knew from experience that if the team wasn't fired up about the project, we were not going to be able to pull off what we needed to do. When a team believes in, and is passionate about a project, their enthusiasm manifests in the quality of the game. We've found this passion to be a more important stimulus than financial compensation or class credit.
One of the ways we motivated the team was by making everyone feel like they were in on the design and giving everyone ownership of certain aspects of the design. By letting everyone into the project as early as possible (and I do mean everyone: artists, engineers, web producer, team janitor) we were able to establish a high level of motivation. Along those same lines, I understood as a lead designer that people joined the project because they loved the idea, not to work for me. I feel that some classes in creative schools are set up to run this way, mirroring the professional game industry.
We kept the team dynamic strong by orchestrating team-bonding exercises when we could. Little things -- watching old movies, going for pie, and sneaking everyone into E3 -- made a big difference. We even worked on a completely unrelated game, The Wrath of Transparentor, as a bonding experience. Transparentor was a quick five-day project that was done very early in the team's creation. We learned an incredible amount from this separate project about everyone's strengths and weaknesses, and it helped to keep us fresh.
Although we brought in everybody early, there was still a lot of work to do prior to setting up the team. To attract students to work with us, we needed to sell the vision of the game through a prototype. The basic mechanics were all prototyped in Flash.
I took it upon myself to learn to code in order to prove the game design through prototypes. Student designers can sometimes come off as over-reaching, and I wanted to prove to the team that the game could be made, that they could rally behind something that was real. Jamie Antonisse, one of the level designers, said of the concept, "Winterbottom was a solid design with small holes in it [that] I knew I could help fill."
Our team dynamic revolved around setting concrete roles. Although everyone was given a chance to weigh in on the design, we all stuck to our roles once production started.
Paul Bellezza (who has since become my business partner) was a rare find in a design program because he actually wants to produce. He fills in my weaknesses and we balance each other out. I was lucky to be able to partner with him on earlier projects and learn how we work together best.
One piece of advice I have for game design students who are trying to get a project off the ground is this: Team up early on with someone who can fill a producer role. On past projects where the roles were blurred, the vision suffered.
Along those lines we also came up with a team mantra: "Design individually, decision by committee." We had tried designing levels as a group, but found it more effective and coherent when designers create levels on their own. Every week the team would give feedback on levels that worked or didn't work, and we would vote for the levels that we would continue with.
2. Rapid paper and digital prototyping. One of the first things students learn in USC's Interactive Media program is to prototype early and prototype often. This includes paper prototyping, which was key in quickly laying out level designs and puzzles.
Later, we were able to create a level design editor in Flash that let the students rapidly implement their paper levels to test the usability and fun factor. The level editor was especially useful in fueling creativity and letting designers implement their ideas. More than 120 prototypes were created in Flash during the pre-production of Winterbottom.
Rapid digital prototyping was especially helpful because we were playing with an untested game mechanic. The idea of recording the game character/player, looping his actions, and creating a paradox made all of our brains hurt at the start of the project. Prototyping helped to ease the pain as well as to discover new twists on the mechanic.
One problem we discovered through early prototyping and play testing changed the entire game. There is an inherent problem with any recorded-based play that requires the player to replay his actions. There's a harsh lose case where the player has to replay not only his current self, but also all past selves. Say you need to jump on the head of a clone and you miss the timing. With six or more layers of recorded play, the game can become extremely punishing. I discovered this early and made Winterbottom's actions loop so you never lose by missing the timing. The team decided to minimize all lose cases so the player could just have fun within the system. Overall as a mechanic, looping enabled some interesting puzzles.
3. Sticking to the core. Once the original mechanics were set, we designed around what we had. Oftentimes in student game development projects, features and ideas spiral out of control. We aimed to get to the core of the game quickly and put that core at the forefront.
I created a mock-up instruction manual that served as a design guide for everyone to follow. This was easier to reference than a lengthy design document and it made it clear to everyone that we were not making Winterbottom the First-Person Shooter. The team knew we were playing with enough innovative material and that we did not have to reinvent any wheels to get our ideas across. Side-scrollers are well understood at this point in video game history and we used their established language to convey our ideas.
Another way we kept the design from spiraling out of control was to hold a "blue sky week," when any idea could fly. We prototyped most of the offbeat ideas and discovered some intriguing gameplay, which didn't always fit the game. One of my favorites was a paint level, where actions were trailed, tinted, and stamped onto the background to create art. Another blue-sky prototype had the player control 50 Winterbottoms at once. Blue sky week kept the team fresh. A few concepts in the final game actually did result from those open-idea weeks, such as creating a bridge made of Winterbottoms.
4. Advisors. We had an amazing opportunity to work with some great people both inside and outside USC. It was important to make sure my thesis faculty advisors, Chris Swain and Tracy Fullerton, and I were in constant communication. If your school has faculty who are willing to devote time to student projects, I highly recommend embracing them.
USC also gave us the opportunity to have industry veterans Jonathan Blow, Doug Church, Dan Arrey, and Carl Schnurr aboard as advisors. These people bring real experience to the table and steered us into the right direction many times over.
Even though these industry advisors are extremely busy, a little of their time can go a long way. A one-hour meeting and an email chain helped immensely on focusing the project ideas and getting to the core. One particular batch of feedback from Doug Church yielded crucial thinking about creating a mixture of sandbox play with scripted puzzle events.
5. Submitting to the Independent Games Festival. Submitting Winterbottom to the IGF isn't something that went right solely because the game was accepted. Submitting forced us to set a stake in the ground and set hard deadlines.
Two weeks before the submission deadline, we had some bare-bones prototypes that showcased core features of the game. We did a team gut check and decided to press forward, lock off new features, make huge cuts, and pull the team together to submit. Even if we hadn't made it into the IGF, this crunch was absolutely critical for pushing the project forward.
What Went Wrong
1. Not trusting our gut. In addition to being my thesis project, Winterbottom spent a semester as an Advanced Game class project that for the first time ever joined the schools of engineering and cinema. Before the fall semester began, we had a meeting with the lecturer who was spearheading things on the engineering side to approve our project plan. When he discovered we were planning to make the game in Flash, he strongly advised against it, stating flatly that Flash was a poor engine for a game.
He suggested that we build the game from scratch using Ogre 3D, as many of the student engineers were familiar with that program and because programming a 2D game would not provide a "valuable" learning experience for the engineering students. Against our better wishes, we complied.
As the class began, we realized that we wouldn't be able to get most -- if not any -- of the functionality of Winterbottom working in Ogre by the end of the semester. A separate engineering team was added to build an Ogre-specific level editor that would suit level-building in both Winterbottom and another student game project. This became a disorganized mess. We wasted a month on this path. The level editor itself wouldn't be ready by the end of the semester, and 3D was a terrible idea for Winterbottom. We decided to press on with the Flash build outside of the class.
2. Recruiting through a class. Before production, we knew we needed to recruit a team, but weren't sure how to do it. Jenova Chen (a former USC student who now owns thatgamecompany) advised me to hold open meetings for anyone who was interested in the project. Whoever still showed up after the third week of meetings would be the team. We followed this advice and were able to form our core team.
Unfortunately, we thought we needed more engineers.
We shouldn't have expected that enrolling in a class would magically grant us the right people for the project. To satisfy the requirements of the class and be granted engineers we had to develop the game in XNA. This was our compromise with the course instructor after many arguments about whether Winterbottom should be in 3D.
Due to the perseverance of our student engineers (who learned a new language), we ended up with an awesome demo of a stripped down version of Winterbottom running on the Xbox 360 at the end of the semester. Meanwhile, our high school wiz kid Asher Vollmer was tinkering away, coding the Flash build. Even though the XNA build was technically superior, the Flash build suited the game better because we could implement the core gameplay faster and easier. It turned out to be very fortuitous that we pressed on with the Flash build because it got us into the IGF and is now what the game resides in. But managing two development cycles simultaneously taxed the teams enormously and nearly broke all of us.
3. Doing double duty. For the majority of the project, I did all the art. Being a lead designer and main artists for a project of this size was obviously a bad idea. At first I thought, "Oh but it's easy for me to generate art," and, "I want that certain look," and, "It will take too long to micromanage -- I'll just do it myself."
While this worked well at the start of the project, it was immediately apparent during the crunch before GDC that it was a terrible idea. I should have used an art team. This led to many stressful days and sleepless nights of pure production. Luckily, Vincent Perea stepped up to the plate to help. Bringing him on earlier in the project would have been a great idea.
4. Managing vs. developing. At one point, our team grew to 25 people, a bad predicament for a student project. We were then creating large spec docs for features we weren't sure we needed to accommodate the amount of people now assigned to the project. After a week of managing this large team, it became clear that the core leaders were spending more time managing than developing. We soon downsized back to our seven core people so we could focus on working on the gameplay instead of ancillary tools and non-crucial assets.
5. Cross-disciplinary courses. A 3D Winterbottom game would have indeed been more of a technical challenge than a 2D Flash-based one. However, a slew of technical problems would have arisen that have nothing to due with the core gameplay. These problems were a non-issue in 2D and Flash; thus, we were able to focus all engineering on what was best for the project.
Game courses in engineering schools tend to be focused on solving technical challenges, whereas design programs focus on the innovation of gameplay. To produce the best possible student game, these two forces need to collaborate.
For interdepartmental game classes to work, I feel the focus should always be on what is best for the project. Collaborative game development should be approached as more than a system of technical features. In the case of Winterbottom, learning to work on a team was more important to the student engineers than getting the recording features to work. Although learning to solve technical challenges is extremely important for students, in a class where the object is to make a good game, the focus should be on just that.
Fortunately, the class was an amazing learning experience for both the students and the faculty, and since, it has been dramatically restructured to better serve both departments' needs.
Matt Korba is a MFA student in the Interactive Media Department at USC. In partnership with Paul Bellezza, he has formed The Odd Gentleman game company to create future game projects after graduating in May.
Team Winterbottom: Matt Korba, Paul Bellezza, Asher Vollmer, David Stanton, Jamie Antonisse, Ian Dallas, Phillip Gregorchuk, Dan Howard, Katie Johnson, Matt Barney, Tim Jones and Vincent Perea.