[In this detailed postmortem feature, indie developer Christopher Totten charts the creation of E4 Software's self-published mobile platformer SWARM!]
Self-sufficient indie development is both the most accessible and perhaps most daunting parts of the game industry. On one hand lies the creative freedom of not having to answer to publishers, on the other is the problem of productivity and self-motivation that comes with working in a non-traditional environment - houses, garages, basements, coffee shops, etc. Indeed, the rise of mobile devices and app stores as platforms for games makes indie development all the more enticing, with new studios in a gold rush-esque run to make the next Angry Birds.
For many this involves balancing their 9-to-5 jobs and families with nights and weekends spent in game development. Those that do succeed in making a game must then deal with the challenges of app discovery, self-promotion, and securing reviews. How does a small developer thrive in an online environment focused on bigger and more easily visible games? These are the issues that e4 Software, a small Maryland-based studio comprised of three Boeing employees and one George Mason University (GMU) professor, is trying to handle following the release of their new game, SWARM!
SWARM! is a combination ball-rolling platformer where players are HotRod, a mischievous skater that "joy-rolls" his way into trouble at every turn. As an invasion of evil mecha-cops threatens his town, he must venture though multiple cartoon environments to discover their source and save his city.
Written by the token academic of the team, this will be an academic post-mortem of the project. What is an "academic post-mortem," you ask? It is one where not only typical post-mortem topics of team structure, workflow, project management, and technical issues are discussed, but also one that includes an in-depth analysis of the game design itself.
Why an "academic" post-mortem?
In projects big and small, post-mortems can be vital. They give opportunties to evaluate how a project went: citing what went well, what could have been improved, and what was a complete disaster and should never be spoken of again. Post-mortems are also incredibly educational, often getting top billing at game development events for the insight they can provide.
Game academia, on the other hand, has a dubious reputation with many game developers. On one hand, there are schools that focus entirely on teaching software, with little thought to actual design. As the web series Extra Credits points out, many of these schools are detrimental to both the industry and students for the low quality of education they provide. While specific software knowledge can be beneficial in the short term, it is rendered useless when the next new piece of software comes along.
On the other hand, there are schools that focus on game studies to the exclusion of game development. Game studies focuses greatly on the study of games in structural, psychological, and social applications (among others.) As with film and literary studies, game studies can be of great benefit to us as designers by providing a critical framework with which to consider our own games. Such a field has invited a lot of skepticism from the game development community, however, by occasionally offering analysis divorced from or potentially detrimental to actual game development.
The approach taken by schools that marry the two outlooks-nuts and bolts game asset creation and game studies-can have great value for game development both during and after the development process. In design schools of many disciplines, it is common practice to utilize the language of critical discourse to analyze existing design work. The hope is to instill in the designer the ability to not only analyze the works of others, but also to integrate that same analysis into the designer's own work. While many would argue that the first thing that goes out the window during the development process is design theory, in many cases it simply recedes to the back of your mind, informing many of the decisions you make.
Perhaps the most important thing that design education gives the developer is a formal vocabulary for conveying design decisions to others. Many game design students point out that when they learn game design, they often already know the things they are learning about from years of playing games, but now have a way to talk about them. Dissecting games for their formal elements, therefore, is something that can easily inform the development process.
Integrating academic thinking into development
In evaluating the concept of a post-mortem, there are places where a game can be dissected for its formal elements so that designers can better articulate the "design aesthetic" or core elements of the game's design. Often, over the course of a game development cycle, several design undertones can emerge without team members being aware of their existence. These can occur in the designs of several different people using the same art assets, or even as they discuss how they will tackle different level building challenges. Post-mortem discussion of such undertones and aesthetics can also be enhanced by the design academic's knowledge of history and precedent. While focusing deeply on the current project can be advantageous, knowledge of what came before or of industry debates and trends can greatly justify design decisions, as will be demonstrated when discussing SWARM!'s release, control scheme, and the games that influenced it.
For SWARM!, the concept of a "post-mortem" is actually something of a misnomer. Technically the game is not finished, though it is very much in a state where it is ready to be played by the public. This is common of many mobile games where part of a game is released initially and the remaining levels and other content are released as part of an update or as in-app purchases. In SWARM!'s case, the current release occurs with two worlds (consisting of ten short "quickplay" levels and four longer story levels each), four environment types, and six playable characters present.
Episodic releases allow us to better take stock of our progress mid-project and add new content at a pace conducive to a small team.
That SWARM! utilized an episodic release model demonstrates where academic post- or mid-mortems can fit into an overall development cycle, even for games that are not released episodically. Targeting a holiday 2012 to early 2013 release in mobile markets, we've used the release of this first section of the game as an event-based milestone. Events such as holidays, competition submission dates, conferences, or important meetings are great incentives for completing tasks. They are also nice moments of dénouement in a development cycle during which a team can briefly recuperate from the previous crunch before moving on to the next task.
Of course, true academic analysis works best when it is done with its own milestones in mind. For many academics this can be the publishing of articles or conference papers that allow them to sustain their livelihood. This "publish or perish" mentality can even find its way into academic post-mortems of games. Our Marketing Manager at e4 likes to say, "If it wasn't written down, it didn't happen." This type of mentality is all too true in game development, where undocumented comments or suggestions get lost in the chaos of game development. In an even broader context, having post-mortem details documented in a design document or even as a written analysis can create a textbook for designing the game. This goes beyond simply the "what worked/what didn't work" model but develops the critical discourse and design language of the game at hand. In many ways, this analysis of SWARM! will do the same, dissecting the mechanics of the game and exploring historic or current industry trends to determine next steps for the project.
Evolving the control scheme of SWARM!
Perhaps the most notable element of SWARM! that sticks out in my mind is the control scheme. Game control schemes and their relationships to device hardware should never be ignored. For example, a quote from Chris Crawford in Tristan Donovan's Replay: The History of Video Games, states that the Macintosh computer "abstracted what we could show the player and allowed more verbs" with its mouse and Graphic User Interface.
SWARM! itself began life as lead programmer Taro Omiya's school project. In the game, a swarm of bees chases a space ship. Searching for a new project, the e4 team turned to Taro's small game and realized that it could fit well as a tablet game where players rolled a ball around. To control the game's protagonist, players tilt the phone or tablet for movement and touch the screen to jump. Several playtests also showed that players liked having the option of flicking the device upward to "flip" the ball into a jump, citing that it felt like a natural addition to the tilting.
Early concept sketches show what could have been, from heroic hamsters to a death sport with spherical tanks. Sketches like this show how in games like this, the art is treated as a coat of paint applied to existing mechanics.