Monday, April 26, 2010

The Horizon Looms Large


No post this week, unfortunately. DeathSpank is in the final stages before certification, which is tremendously exciting, but also a mountain of frantic work. For those that haven't finaled a game, it involves fixing wholly unexpected bugs like:

Description:
If game is paused as controller is unplugged and submerged in a bucket of chum, game will hang and possibly shock player.

Steps to Reproduce:
1. The user starts a new game.
2. Submerge controller in bucket of shark chum. Water will not work.
3. Pause game and unplug controller simultaneously.
4. Notice that upon cleaning and reconnecting controller, game will not respond.
5. User may be severely shocked if hands are improperly submerged in chum.

Please see attached screenshot.

Suggested Fix or Results:
Game should not hang and/or player should not be horribly electrified.

(I say this having nothing but love and respect for our awesome QA guys. However, they find the most amazing things that I can hold no one but myself responsible for.)

I'm really looking forward to having other people finally play (and hopefully enjoy) DeathSpank. Being able to see the finish line is great, so I hope you'll forgive the mild downtime during the final sprint.

Labels: ,

Monday, April 19, 2010

In Medias Ludus


Continuing with the discussion of games and improv theatre, Michael wrote a great post this week about how the methodologies of improv can be applied to Sleep is Death (and life in general). Given the inherently extemporaneous nature of that game, improv techniques are quite directly applicable. But, as I alluded to last time, while I was reading Truth in Comedy, I was struck by how relevant their observations were to digital games in general.

Michael writes, "A Player needs 3 things: 1) A character who wants something. 2) A clearly defined situation, ideally with an inherent obstacle or conflict. 3) Strategies for getting what you want."

When digital games go off the rails, typically one of these three things is absent or vague. The player's goal is unclear ("I don't know where to go now"), the obstacles read poorly ("Is this room a dead end or did I miss a door somewhere?") or it's not clear how to start achieving the goals ("I can't see any way to open that door"). When I'm banging on about readability, this is what I'm talking about.

Note, this does not mean everything should be painfully obvious. The problem is when the player is at a dead end and feels like they have no means of discovering what to do or how to do it. Having to explore and puzzle things out is good, having absolutely no idea what to do and being reduced to trying things completely at random is not (e.g what happens when you're stuck in basically every old-school adventure game).

The other interesting lesson from improv I wanted to call out is "Start in the middle." Rather than starting at the beginning of some action or narrative, which tends toward unexciting exposition, the scene starts in the middle of some event. This technique is called "in media res" or literally, "into the middle of affairs." It's more common in film and television (e.g The Usual Suspects or Reservoir Dogs) than in games.

Despite my increasing intolerance for their staid mechanics and overwrought narratives, a number of JRPGs including several Final Fantasy incarnations have used this technique to good effect. So did Uncharted 2, both Max Payne games and the recent Tales of Monkey Island, for example. And of course, Planescape: Torment's "You wake up on a slab in The Mortuary" may be the best in medias res opening of all.

Opening in this fashion is still quite uncommon though. I wonder if part of the reason why more games don't open in medias res is that the character's mechanical progress moves with the game's narrative progression. By opening in the middle of some action, it may seem harder to have the character mechanically progress from there (and if flashbacks occur, one might feel like abilities ought to be removed). Many games also open by introducing mechanics in a tutorial-ish fashion, which may be a bit harder to fit into a scene or story already in progress.

A few games also begin in the middle of the game mechanically, but at the beginning of the action narratively. Most notable would be the Metroid Prime series, where that player begins with powerful equipment only to lose it after a short opening scene (I think Super Metroid opened this way as well, but I can't remember for sure). These abilities are slowly recovered until the player eventually surpasses that initial state.

We might call this structure "in medias ludus" (Update: make that "in medium ludum," thanks Roger!) if we wanted to be delightfully pretentious, and to be honest, I'm not sure how successful I feel it is. For me, it often gives the feeling that for at least the first half of the game, you're behind the curve and simply playing catch-up. The Metroid series is so well engineered, and this formula is fundamental to its gameplay, it works. But other games that have attempted this, most recently I remember Prototype doing so, don't work as well.

I generally like in medias res openings, partially because it dovetails well with another improv lesson: "Take the active choice toward forward action." Especially in improv, given the choice between discussing some possibilities and simply doing one of them, always opt for the latter. While Shakespeare can make Hamlet-esque indecision fascinating, neither improv nor games are particularly suited for this. If a game explicitly offers a choice, it ought to be between one type of action or another, not between action and non-action. And by "action," I simply mean something meaningful for the player to do, not "action" like shooting guys in the face.

A great many games have sleepy, unengaging beginnings, rife will text-laden tutorial billboards and mundane tasks. This is something no game can afford, especially for those of us in the digital download space, where demos and conversation rates are of vital importance. But even more fundamentally, opening in media res can help focus a game. Starting at the beginning makes it very easy to justify a bunch of dry exposition about characters and a world the player doesn't care for (yet, hopefully). Starting with action and conflict, something that will be engaging for nearly everyone, we can draw players in. Don't throw a bunch of narrative at the player right out of the gate; wait until questions have been posed before supplying answers.

At the end of the day, our currency is engagement. Structuring a game to start in media res is only one approach. The first five seconds to five minutes of a game are vital, however. All games would be well served by a careful consideration of this portion of the experience.

All that from a short book about improv, eh? Again, I highly recommend it.

Labels: ,

Monday, April 12, 2010

Truth, Improv and Games


I read Truth in Comedy this week. If you look past the 90s "wacky font" adorned cover, inside lies a surprising and excellent book (and one not unrelated to games). It's only incidentally about comedy; it's about improv theatre, specifically an improv structure called the "Harold." The Harold was developed by Del Close, one of the premier influences in improv and if you look at his list of students, you'll see he trained an absurd number of now-famous folk.

Coincidentally, Sleep is Death was also released this week. While not exactly improv, Sleep is Death certainly shares some improvisational qualities. I haven't had a chance to dig into it yet, but it seems like it possesses the same semi-structure of tabletop RPGs. I've seen some discussion about Sleep is Death devolve into scoffing "Why not just play D&D?" style comments. But I think the structure of Sleep is Death is different enough to be quite interesting.

The representational layer Sleep is Death puts between the Controller and player both constrains and frees the storytelling. All interaction is mediated by the simulation; you cannot see the Controller nor can they see you. It sounds obvious, but that's a big distinction from live roleplaying that mimics real social interaction. And the dynamics of a single player and Controller definitely differ from that of a group of players.

The best response to any scoffing about tabletop RPGs vs. digital ones was presented by Kieron Gillen on RPS. Go read it.

Unfortunately, much like tabletop RPGs, I can only imagine the quality of the experience will vary wildly depending on who the player and GM/Controller are. And, again like tabletop RPGs, there will be a raft of cliched stories, some extreme awkwardness and a few shining gems. I hope finding those gems won't prove to be too difficult. At least with Sleep is Death I won't end up in the basement of an over 30 man that still lives with his parents. A basement whose walls were lined with Star Trek figures, still in the package (seriously, that's no exaggeration).

Anyway, that's enough carrying on about a game I've barely had time to investigate. Back to Truth in Comedy. Given that improv is all about a group of people collaborating to create something from nothing, it shouldn't be too surprising I found parallels with games. There were similarities both with games themselves and team dynamics of creating games. Given what I wrote last week, I'll make a few observations about the latter and the former in a separate post.

One thing stressed in Truth in Comedy is the absolutel necessity of the group working as a single entity. Agreement with fellow players during a scene is the cardinal rule. It's "Yes, and ..." that all improv is built upon. It's trusting your fellow players will provide the information you need and that they will support whatever decisions you make. It requires sublimating one's ego for the benefit of the group. As the authors succinctly put it, "The best way for an improviser to look good is by making his fellow players look good."

The same clearly applies in any team-based creative endeavour. Granted, improv has a bit more freedom in that its creations are inherently transitory and even the wildest of ideas can be chased. But when it comes to game teams, that same trust is vital. Developers have to be confident that their teammates will not judge them based on how successful an idea might be. A judgmental climate means people will be more conservative with their ideas and with their work. Rarely will this benefit a game's development.

The audience of players isn't going to care which name on the credits was responsible for some particular success or failure. The only evaluation they will provide is of the work as a whole. And thus, everyone must focus on the work of the group as a whole, not any particular individual.

Now obviously, I'm not going to fire up Maya or Photoshop and tell an artist what to do. But rather, everyone should feel like their decisions will be supported. The team will provide honest and non-judgmental feedback, and more importantly, will help in making their ideas real. When everyone operates with the same singular purpose, to make the best game possible, disagreements are possible without a feeling of someone having to "lose." One line I particularly liked from Truth in Comedy was, "Treat others as if they are poets, geniuses and artists, and they will be."

Reading Truth in Comedy, I couldn't help but feel that the attitude it presents is similar to the one I see manifest at events like the Global Game Jam. At game james, four or five have to create something from nothing with little preparation. It's clear that the groups that succeed are the ones that trust each other and work with a single purpose. The ones that don't succeed often bicker and measure egos about the "right" way to do something.

I'm definitely going to be checking out a few Harold-inspired improv shows in the weeks to come, but more importantly, I'll be thinking of ways I can better support my teammates and keep our ultimate purpose in mind. Truth in Comedy really was an interesting read and I highly recommend it to basically anyone.

Labels: , ,

Tuesday, April 6, 2010

Share and Share Alike




Making games is hard, but it is hard for reasons some may not expect. Technology isn't the biggest challenge, deadlines and budgets aren't the biggest problem. I've learned that the hardest part of making games is making games with other people.

I do not mean this in a negative way, grousing about how difficult other people are. Rather, for me at least, transitioning from academia where you are basically the only one responsible for (or, let's be honest, who even cares about) your work to an environment where two dozen people all have to execute the same idea is a big sodding change. One of the things I took away from GDC was that this is a bigger deal than a lot of people are willing to acknowledge.

Honestly, after spending all my years in university (and even at one crappy start-up) doing primarily solitary work, I never want to do so again. It's not that working with other people is unpleasant; I love it and I'd go totally barmy if I couldn't do so. But it is different and learning to recognize and even harness those differences is not necessarily obvious or easy.

I think at the end of the day, it's really about trust. You have to be able to trust that your teammates are all working toward the exact same goal (make the best game possible). Everyone has to feel some degree of ownership for the project. But at the same time, solitary ownership of ideas can be very dangerous.

The problem is ideas that are distinctly owned conflate the person and the idea. If we determine John's idea isn't viable for our game, some could see it as a reflection on John's competence. John may end up defending a clearly flawed idea, simply because he's worried if it's not accepted, it will reflect poorly upon him. It takes a mature and trusting team to simply see an idea as a hypothesis to be tested.

Matthew Burns (aka Matthew Wasteland) wrote an article for Game Developer Magazine examining the production processes at Harmonix, Treyarch and Valve. (It's in the issue that was given at GDC and is a great article, so copies abound and you should find one) Within the article, Valve's Robin Walker provided this quote, "The goal isn't to get my particular idea in the game - the goal is to be right." This is what we all should aspire to.

The question becomes how to move toward that state. One practice I've found useful is to literally swap ideas. When working on a pitch, a new feature, whatever, literally exchange your ideas with a teammate's. Have them send you their write-up and send them yours. Work in isolation for a little while and then meet. This structure has the added benefit of knowing someone else will examine and tinker with whatever you come up with, so it ought to be your best work at its most cogent.

Not only does this give you better perspective on what they are thinking, but it allows you to start discussion at the points of intersection (or even points of divergence). It separates you from your work. Being wrong is fine (I'm wrong *all* the time, believe you me), as long as we learn something from being wrong that will move us closer to being right.

And from a purely logistical standpoint, bottlenecks are terrible. Having one single person responsible for the lion's share of decisions does not work in all but the most unusual of circumstances. Even if it does work once, I'm deeply skeptical of it being sustainable. We've all heard of tales where a single, all-important stakeholder ends up looking away from a project for a period of time. Upon return, they see all kinds of changes not to their exact liking and all hell breaks loose. Maybe I'm in isolation, but I can't imagine wanting to continue working under such circumstances.

The most important quality a team can possess is trust and it's also the hardest to cultivate. Of all the discussions about team and culture I heard at GDC, this aspect echoed most frequently. I certainly can offer no sage-like wisdom that will suddenly imbue trust in a group of people. But I do believe that the importance of a culture of trust is grossly underrated. Working to separate people from ideas is a single way to move toward a more trusting culture. If you have any more experiences with building trust on a team, I'd be curious to hear them.

Labels: ,