By Matt Duffy Chidley
In October 2010, Mad Rat Labs (Chris Parker, Manny Perez, Carmen Scaringe, and yours truly) began work on our student game project, the capstone of our Game Production degrees at the Los Angeles Film School.
We had spent the previous 11 months as the very first group of students to undertake the brand new program. Although labeled a "film school," LAFS houses four separate departments (film, audio recording, computer animation, and game production) staffed by industry professionals and experts. Instead of traditional semesters or quarters, the school follows an accelerated monthly block schedule of intensive full-time classes (30-40 hrs. per week). Double that time for homework and you're talking some epic scholasticism!
As you might have guessed, the Game Production program aims to groom game producers -- specifically by putting students through a broad curriculum of courses in design, theory, audio, art (2D and 3D), level design, programming, project management, and business. The thinking behind this holistic approach is that game development is a highly collaborative pursuit, and a good producer is one who can understand all the disparate components of a project and make them fit together. The program is also geared toward the emerging model of smaller independent game studios where team members are frequently called upon to wear a variety of hats.
During the final month of classes, each of us prepared a game design document and pitch for presentation to a Selection Committee made up of faculty advisors from the school's various departments. The Selection Committee then greenlit two of those designs and divided us into teams to begin work on them.
The other team's project, RISE OF CHAOS, is a splendid hack-and-slash platformer and can be played here.
PROTOCOL: THE FINAL JUDGEMENT was based on a Carmen Scaringe design called "World Wide Judgement Day." The idea was to create a browser-based Flash game along the lines of the film 2012, offering players the same thrilling experience of barely escaping a massive rolling wave of global destruction. The game, we hoped, would pose challenging moral dilemmas in a high-pressure, life-and-death context, providing a forum for examination of how normal society and behavioral norms break down during times of extreme crisis.
What we ended up shipping was an arcade-style, Canabalt-esque "boatformer" with cool background art and a sophisticated radio-play storyline. You can play it here. I'm sure you'll agree with us that all it really lacks is a gun, a jump button, and dragons.
It was an intense production cycle, full of triumphs and frustrations. In retrospect, the roller-coaster experience was a lot like that of playing the game: exasperating, terrifying, occasionally fun, and extremely gratifying to finish.
(Author's Note: Please humor me in breaking with traditional postmortem format by alternating between things that went wrong and things that went right. Adios, legacy postmortem design!)
1a) WHAT WENT AWRY: Unrealistic Initial Concept
Most members of the faculty Selection Committee that chose PROTOCOL's initial concept were familiar with big-budget console titles, and few of them had much experience with Flash games. Several from the film department barely even know what a video game is.
As originally conceived, PROTOCOL was a sprawling, epic adventure featuring four separate gameplay modes, vehicles, NPCs, mass destruction, and all the other lunacy we've come to expect from big-budget action games. Keep in mind that our "studio" was a four-man team of producers (that is, production students) and this was our first game. In hindsight, the task that the Selection Committee had assigned us to was totally impossible.
I really wish the Selection Committee had gone with my idea to do a simple match-three game with pretty gemstones.
1b) WHAT WENT RIGHT: Re-Scoping
Fortunately, we were armed with Agile sensibilities. Instead of freaking out and popping our emergency cyanide, we took deep breaths and decided to tackle the project one mode at a time. Following a brief pre-production, we commenced work on Boat Mode, during which the player attempts to flee the impending apocalypse by sea. Our first sprint would be a "spike," giving us a chance to explore what we were capable of, and hopefully at least yielding a playable prototype.
At the end of two weeks, two things became abundantly clear:
1) We had a pretty fun and functional 2-button boat game concept, and
2) There was no fracking way we would have time to do the other three modes. No fracking way.
We scheduled a meeting with our Executive Producer (i.e. our primary faculty advisor) to discuss the whole thing with him. We pitched our new idea to set the entire game on the boat, and to devote our energies toward fleshing out and polishing this unique core mechanic as opposed to scrambling toward ultimate failure on the original over-ambitious design. We framed it as a learning experience about biting off more than you could chew (even if the truth was that we had been force-fed this particular bite by the Selection Committee).
It worked. Collective sigh of relief from the team.
2a) WHAT WENT AWRY: Waterfall Pressure
Prior to starting work on our final projects, we spent two full-time months in project management classes with a certified PMP / ScrumMaster. Needless to say, Agile[1] was fresh in our minds.It came as a small surprise when our Executive Producer presented us with his traditional timetable of waterfall-style milestones, including a "feature-complete" Alpha, "asset-complete" Beta, and so on. We were confused. Why did the school teach us all this Agile stuff if they didn't want us to use it on our final projects?
The ultimate idea behind these student games, anyway, was to simulate as much as possible what it's like to make a game in the "real world." A trial by fire. Sink or swim. Welcome to the game industry. What the publisher says goes.
Being a bunch of Agile producers, we took it in stride.
2b) WHAT WENT RIGHT: Agile AnywaySomehow, we figured out a way to satisfy the Executive Producer's various requirements and run our show as an Agile one anyway. It's my understanding that producers often find themselves having to shield resistant stakeholders from the off-putting argot of our field's best practices. We kept him happy by showing him user-centric progress, and meanwhile we worked internally as a single cross-disciplinary unit with sprints and shippable slices and all that good stuff.
Especially at the beginning, the Agile mindset helped us all to take responsibility and ownership of the original concept and to make it our own. This was especially crucial for those team members who saw the project as more of an assignment than an opportunity to work on a labor of passion -- the power of self-motivation that Agile fosters became especially apparent when it broke down later on, and orders issued by fellow students (and even teachers) to perform certain tasks were simply blown off. Without a rigorous hierarchy and the threat of getting fired or flunked, Agile (and pizza, of course) proved to be the only way to motivate the chronically unmotivated.
All along the way, Agile helped us to keep from getting overwhelmed, to prioritize only high-value features, to focus on one thing at a time, to timebox tasks and know when to give up on a story and when to adjust the schedule or backlog to accommodate it, and to clamp down on the impulse toward what sometimes turned into explosive-diarrhea-like feature creep sessions.
I don't think we could have done it without Agile. It was our first game, and we really had no clue what we were capable of at any point during the production process. That can be pretty intimidating, ya know? I mean, honestly, how do you make a game? Where do you even start?
3a) WHAT WENT AWRY: Situational Annoyances
As mentioned previously, the idea behind our student games was that we would be working full-time in a real-world studio simulation. In lieu of class instruction, the school would be providing us with studio space, server access, guidance from the faculty, and whatever other tools we might need to make our games.
Unfortunately, for various internal reasons, construction on our studio space didn't begin until the last minute. We moved in even before the paint was dry. We couldn't leave anything in the studio overnight because doors hadn't been installed yet. It took several weeks to get a white board installed. By the time the IT Department got our server access and Alienbrain up and running, it was too late -- we were already in the final stages of our project and our workaround pipeline was already established. Working in a construction zone was a roadblock with which future classes will fortunately not need to cope.
There are advantages and disadvantages to being the guinea pigs for a fledgling Game Production degree program at a media-centric tech school. Despite some areas of overlap, game and film are quite distinct animals, and the existing structures and practices that make sense for film students aren't always suited for games. Again, future students will not have to deal with many of the minor growing pains that we experienced as the school learned to adapt to our needs as game students.
The school's 14-second splash screen / animated short film, required during the intro to our Flash game, is a prime example. Not only did it create a major technical hurdle (it more than doubled our game's data weight and, consequently, download time), it also demonstrates a disregard for the needs of the medium.
3b) WHAT WENT RIGHT: Free Tools (esp. Dropbox and FlashDevelop)
Praise be to "the community" for open-source tools. Our budget was $0, so these were an especially good fit in our case.
In the absence of proper version control, Dropbox really saved the day. It was probably even better than a local server because it allowed us to work anywhere there was Internet, including nights and weekends. (…Huzzah?) Dropbox let us do file transfers, updates, and rollbacks without even really having to think about it. Of course, it's only as good as the user, and we had occasional hiccups when, say, torrent activity slowed a team member's internet connection to a crawl or filled his Dropbox over capacity. It's also too bad Dropbox doesn't have any "read-only" functionality, as the latest build was repeatedly deleted from everybody else's machine by a certain team member who prefers drag-and-drop over copy-paste.
As Lead Programmer, I wanna throw a shout out to my boy FlashDevelop. It's loaded with brilliant features, helps you stay organized, and anticipates stuff for you so you don't have to waste your valuable time figuring out where the bracket you omitted is, or why a variable isn't defined all the sudden (hint: it's because of a stupid typo), or digging through the Flash API to locate the package you need to import ("Is that one thing in TextField or TextFormat? Neither! It's in TextFomatAlign! Thanks, FlashDevelop!")
4a) WHAT WENT AWRY: Division Of Labor / Specialization
The ideal four-person game dev team would consist of an ace programmer, a dope artist, a brilliant designer, and a savvy producer / QA lead / everything else that needs taken care of. Most game schools, I imagine, can match such specialists together, but LAFS’ game department is one of the few that teaches game production and only game production. The result is that our team had four chiefs and zero Indians.
Making a video game is hard. Good-looking art takes real talent and years of practice. Using ActionScript 3.0 and Flash may not be "real" programming, but it ain't exactly what most folks would call "easy." Design… well, I guess anybody can be a game designer, but still…
In our case, we assigned roles based on a combination of our own personal ambitions and our comparative strengths -- meaning that everybody spent some of the time doing what he wanted to do, but also got "stuck" with certain jobs he wasn't qualified for. Usually, we did the best we could, but there were moments when we all lamented our individual and collective shortcomings.
As Lead Programmer I constantly felt the pinch of my own limitations. It's a drag to have to say no to an awesome feature idea because you lack the skills to execute it in time. Of course, working under constraints can spur creativity and give rise to those occasional "happy accidents," the novel and clever workarounds of necessity so common in our particularly young and experimental field of digital game development.
Perhaps this problem can't be helped. Game students need to work on student games, and producers especially need to be able to figure out how to turn lemons into lemonade. Besides, team strengths are seldom optimal in the "real world" either. Welcome to the game industry.
As is likewise the case in the "real world," some of the team members ended up pulling more weight than others. Of course, in the "real world," work is rewarded with financial compensation reflecting (in theory) the marginal value of workers' labor. There are bosses who will promote you for doing a good job (in theory) and who will get on your case if you are slacking (in theory). By contrast, school group projects usually result in the nerdy kid getting suckered into doing everybody else's work.
This isn't to imply that the team didn't behave like responsible adults… most of the time. Because our roles and responsibilities were either poorly or not clearly delineated, there were plenty of occasions when half the team was crunching like crazy while the other half sat around asking what they should be doing.
In retrospect, having a single team member designated in the producer role could have alleviated this. A full-time producer could have helped motivate the unmotivated by keeping the team on the Agile track and spending the time it takes to figure out how to plug people into miscellaneous tasks. Where all else failed, he could have provided some good old fashioned, legitimate-authority disincentive for slacking.
A dedicated producer would also have been able to "run interference" on the constant barrage of well-meaning visits we received. A proper producer could have made the time to demo our latest build, answer questions, collect feedback, and then prioritize (ahem, *file*) suggestions so that the rest of the team might be spared the pressure of trying to please all of the teachers all the time.
4b) WHAT WENT RIGHT: Office Hours
Even if we didn't really know what we were doing, even if some of us didn't always have something to do, at least we were there for each other as a team. By establishing and committing to a regular work schedule early on and being disciplined about making up lost days and hours, we made sure to grind out the legwork necessary to get our game off the ground.
Our mutual minimum time commitment to each other went a long way towards soothing the natural resentment and crankiness that can build up over a long haul. All kidding aside, we began and ended the project with the same sense of "we're all in this together" and every member of the team really stepped up and did a commendable job.
5) WHAT WENT RIGHT: Faculty
There is no accompanying "What Went Awry" for this section. While the independence we were afforded was harrowing at times, and the game we ended up making was completely our own, it's not like we were simply thrown to the wolves.
Our studio was conveniently located across the hall from the teachers' offices and they were constantly dropping by to check on our progress, to give us pointers, or just to say hi and tell us everything turn out all right. They were always available whenever we had questions or concerns, and on multiple occasions we took advantage of their generosity by scheduling tutoring sessions and feedback discussions.
The hardworking, diligent, intelligent, knowledgeable, patient teachers we had at LAFS were the best thing about our experience throughout the program, and we really can't praise them enough, thank them enough, or understate the positive impact they had on us. Thanks, guys!
CONCLUSION
This is the part of the postmortem where I mention all the valuable applied lessons we learned, and how book-learning is great and all, but there's no substitute for rolling up your sleeves and getting your hands dirty working on a real project from start to finish… Let's just skip straight to the part where you hire one (or all) of us, Mr. Bleszinski / Kojima / Molyneux / Wright / Brenda Brathwaite / whomever!
You want to know the most important "what went right" of all? It's the BFFs who came together to pilot this Game Production program and work on these student games. Luv you guys! (Chanting:) Mad Rat! Mad Rat!! Mad Rat!!!
THE END
[1] For those intimidated by this producer-jargon buzzword, don't worry. It simply refers to the best way of managing a project, except in cases when another way would be better. For more, see http://agilemanifesto.org/.
