FDG 2012 Conference Report, Day 3 and Conclusions

(This post was written in everyone's favorite text editor while sitting in the airport and on the flight home. This has allowed me to explore a few ideas in more detail than the last two days. That is to say, I'm using my writing to try to piece together some ideas, and I've not pulled any punches in the attempt. Final edits were made later in the day when I had an Internet connection and was able to verify names and add links.)

The opening keynote this morning was given by Reed Shaffner and Zach Schubert from Zynga. I think many of the attendees were eager to hear what Zynga would have to share at a primarily-academic conference, since—fairly or not—they tend to be the butt-end of a great many jokes in game design. In fact, I was really impressed with the technical content of the presentation and the candor with which these two gentlemen shared their ideas. It wasn't purely altruistic: Zynga is in the process of creating a platform for game developers. One way to speed adoption of a new platform is to get buy-in from academics. Regardless of motivation, it was an honest presentation and I really appreciate that they were revealing their hands to us, especially since, as they say, Zynga has not traditionally engaged with outside groups.

The presenters had done their homework, too. Shaffner made a comment about how they take some criticism since some of their games are like clicking cows. This is, of course, a tilt of the hat to Ian Bogost's Cow Clicker, and as Shaffner said this, he nodded to Ian, who was sitting in the front row. Classily done.

Let's talk about analytics. Zynga collects 8 terabytes of data each day spread out over 60 billion rows. To consider how much data that is, it's like 2:43 into Powers of Ten. These data are available for query within five minutes of being collected, and a subset of it is available in 90 seconds. That's incredible. They pointed that unlike many Web applications, practically every operation is a write, which gives them interesting technical and architectural challenges. Their total database size right now is about 1.4 petabytes (3:13). With this mindboggling amount of data, it would be folly not to do some automatic analysis over it. They have just recently started endeavors to predict play behavior from the 100 or so characteristics they record about their users. These sound like wonderful machine learning problems!

Schubert talked a lot about how they were converting to a service-oriented architecture. Traditionally, they have replicated a lot of services in game-specific servers, and also replicated code on client and server so as to prevent fraud. Heavyweight game servers are not scalable, and—according to their own internal tests—replicating logic on client and server do not prevent fraud. Separating into services not only helps them continue to scale, but it also permits the Zynga platform to emerge as something valuable to the community of game developers. Regarding fraud detection, they're moving toward the approach taken by credit card companies: automated machine learning on the server side to detect potentially fraudulant activity. Again, this is enabled by their vast collection of data and opens up fascinating research opportunities.

Zynga API Infrastructure. Very cool.

I took the opportunity to talk to Shaffner after the keynote. More specifically, I got a cup of coffee and then saw that he was still in the room, and he was kind enough to chat with me despite the fact he almost certainly was ready for a coffee himself. I asked about the methodologies they use, since as you know, dear reader, I do love me some methodologies. Their game teams use waterfall since they are often driven by very strict timelines. He acknowledged that agile has value, but the company was more attuned to design-up-front. Since these games are continuously updated services as opposed to products, it really sounds more like a form of continuous delivery with a very structured initial planning process. Some of the internal tools teams used more explicitly agile approaches, and most of the teams incorporate variations on daily stand-up meetings (capped at 15 minutes) and burndown charts, albeit without rigid timeboxing.

I appreciate that the conference organizers had a range of keynotes from education to sociological to technical. The guys from Zynga were great, regardless of what the rest of the company is doing.

I will note that the representatives from Zynga and Bethesda mentioned that they would benefit from cooperation with the academic research community. More specifically, they had problems that academic research could help solve. 'Tis external funding makes the academic world go 'round. Just remember: you heard it here first.

After the keynote and Zynga-sponsored coffee and snacks (thanks again), there was one more research paper session. I will note that there were two parallel tracks during each of these sessions. At almost every juncture, it was hard for me to decide which track to attend, as I'm sure I could have learned something in each one that's relevant to my interests. The easy one was when my own session, although there was a paper about games in CS education opposite my session that I'm eager to read. This morning, I attended the session on game design.

Chris Lewis talked about behavioral game design patterns. This work is based on existing work on game design patterns which, like object-oriented design patterns, are inspired by Christopher Alexander's work and discovered in successful systems. This work on behavioral design patterns looked specifically at Zynga's 'ville-style games, and the author proposes four patterns based on behavioral psychology and behavioral economics: fixed interval scheduling, the sunk cost fallacy, scarcity, and reciprocal altruism. Lewis explained how these show up in Farmville as well as in other games not connected to social networks, and I found his explanation intriguing and satisfying.

I have had some trouble wrapping my head around the game design pattern work, partially because the scope and application feel very different from Gang-of-Four-style software design patterns. Consider fixed interval scheduling. The problem it solves seems to be, "How do I motivate my players to keep playing?" Fixed interval scheduling is certainly one way to do it, but it's more directly answering the question, "How do I motivate my players to keep coming back," but when asked that way, the answer is obvious: give them a periodic thing to do. By contrast, consider the Visitor design pattern in object-oriented software. The problem is that one has type-specific algorithms to execute over a potentially-heterogeneous data structure whose type is not known at compile time, and the behaviors to be added change more frequently than the kinds of things being added. The solution is to use Visitor, a combination of double-dispatch and subtype polymorphism. There are lots of ways to implement the pattern that depend on the specifics of the context, but there's a real sense in which Visitor gives you the best path—the best family of reifications—for the problem. It's not the only solution: for example, you could pepper in some runtime type information extraction, such as via instanceof, but you shouldn't.

Is your problem related to type-dependent algorithms over a heterogeneous data structure? Use the Visitor design pattern. Is your problem that you want people to be motivated to play your game? There's about a hundred different things you could do. Is your problem that you want players to keep coming back? Then make them keep coming back. To be clear, I'm not saying game design patterns are wrong, but they do strike me as a very different kind of thing than what we call "design patterns" in software development.

Anne Sullivan presented an interesting design for a social RPG—which she defines as a role-playing game with no combat—in which the game's responses were based on a "story forest". Plot points could come from different characters based on your previous interactions with them. Similarly, the ending of the overarching narrative was related to behavior throughout the rest of the game, even including generated endings for cases that fell between the cracks. At the very end of Q&A, someone asked where to find and play the game, and at this point she admitted it wasn't finished due to lack of resources for content creation. I find it irksome that she was not more forthright with this during the prepared remarks, since this point is a significant contribition to discussions of alternative quest and narrative techniques: content creation is often a limiting factor. Understanding how it is a limiting factor within this kind of game system is crucial to moving this line of work forward. Evaluation of an incomplete artifact is necessarily incomplete, and redefining "done" as "done enough" strikes me as problematic when the very  goal of the study involved looking at overarching and complex, interwoven character interactions.

Sullivan's justification and related work were quite interesting. Although I would have preferred more technical details about the actual mechanics, I certainly share her disappointment in the proliferation of killing in CRPGs where alternative solutions provide such better story. (My first answer to "What would you see removed from Skyrim-like CRPGs?" in yesterdays panel is "Everyone fights to the death.") I was surprised that she did not mention Chris Crawford's work on StoryTron at all, since it seems to capture much of what she is trying to demonstrate through her experiment. The biggest problem with StoryTron, which I was able to confirm once I returned home and got online, is that it's still down, and so is its most well-known game, Balance of Power: 21st Century (review). Crawford seems to be working against those of us who want to take this work seriously! If you're reading this, please keep these artifacts accessible so we can study and learn from them.

Gillian Smith presented a platform game based on a six-dimensional procedural content generation (PCG) system. It was an interesting experiment, and she acknowledged the limitations of her team's solution. Seeing the demo, though, I am reminded of a comment from How to Prototype a Game in Under Seven Days: nobody cares about your engineering. More specifically, one must remember that the player will build a subjective mental model of what's happening under the hood. Smith kept speaking about the project's PCG nature as if it were apparent, and she was clearly exasperated at the complexity of it and of communicating it to the player. Compare this to Inside a Star-Filled Sky, which demonstrates how PCG can be explicit, integral to gameplay, and comprehensible. I'll have to read Smith's full paper to see if she can tease apart the fundamental differences between these two projects. The answer to the research question, "Can we build a system that does X" is almost always "yes," but it's a solution looking for a problem.

Remember, friends: I criticize because I love. That's what academics do. At least, that's what I do.

A team from Sweden presented their Masters work, a Microsoft Surface project designed to facilitate all kinds of tabletop gaming. They very quickly admitted that it was naive to think they could facilitate all kinds of tabletop gaming, and instead they found two examples of games that worked for their approach. Of course, if you build a digital tool that allows players to trace lines with their fingers and then erase them, you've invented an awkward and expensive version of paper. Now, these guys had more features than fingertip drawing, but I hope that the real lesson of their paper resonates with future graduate students and hobbyists: solve a specific problem and beware of feature creep. When my team developed Confluence, we had to push back pretty hard against pressure to add numerous features that would make ours the end-all and be-all of hybrid RFID multitouch conference systems. I'm glad we held our ground, and we still barely got it done in time—but it worked exactly for the purpose we designed it.

I believe that all of these three experimental systems presentations were given by graduate students, and as I reflected on this, I remembered some of my early conference presentations. They were based on the fact that I had built a thing, and it was neat, and I wanted to share it. In retrospect, I probably should have spent more time before building it trying to really understand why I should build it. This reflects my more recent embracing of design thinking, especially the point that design is for people, and so people need to be a constant or at least periodic focus of the iterative process. I wonder, did these graduate students, like me, finish a project with good intentions and then go back and add a related work section?

I haven't read all the papers (yet?), but I suspect the talk followed the flow and tenor of the paper. What I'd like to see in game design papers is explicit treatment of each phase of the design process and an analysis of its direction over time. For example, what were the originally identified goals? As a prototype was built and tested, how did this change what goals were identified for the next round? How did your empathy for the end-users change your evaluation plan each iteration? Perhaps this can be boiled down to this statement: if we're going to talk about game design as design, then we need to explicitly describe the design process, especially for design experiments. OK, now that I've said that in public, I'm going to try that when I write up a game design paper. Internet, your job is to hold me to that promise.

After this session, I joined a group for lunch at The Big Easy, where I had a shrimp-and-oyster po' boy with a Blanco Diablo. (Interesting story: when writing this, I remembered it as "diablo blanco", but when I did a search to find a link, I discovered it was "blanco diablo." Another exciting bilingual story from FDG2012!) Excellent food, and great company. Near the end of the meal, we had a short discussion of Jane McGonigal's work. One lunch attendee argued that it's good that we have hope, that we be positive in about what games can do. I argued that this should be tempered against what we know about how people actually behave. I may not have made my point very well, though, partially because I made an analogy to Scientology that was probably not well explained. My point is, if we all converted to Scientology, we would share in the belief system it presents, and we'll all probably be really happy and get along. But, it's not the case that everyone is going to convert to Scientology (hooray!), and so we're better off looking at what people are actually doing than just hoping everyone will convert. It's pertinent that I'm currently reading Hanging Out, Messing Around, and Geeking Out. This book is the result of a massive ethnography of how youth engage with new media; that is, it deals with how people really behave in a complex changing environment. It doesn't make any promises about how new media will save the world, but it does provide research-based conclusions regarding how people behave.

I had a great time at FDG. I met some great people from a variety of disciplines and countries. The range of research topics was great, since this showed me new directions for my personal and professional work. The quality of the research was fine, although I think this conference shows that there's a lot of growth potential still within this field. I heard several academics complain at the lack of industry representation, and while it would have been nice to meet more people from industry, it wasn't clear that the presented papers were well connected to industrial practice. Compare, for example, my trip to OOPSLA (now SPLASH) a few years ago, where everything I saw blew me away, and where there's historically been a productive mix of industry and academia.

I also had some great opportunities for personal growth at this conference. Several attendees mentioned that awkward lonely feeling you get when you attend a conference where you don't know anyone, and it was great to hear other people articulate those feelings swimming around in my own head. It sounds so silly, but it's true that I am in a room of strangers and it's lunchtime, it feels really weird to walk up to them and say, "Let's go get some lunch!" I'm sure it's easier for some than for others, and I'm glad that others are not afraid to discuss it! This is me, doing it in public and embracing the suck. This also marks the first time at a conference where I joined in ad hoc after-hours socializing with people I just met. Here's a good story: After hearing Jonas Linderoth's keynote Wednesday morning, I read his 2011 DiGRA paper Thursday morning, then found him and told him I enjoyed it Thursday afternoon. That evening, we sat together over drinks discussing the Swedish and American educational system, the challenges of publishing qualitative research, and Sam's amazing journey from wine stores to cord stacking. (Also, Swedish death metal.) Lessons learned all around.

I look forwarding to attending an FDG in the future, although likely not next year in Crete unless I can secure significant travel support—and someone to watch the kids, since I don't think my wife would let me go without her!

Sorry for the long post. I don't have time for a short one.