GDC 2010, Day 1
My notes from the first day of summits at the Game Developer’s Conference.
Indies and Publishers: Fixing a System that Never Worked
Carmel argued that software publishing, like software development, is broken because it uses the wrong metaphors. Software developers looked at mechanical engineers who sequentially designed and then built structures because building had a large cost. Reducing the time, money, and materials used meant working hard on the design until everything was sufficiently good. Software developers used an analogous system, the waterfall model, but met with constant failure because software environments and goals are often different enough that what worked previously won’t in a new environment until it’s better understood. So up-front design doesn’t adapt to emerging requirements and constraints; further, code is cheap. Developers accepting this view are adapting iterative development models that allow them to design, develop, and then repeat the process as new findings come to light.
Publishing in physical stores is a similar misapplication. Producing and distributing physical objects requires significant risk and resources. Digital distribution has very little cost requirements and much lower risk, and yet publishers still offer developers the same terms as physical publishing. Fixing this model means acknowledging theses differences and using them to provide better experiences for both customers and developers.
World of Goo illustrates both examples. With Games for Windows Live, Carmel said it took about two months to negotiate the contract and two more months updating the game to support the environment. With Steam, it took only one day of legal work and an additional four to alter the game for distribution. Carmel pointed out that this isn’t a fair comparison because Games for Windows Live was a new service at the time while Steam had been around for much longer, but the experiences are illustrative of the competing views.
Publishing is about funding as well as distribution, and distribution isn’t much of a problem with digital distribution. Indie Fund was created by a collective of indie developers to address the funding problem. They have six primary differences with existing publishers: transparent communication, public terms (eventually), a single point of contact throughout the process, knowledge of and support for flexible and iterative development, no intellectual property ownership, and no intellectual property control. This last one means that Indie Fund won’t exercise editorial control over funded software. The overall goal is to make studios financially independent.
Abusing Your Players Just for Fun
Why abuse players? Cactus says it’s fun for the developer and other media do so, too. In film, there’s David Lynch and Alejandro Jodorowsky. In music, punk rock. In games? Well, there’s Mark Essen. And Cactus, of course.
Why are Gaming Veterans Flocking to Social Gaming?
Working at large studios now has a slow development time, one game taking multiple years. All of the developers lauded social games for having quick development cycles—Reynolds saying Farmville took five weeks for to develop the first version. Rapid development, small teams, and being close to the entire process is similar to the early days of game design, they agreed. Interestingly, none of the designers mentioned the independent game movement throughout the discussion of social games.
Brathwaite seemed to find social games validating in a way, as she said they opened up games to her family who now understand her better. She also made the point that, with metrics, designers can view the design process as a game, too. Her question for the other panelists (particularly Reynolds) was why casual game designers kept making the same game. Falstein responded that it’s easy and there’s still innovation, so it’s no big deal.
Meretzky made the point that most social games aren’t really, well, social. Instead, they’re single-player experiences that derive benefits from spreading. He’s hoping to make more meaningful games, which he described as incorporating more social information (such as profiles). This is an interesting definition of meaningful in that it doesn’t really talk about what players take away from the game, but I think he means something more like modelling how for example board games foster social interaction. He was also the only advocate of simplicity in game design instead of starting with a simple game and gradually building it up into a “real” game (consider transitioning Farmville into a SimFarm game).
Reynold’s big point was that social game mechanics matter much less than the social interaction. Given Meretzky’s comments, I’d wager that the simple mechanics and scheduled reinforcements are a significant part of the design, too, but seeing the success of World of Warcraft as a social space also supports his thoughts. His other main point is that facebook is a requirement reboot, just like the change from MS-DOS to Windows 95.
Falstein’s observation that even the most hardcore players can’t progress much faster than the most casual in social games is a bit problematic for me. Combined with the other panelists’ comments, a social game seems to be a single-player facebook game with lots of scheduled rewards and simple mechanics that benefits from spreading to others. This is exactly the problem that other designers have been railing against both online and at this year’s conference.
Effective Marketing for Indie Game Developers
Public relations are mainly about frequent and open communication with players, Graham argues. Thinking about how developers can make noise, keep their development process open, make friends, and make community is the primary challenge, and he suggests four different tools for doing so.
Communication requires something to talk about, and blogging often is one way to do so. Wolfire Games has been posting one post per day for quite some time with the express goal of encouraging feedback. Initially, they’d end each post with a question, but after readers called them out on this, their writing skills improved and they received better feedback (is what I think he said!). Most of their most popular posts were written by their lead developer and involved controversial topics, such as why developers should use OpenGL instead of the competition.
Keeping the website up and running is essential to enable communication to even happen, and so Graham suggests using Google App Engine and the Amazon Cloud to help maximize uptime. A related note would be to actually take software backups, including off-site backups, for when things break.
Augmenting the site with additional means of interaction also helps. In addition to the standby of forums, he suggests IRC (Wolfire has its own channel) and live chat (Graham’s almost always available) are methods that have worked successfully for them.
Lastly, he encouraged the use of social sites: facebook, youtube, and twitter. In addition to these, though, he suggested looking for community sites that fit whatever game is being developed; for them, this meant http://moddb.com and http://www.gametrailers.com/. For youtube, Wolfire follows a specific structure for each of their videos. First, it introduces a new feature, even if it’s very rough at the moment. A narrator describes the feature as it’s showcased, and they finally add a text that critiques or comments upon the narration. The effect is very similar to “The Wørd” on The Colbert Report, amongst others, and looked effective. He stated that they’ll usually have people who sympathize with either the narrator or the text, and doing so helps broaden the video’s appeal.
Creating and Nuturing Your Indie Game Community
Lindsay discussed how the SuperHappyDevHouse came about. DevHouse is a hackathon held every six weeks where people come with a laptop, hang out, and, well, do stuff. Starting with less than 20 people, the largest has had around 400 people attend the about 12 hour event. Lindsay has 10 tips that DevHouse followed along this path:
- Hold events. Doing things online is great, but in person is even better.
- Make purpose. Instead of using extrinsic draws for the group (invited speakers, free food), Lindsay argued that cultivating intrinsic interest is more sustainable and inviting. This also makes it easier to hold events if people are coming for the activity and community.
- Start small.
- Repeat often. DevHouse was held every six weeks, and this is the social version of release early and often.
- Stay learning. Debrief after each event and it should continue to improve. As part of this, he argues that failing early and often (with the smaller group) is a great practice.
- Be inclusive. Let people join and give them responsibility, Lindsay says, and they become more invested in the community.
- Identify values. What do the organizers want? Why? Make these values explicit and part of the culture.
- Think experience. What is the experience of the event? How can it be improved? This includes the design of the environment and its location.
- Teach promotion. Here he gave the example of a Nintendo game that teaches people how to market the product to friends. DevHouse copied this and created a “How to Invite Frindes to attend DevHouse” document and shared it. Soon after the 400 person event occurred.
- Help duplicate it. DevHouse not only sanctions other groups doing similar activities but also actively supports them by answering questions or, in some cases, helping to organize the first session at the new location.
Munroe then took the stage and discussed the groups he helped organize, The Artsy Games Incubator and The Hand Eye Society. He agreed with Lindsay’s tips while offering up his own. Providing structure (also known as deadlines) are one way to help the event proceed smoothly. And, after noting the disconnect between the indie game community and other local communities of independents, he suggsts being open and throwing events for the public. He described a craft fair where a group set up an arcade using indie games to great success; they’ve also created a more traditional cabinet for indie games that they move around town. And finally, he re-emphasized the need to fail in order to learn and grow the community.
AI and Interactive Storytelling: How we can Help Each Other
Kline began by quoting Chris Hecker as saying that “interactive storytelling isn’t for us”, but for Kline interactive storytelling is really about managing experiences. He argues that current game genre conventions are part of the problem; instead, he divides games into three: roller coaster, experiment, and challenge. Roller coaster games include Dragon’s Lair, Metal Gear Solid, and Half-Life and is primarily about a linear experience. Experimental (or play or non-mastery…he didn’t find a good label for this) games are more open and include games like Deus Ex, The Sims, and Civilization. Challenge games are all about skill, such as Street Fighter II, and so things like balance and mastery are important.
After laying this foundation, Kline redefines interactive storytelling as search and provided a number of case studies supporting this view. Acting can be viewed as searching for events or generating a sequence of events for story purposes. Barks, too, can be seen as a complex search through the environment for narrative elements. Hints are a search for players’ experience with the desired experience (meaning for example, that a player wandering around instead of efficiently moving towards a goal has an experience disconnect and the search result should direct the player towards the desired experience). Guides are another way of directing players and should have multiple techniques—he gives the example of “How do you make someone walk through a door?” Dynamic difficulty or game calibration also attempts to match players to a desired experience. Left 4 Dead does this well, he says, and it also maintains desired pacing well. Surprising the player through, for example, procedural generation of levels is another technique to create interactive stories. Finally, storytelling itself can be attempted in experimental games.
Mateas next took the stage to discuss procedural narrative. Heavy Rain, he said, isn’t the way of the future because he wanted richer story development. He compared it to his game, Façade, by saying at least they were trying to tackle tho actual problem instead of covering it up.
The standard model of story construction leads to combinatorial explosion, though developers have created techniques to manage this (fanning in or out, for example). Instead, why not do action selection problems? he asks. With this technique, significant story sections are selected out of a library of story parts, each with prerequisites and outcomes. How? He says that story grammars are one possibility, but doesn’t elaborate much on these. World and character simulation are another necessary, but not sufficient, way to create procedural stories. Agents acting within a world alone just leads to “one damn thing after the other”, which he states is hard for long-term generation. To this he adds author simulation, which may conflict with agent goals. For example, two agents wanting to get married and doing so is a rational thing for them to do, but it doesn’t make an interesting story. Instead, the author simulator could prevent them from marrying (due to parental wishes, for example), which leads to more compelling stories. For more information, he strongly recommended Expressive Processing.
One quick aside: Dwarf Fortress as far as I know only models agents and the world, and yet it’s far from “one damn thing after another”. Adding an author simulator seems to put faith into a higher-level system that I’d imagine could be incorporated into the agent-world simulator (via a “drama” attribute, for example), and so the belief that a separate layer will lead to better experiences may be premature. But it’d be a lot easier to program.
Emily Short’s discussion centered around articles captured on her blog. They chronicle how she’s been working with interactive fiction dialog systems to create better experiences, and they’re well worth a read.