Tuesday, November 01, 2011

NYU PRACTICE Game design Conference

I spent the weekend in Manhattan at the "first annual" game design conference called PRACTICE*. I stayed at my friend Gil Hova's house, and managed to get some playtesting in with Gil (Sword Merchants), Andy Van Zandt (Admirals of the Spanish Main), and Michael Keller (Titans of Industry) on Sunday night - and honestly, that might have been the most productive part of the weekend. I also playtested an upcoming game by David Sirlin and got a short game of Admirals in with Robert from Cambridge Game Factory.

I posted the schedule of the conference in a previous entry. As I expected / feared, the talks were heavily geared toward digital game design. I wish there had been more focus on non-digital game design, as ANY of that information is almost always useful to designers of digital games, while a lot of information about digital design is not useful outside of that space (like programming for example). I'll list the sessions again here, and note any takeaway I got from them that could prove useful in my future game designs:

Lecture (Reiner Knizia): A detailed case study of a best-selling board game design

It turns out they were referring to Knizia's new title Whoowasit. New to the US that is - apparently it was the best selling board game in Europe (all of Europe? Did I get that right?) for 2008 and 2009, slipping to #2 in 2010.

I had heard part of this before, but not the new stuff. Whoowasit is a cooperative "deduction" game for kids. I put deduction in quotes because as Reiner said in his talk, it's not really deduction... Someone has stolen something, and you go around getting clues by delivering food to different animals, and those clues let you eliminate suspects, trying to figure out the correct culprit before 6:00 - so you have a set amount of time to get enough items delivered and collect enough clues to single out the thief.

The game uses some technology - a box which talks to you when you touch certain spaces on it - which has evolved from the conductive ink used in the boards for RK's earlier titles King Arthur and The Island (which wasn't ever released in the US). Honestly, those 2 games and the brilliant-sounding ways they used the conductive ink to allow the game to 'know' which piece is where and track virtual pieces around the board sound MUCH more interesting to me than the simplified Whoowasit, where they removed the technology from the board and put it only into a box that accompanied the game. However, while King Arthur and The Island didn't seem to be very successful commercially, Whoowasit seems to have blown up! It sounded like there was subtlety in the design that was lost on the players. For example, there was a Knight in King Arthur who you could interact with in different ways to elicit different results - you could fight him, you could give him an item, etc. however, players seemed to approach him like an obstacle in the way, and chose to fight him... then when encountering him again later they thought "well, fighting worked last time, might as well do it again" and so the full potential of the mechanism was not being realized.

While I don't think that problem is worth removing the technology and all the associated possibilities from the game, I suspect there were also some commercial concerns, like cost of production, and perhaps the conductive ink didn't work or hold up well enough. I don't know.

The Takeaway: The thing I got out of this presentation was 2-fold...
1. When you find a unique mechanism or technology, look for other ways to use it.
2. Be careful with subtle mechanisms - if they're TOO subtle, players might miss them altogether.

Side note: Whoowasit allegedly keeps track of how effectively you play, and helps you out more the more you need it. Cool!

Panel: State of the Art Techniques: Best-practice methods for creating great games

This panel didn't seem to me to live up to its name. There was someone from Popcap (who, despite living in San Francisco, said he'd met Mohan!) talking about prototyping for social games, someone from Wizards of the Coast talked about balancing in a ccg like Magic: the Gathering, someone who'd worked on The Sims and Spore talked a little about math...

The Takeaway: Do the math behind your design, consider how important it is to balance game aspects before you worry too much about balancing them, when setting costs of things, pick a "skeleton" - a generic version of an object and decide what it should cost, and set the cost/power of other cards based on that (like a 1/1 Merfolk for 1 mana) BUT make sure you account for ALL costs of the object, not just resource costs (don't forget opportunity costs). And for social games, you really need...
- Single session engagement
- Retention
- Virulism

Lecture (Steve Gaynor): Helping Your Players Find Their Own Way - Lessons from Bioshock and other titles in progression gating and player tools.

This was a talk about level design in a video game, and as such you'd think it would not be very helpful in the design of non-digital games. However I actually found this talk very interesting, and I think the technique described COULD be used in board game design.

The focus of this talk was a technique called Staged Tool Gating. It's a technique to usher a player down a linear path through a non-linear space. Tool Gating is simply a locked door that requires a key (the door is the 'gate' and the key is the 'tool') - and you can replace Door and Key with any path blockage and anything that would remove that blockage. Staged Tool Gating is placing gates and tools in such a way that they lead the player through the intended path, even if that path crisscrosses a non-linear level.

The Takeaway: I've been thinking a lot lately about how to add a feeling of progression to a board game. Perhaps Tool Gating is a way to do that - making sections of the board, or various resources, unavailable until some other condition is met.

Panel: Designers, Players - Fight! Tournament players and developers on designing for expert play in fighting games.

David Sirlin started this talk off discussing game balance in a competitive game, and his presentation was very interesting and useful. Seth Killian (from Capcom)then discussed Street Fighter, and finally a high level Street Fighter competitor talked about Street Fighter as well. Apparently, everyone is enamored with Street Fighter...

The Takeaway: From David Sirlin's comments, the takeaways were that when balancing a game, there are some things you just can't do. You cannot change the flavor of a character just because it would make that character more fair. You have to find a different way to balance them. The example given was in his game Yomi, one of the characters is a rock golem who's very tough and very slow. In playtesting he proved to be too powerful, and playtesters suggested he'd be fair if his hit points were reduced from 100 to 70. While that would be fair, you just can't have a giant rock golem with the same amount of hit points as another character in the game which is a little girl, who's not even made out of rock!

From the Street Fighter discussion, the takeaway is that even a small change to a system can have a significant effect on the way the game plays. Speeding up a move by 6 frames (1/10 of a second) could take a character from being among the worst in the game to being one of the best. this holds over to board games as well - small rules changes can have a significant effect on gameplay.

Open Problems: A structured "open mic" session in which conference attendees present works in progress and share design problems for discussion and feedback.

They had more people interested in this than they expected, so each person got about 6 minutes to give their spiel and ask their question. The session went pretty darn well, though I think a little more time per person would be good (like 10-15 minutes instead of 6).

I asked about adding direct interaction in a euro-style game, and didn't get much response. The following suggestions came up:
- "Don't do it"
- "Do like Dominion - have attacks hurt everybody"
- "Attack only to your left" (structured targeting to avoid kingmaker type of attacks)
- "Cost it high enough that players can only do it if they really invest, and then you can see it coming" (this is what I was already considering)

I feel like Josh Debonais had a really good suggestion that I seem to have forgotten... of all the possible things to forget from the weekend, how could I have forgotten that!?

I forgot to ask / ran out of time to ask about what people thought would make a good expansion.

Lecture (Rogers Redding): The Game Design of Football: Evolving the rules of a nation's favorite sport.

This was interesting, though not terribly useful. I am surprised that someone hasn't sat down and rewritten the rules to Football from scratch. It was suggested that people fear change and wouldn't go for such a thing, but I think that's ridiculous considering they make rules changes every year. They're removing the Kickoff, because too many people get injured during the kickoff return.

The Takeaway: Examine your rulesets and make sure there's a reason for each rule. Remove any artifacts leftover from previous iterations and keep the rules as clean and elegant as possible, or you'll end up with a mess of band-aid rules and rules that don't really DO anything.

Panel: Game Design and Programming: A debate on the intersection and relevance of coding and design.

This panel was almost entirely an argument about whether knowing how to program would make someone a better game designer. Chris Hecker and Nick Fortugno talked past each other through 4 or 5 metaphors about a simple concept...

Chris: If you know how to program, than you can more efficiently bring your idea to fruition (rather than having to communicate with a programmer), which translates to a better quality.

Nick: You don't have to be a programmer to be a game designer.

More specifically, Nick suggested that the injection of creative juices by adding that programmer to the mix could provide a better creative environment than a single person designing and programming in solitude. Chris agreed that collaboration is good, but that you could still get that collaboration if you did the programming yourself. I think he missed that what Nick was suggesting is that if you knew how to program you wouldn't have another person there to collaborate with - so if you don't seek them out, then you won't have the collaboration at all.

The Takeaway: Collaboration is good, and so is being able to communicate your ideas to others. I think that panel could use a lesson on the latter!

Lecture (Matt Boch): Break it down: How Harmonix and Kinext taught the world to dance.

This was a history of various iterations and prototypes of the game Dance Central. It was very interesting to watch, and even had some information that could be useful for any prototyping or game design...

The Takeaway: Define your target audience, then be sure you're designing a game that would suit that target audience.

So there you have it. Even though the conference was heavily geared toward digital game deign, I managed to get a takeaway from each session that could help me improve as a designer. I'm not sure it was worth the $500 entry fee, but I'd consider doing it again. I'll just try to become more influential by this time next year so they invite me to speak (and let me attend for free) - then it'll certainly be worth the cost :)

* It was suggested by an attendee during the feedback session that PRACTICE is a terrible name for the convention. I agree with that, though I fear it's probably too late to change it now that they've begun. It just doesn't convey anything about the subject matter.

It was also suggested that the conference could run a bit longer. I believe they'll start Friday afternoon next time. 2-1/2 days isn't much more than 2 days, but it's still more!

4 comments:

Clive said...

Although targeted at video designers it seems you picked up some interesting information and had some re-confirmed, which is always good!

I like the idea of progression in a game but has to be balanced so that you are not leading a player by the hand through the game (if that makes sense). I am not a Risk fan but am seriously thinking of buying Legacy to see how they deal with a continuing progression from game to game.

As for you speaking next year, it seems they need really to address the game design process individually. I have a teacher friend that is teaching a DigiPen class and they need 30 hours of material (DigiPen 0nly supplies 60 of the 90 hours). So, I am working with him on some game design activities. A coder does not make a designer.

Seth Jaffee said...

No, a coder does not make a designer... but Chris' point was that learning to code can make a designer better.

Clive said...

I think I agree with Chris' comment. If you are a designer then knowing how your information is going to be coded and how it will look and work will help you in your designs. But I don't think it would make a poor designer a better designer (if that makes sense).
Certainly seems like it could or should have been an interesting discussion.

sirkerry said...

Staged Tool Gating - unless I misunderstood what you're referring to here I think FFG's Mansions of Madness uses this concept/mechanism in some of their scenarios.