Notes from Tuesday, March 6 at the 2012 Game Developer’s Conference. Also check out Sirlin’s notes.
The Failure Workshop
Carmel introduced the Failure Workshop as a session dedicated to failure, exploring the causes of that failure, and hopefully learning something from it.
Cheng described the problems with Sugar Rush, a game that was cancelled two weeks before it went live. Why? One reason was that the game lacked an advocate who kept it true to a vision; instead, they went through five art styles—redrawing all the art in the process—as their perceived market and platform changed. And after losing their first publisher, their second publisher shut down two weeks before their intended launch date. They couldn’t launch the game themselves because it relied upon their publisher’s servers and, more importantly, IT people who numbered more than the entire development team.
Swink was absent during Anderson’s discussion of Shadow Physics.It sounded as if the team primarily suffered from communication problems and from believing their own hype. Anderson described wanting to make a fortune from the game and “Braid envy”, where he and Swink would talk about how the game would inherit and extend Braid’s reputation as a must-play 2D platformer. Further, Anderson described how they had problems finding interesting puzzles. Anderson closed by saying how Shadow Physics, like Sugar Rush, lacked an advocate who passionately wanted to continue its development, and that it was a dead project.
Rao’s presentation kickstarted with some technical problems (appropriate for a failure session, he joked), before launching into the cut system from Bastion: gardening. Rao waxed on about how gardening was the system that was meant to unite the weapon upgrade system, exploration, exclusive decisions that mattered, and more. And gardening had occured in many successful games, such as Viva Piñata, so why not in the action-adventure genre?
He shared a voice clip of Logan Cunningham improvising some lines for gardening that highlighted the problem. “Find a pocket watch? Plant it. Find a MD player? Plant it. Find a Milli Vanilli cassette tape? Plant it.” I don’t recall exactly what he said, but Milli Vanilli was definitely there. The narration didn’t make any sense, and players likewise had no idea what the connection was between planting a seed and receiving a hammer upgrade. The artists were likewise instructed to do things like “Make a hammer plant” with mixed success. Supergiant Games cut the feature, returned to the standard convention of a menu system, and players understood the connections much better.
Northway concluded by showing a number of failed prototypes. One based on flocking lacked interesting systems. Players controlled one flock of birds that served as a target for another group which in-turn was preyed upon by a final group. He repeatedly stated he was still interested in flocking as a mechanic and hoped that he or someone else would develop it further.
He then descussed a game that I forget before moving onto Clutter, a 2D platforming game that had players construct their character from toys found in levels. The reason Clutter failed, said Northway, was that he kept listening to feedback from people who suggested that he de-emphasize the building aspects and emphasize the 2D platforming aspects. He did so but eventually didn’t enjoy working on the game anymore because it had lost the reason for its existence. Aborting Clutter led him to Incredipede, where he’s once again feeling that the concept has significant depth in terms of the puzzles he can create.
The Indie Composer Speaks
Shigihara shared her love of Mega Man’s music, which she practiced as a child instead of the classical pieces her piano teacher assigned. One of the reasons older video game music is so interesting, she continued, was that the composers had limited resources to create something interesting; the constraints led to them incorporating counterpoint and other things I missed into the music. Many composers creating music today do so without those constraints, leading to less interesting music. Ed Fries made a similar point about programming at MIGS 2010. She also talked about how she entered each note by hand into her tools.
Vreeland showed how Fez used a custom editor to generate its audio. Loops in the game could be configured to play for particular in-game events, such as time of day. Sound effects were also tuned to match the music through the editor. He argued that developing game-specific tools could help make the audio fit gameplay better.
Baranowsky gave some tips for working with composers that also apply to general contract work: Get to know the person and give them some ownership in the project. Scheduling, how to provide feedback, and general expectations all go better when people know each other. And you’ll get better work from people, he continued, giving them part of the profits instead of a (small) check helps contracters feel invested. Another complementary method is to include the composer in the design of the project (the other composers agreed), as they’d be able to help think of the project from an aural perspective.
And all agreed that custom music was the way to go for games.
Clones: Advancing the Discussion
Ismail and Nijman of Vlambeer have had a rough time with their game Radical Fishing. In the midst of porting it to iOS, they discovered that another company, Gamenauts, had released essentially the same game. As a two-person team, such a game would have a significant impact on their ability to continue making games.
They defined clones as games that were exactly the same mechanically with different artwork and/or music; as an example, they said exchanging the media assets between Doom and Duke Nukem would still play out as different games. It’s only when the games would play the same that they qualify as a clone.
So what to do about cloning? Ismail and Nijman argue that suing a cloning company is hard to do because its easy to look bad. Instead, they suggest humanizing game development: Sharing that people make games by being open about the process through blogging, movies, and more.
Create New Genres (and Stop Wasting Your Life in the Clone Factories)
Like Vlambeer, Spry Fox has had their game Triple Town cloned, but unlike Vlambeer, they’re suing the offender. Cook’s talk took a different approach from Vlambeer, starting with why cloning games didn’t make sense economically.
Cook’s definition of cloning encompassed refining games to eventually create a genre. Unlike Vlambeer, then, Duke Nukem would be a clone of Doom under this definition. He used this definition to argue that creating a genre and then executing that idea well. By starting at the beginnings of a platform or, as Cook stated, genre, a studio that can execute the idea well will define the genre and capture its market.
There are a few problems with this view, though. Cook described how RTS games began with Dune II, but Westwood Studios was unable to execute as well as Blizzard with WarCraft. So defining a genre is insufficient if the subsequent execution is poor. Further, games that differ significantly from existing genres potentially face audience, press, and developer problems. Prior to Cook’s talk starting, I met an employee from Gameloft who described creating a startup game company, working for three years, and failing to achieve sustainability. Joining Gameloft wasn’t what he wanted to do, but it did enable him to continue eating. The question, perhaps, is how much one is willing to sacrifice in order to create a genre.
Ok, so how can one create a new genre and then execute it well? Cook offered 13 techniques. To begin, he suggested that teams design from the root of a genre, looking at the essential mechanics that gave rise to a genre and making different decisions. He continued that designers should avoid antipatterns that emphasize content creation instead of gameplay creation. What are these bad mechanics? Things like puzzles, levels, and story-centered games (and the related genres of adventure and PvE MMOs). Board games already do this well, Cook mentioned, and are a good place to explore this concept.
He continued with the third technique, using loops, not arcs. Loops are cycles of play that players learn, master, and burn out on. Small teams, ideally one with great design skills and another who’s an excellent programmer, are Cook’s forth recommendation as long as the designer gets final say (fifth) and the team iterates (sixth) in short cycles (seventh). And by short cycles he means a day; any longer than that and the game isn’t being developed enough. The short cycles are used to answer questions that arise from the limited up-front design (eighth) Cook recommends.
The point of these techniques is to prevent designs from prematurely being fixed; heavy up-front design attempts to describe a system before it’s been tested and iterated upon. And so Cook also recommends that art and narrative should be added late to the project (ninth) as they should be serving the mechanics. And since teams can’t know from the beginning if a project will turn out well, he recommends using a portfolio approach to development with many small experiments (tenth).
The last three techniques deal with the end of development. One of the most important is to release the game (eleventh); doing everything else, especially publicly as Vlambeer recommends, means that the team is doing work for people who want to clone the game. Innovating post release (twelfth) is how the gameplay-focused games that Cook advocates can execute better than competitors. His last technique is fitting different markets, where he drew the analogy between porting a game and one-night stands. With Triple Town, the game developed and grew from its Kindle beginnings, to facebook, and then to mobile devices. Each time was an opportunity to tweak the game to resonate better with players.
Bringing Large Scale Console Games to iOS Devices: A Technical Overview of The Bard’s Tale Adaptation
Jacoby’s session detailed how he ported The Bard’s Tale from PS2 to iOS. Initially, his goal was to retain as much of the tested and working code as possible instead of re-engineeing the software to fit iOS’s standard looping model using CADisplayLink. He did so by putting the existing engine on its own thread and having the CADisplayLink callback advance the game each tick. He further decoupled the rendering from the gameplay to fit the hardware constraints of the mobile devices. When rendering still required excessive amounts of time, he replaced the alpha testing with alpha blending with good results.
The other main problem he had was reducing the audio and art assets sufficiently for the App Store. Converting the audio to Ogg format recovered much of the audio space. For graphics and models, he realized that many of the assets were either unused and could or were duplicated in order to load better on the PlayStation. Culling unused and duplicated assets allowed the game to hit their size targets.
Jacoby finally discussed iOS-specific features he added, the most interesting being iCloud support. He wanted the iOS port to work with older iOS versions and without constant internet access. To do so, he created a local save-game cache that always updates when the game saves. With iCloud support enabled and access, the saves would sync with the cloud in the background.