malvasia bianca

Thursday 9:00am–10:00am: “Classic Game Postmortem – Out of This World/Another World“, by Eric Chahi

This was a look back at the making of Another World.

Overview of the creative process. Freedom under constraint: an improvisation process.

Initial context. July 1989, the Amiga era. He’s 22 years old, but had written a lot of games; taken 3 weeks to 6 months, none really successful. Dragon’s Lair had just been released: how to do this?

2D game based on polygons. Cover lots of the screen with not so much data. Also wanted to use rotoscoping techniques, inspired by some new hardware. But: is it possible to draw polygons at the right speed? Experimented, yes. So graphics unit: polygons and only polygons, that’s a key constraint. He was obsessed with this: how would a potato look in polygons?

At times, he used “pixigons”, polygons the size of pixels. So the first level took too long, doing pixel art in an obtuse fashion. He ended up using bitmaps for the backgrounds, to increase detail, but only ten bitmaps in the whole game.

Create a 2D game with a cinematic feeling?

He didn’t have suitable tools available, so he had to create an engine and tools from scratch. He wrote a polygon editor, and an interpreter for a homegrown scripting language for the game logic. (Including animation!) Shows the main character in the editor, including a demonstration of groups of polygons. (E.g. the head.)

Fusion between code and graphics: you can modify the graphics in the polygon editor and see the interpreted code change, or vice-versa.  It was a very simple language, with only 256 possible variable names; he ended up writing down the meanings of variable names on paper! The engine had 64 tracks, each of which could run its own code. (Like a multi-track audio mixer, I guess.)

December 1989: tools and engine were usable, albeit flawed. One flaw: no common data shared between levels! So he copied data back and forth, which was a nightmare when tuning: each change in Lester’s behavior had to be done five times.

Did the initial animation. Polygons worked well; rotoscoping, not so much.

Tried hard to listen to his inner self. Including surprising himself: what would he expect as a player at a given moment, how can he subvert that expectation? E.g. when player is transported initially to the other world, initially thought that the player would appear on the surface, but much more surprising if he appeared under water.

The basic gameplay mechanics were inspired by Karateka.

16 colors in the palette. Which meant that he needed to have multiple uses for colors: e.g. used the main character’s flesh color for sunset highlights. Using black hair would have been useful to that end; but then the character would have looked too much like Eric himself, which would have been disturbing! Red hair loved that latter problem, while still being a reusable color.

He used parallel action in the background; but then the background action comes to the foreground (the lion appears), with a cutscene ad punctuation, then varies up the pacing in the subsequent chase, backtracking, rescue by a hooded figure.

That ends in a cliffhanger; the next scene starts by removing the hood (in a different location), so he could learn what’s under it! And then friendship gets introduced, including the only closeup of Buddy’s face.

Also, this level introduces both weapons and shields. That combination turned out to allow a lot of interesting gameplay combinations. (Especially whe you throw in the slow shield-destroying plasma shot.) Do you use a fast shot, take the time to set up a shield, take still more time to destroy a shield?

Also, going from the top to the bottom of the screen: he’d initially planned to use an elevator, but a teleporter felt better.

At the end of the jail level, it was clear that you’d have to meet Buddy again later.

December 1990: 17 months in, only 1/3 of the game is done. So he needed to work faster; he focused on puzzles that used the same building blocks he’d already established. The frame of the story ended up being a series of meetings and separations between Lester and Buddy. (That wasn’t the plan at the start: improvisation.)

He used separation of foreground and background more: that gave a cut scene effect without interrupting gameplay. And played more with pacing.

Publishing. He met with somebody at Virgin Games: they tried to convince Eric to make it easier by converting it into a point and click adventure. He was tempted, but decided not to; went with Delphine Software, who were supportive of the existing software.

June 1991: time is running out (it was scheduled to be released in November).  How should he end the game? He went through the game so far, and drew a map of key past events; he decided to play with the pace, leading to the area scene.

The cover illustrations of his previous games had been particularly unsatisfying. He was already passionate about illustration, and Delphine Software was willing to let him illustrate the cover himself. But he didn’t have time!

Also, they weren’t doing enough play testing. They found a few issues, but it was still unbalanced. Later, Interplay ported it: they polished some aspects, but also wanted to make the game longer, more difficult.

Interplay wanted to change the music, which he really objected to. They had a long war via fax, which eventually led to Eric sending an infinite fax, consisting of a looping strip of paper in the middle of the night, saying “keep the original intro music!” Interplay didn’t change their mind, but Delphine pointed out that Interplay had no legal right to change the music.

Console porting led to a bit of censorship, about an alien butt-crack. He considered sending an infinite fax, but decided to remove three pixels instead.

Eric was exhausted at the end, which is probably why Lester is almost dying at the end of the game.

He’s surprised at how long the game has lived: in fact, its being ported to iPad now!

I’ve broken out two of today’s talks into their own posts:

• Clint Hocking on “Dynamics: The State of the Art”
• Jason Booth and Sylvain Dubrofsky on “Prototype Through Production: Pro Guitar in Rock Band 3“

The rest:

• “Video Games Turn 25: A Historical Perspective and Vision for the Future”, by Satoru Iwata
• “GDC Microtalks 2011”
• “Seven Ways a Video Game Can Be Moral”, by Richard Rouse III
• “Designing Limbo‘s Puzzles”, by Jeppe Carlsen

9:00am–10:00am: “Video Games Turn 25: A Historical Perspective and Vision for the Future”, by Satoru Iwata

I actually liked Iwata’s 2009 keynote; this one, not so much.

25 years ago: no industry, just a hobby. Would wear lots of different hats: game designer, artist, sound engineer. Lots of fun; made almost no money, what we produced was primitive. “Video game cavemen.”

Now: more graphics power, more memory, much more costs. Much larger teams, longer timescales. Fortunately, more people are playing games: Nintendo’s basic strategy is to expand market. Sales alone not the whole story: when are machines shared? In 2007, 45% of US population had played a dedicated game console over the last year; in 2010, 62%. More room for growth in Europe, and then there’s emerging markets.

Social network games are different from video games of a social nature. Space War; multiple component ports; wireless communication on handhelds; online play.

“Must-have” comes from three sources: hardware (e.g. Gameboy; not easy); game; social appeal of connecting with other players.

Mario always evolves. Pokemon popular because of social nature. Tetris first video game to attract a female audience in a meaningful way. The Sims: maybe not even a game, no way to win or lose, but phenomenally popular.

Universal appeal. First Kirby game went against then-current trend in action games of being very difficult: designed so that almost anybody could finish it.

Selfishly, hopes Nintendo 3DS is next must-have: because of technology, because of games, because of social appeal. Built-in applications are designed to increase social appeal, and to encourage people to carry the 3DS everywhere to get passive data transfer.

Now Reggie is on stage. Says nothing interesting. Iwata back, game teasers. Then:

Three concerns. First: craftsmanship. Often gets lost as projects get bigger, more complicated. Second: talent development. Too much specialization, hard to assess entire personality of a game. Third: too many games, often cheap or free, so hard to make enough money to survive. is making high-value games a top priority, or not? Smart phone / social network platform owners care more about quantity than high value.

Getting noticed: capture attention immediately; easy to describe unique nature of game to others. With these, reach tipping point for word of mouth. Innovation: make the impossible possible. Trust your passion.

12:00pm–1:00pm: “GDC Microtalks 2011”, by ten speakers

As always, these were excellent, and impossible to summarize: it’s just an experience that washes over you.

Richard Lemarchand: intro. Microtalks means 20 slides, 16 seconds each = 5 minutes 20 seconds. Theme: Say how you play.

Michael John: is the father of computer games the computer, or games? Code fear pulls us to latter, but former is correct. All games are played; not all play is games. Mention of education. Kids should be making computer games; everybody should know how to program. Making game with his daughter.

Jamin Brophy-Warren: Kill Screen! Think about video games as (design) objects. What is a toaster? Lash-up of various properties/components. Games are objects with stories; game players are storytellers. Objects increase in value by being linked to stories. Not currently good at telling stories about games to those outside of our circle. Lacking a common narrative tongue. Overcome the dinner table story, embrace our stories. If we don’t tell our stories, they fade into the ether. Here’s the text of his talk.

Naomi Clark: Tarot decks, I Ching. Divinatory systems give rich matrix of ideas to associate with. Social games. Games of labor. David Sirlin prefers games of skill. And then there’s the fantasy of games of chance. Games of labor also have a fantasy. (As do games of skill: “adolescent delusions of badassery”.) Game designers’ fantasy: fantasy of control. Leave more empty spaces in our games, more pauses in the experience of play?

David Jaffe: Personal gaming setup moving more to portable space. Gap from turning on (non-portable) console to playing. Low-end: 1.5 minutes. High-end: 3+. Lots of other options without that boot problem. Sleep mode? Restrict updates? Shorter games? Multiplayer: best one-on-one, worst with large teams.

Colleen Macklin: Playtesting: the call of the wild. Don’t want to domesticate games too much by excessive tweaking, though. Game we played: want to stay in minority as long as possible. (Didn’t work too well…)

Asi Burak: Text adventures.

Jason Rohrer: Boredom has survival value, perhaps, but not great in games. Don’t want a spoonful of sugar with medicine: want fundamentally delicious medicine. Paintings engage for seconds; music for minutes; movies for hours. Latter engages more you than former. Engagement with plot also has survival value. Games super-engaging, lasting dozens of hours: you can’t even knit while playing them. Survival value of engagement with challenge is obvious. Fight against challenge in games is as hopeless of fight against plot by avant-garde movie directors. But need more plots. Similarly, need more varieties of challenge, while embracing it as potent expressive tool in its own right.

Brandon Boyer: Originally, approached topic with melancholy: more interested in David Foster Wallace, Spalding Grey recently. But then: Little Big Planet, Retro Game Challenge as tragedy. Power of aesthetically pleasing abstract systems. …

Brenda Brathwaite: Wow.

3:00pm–4:00pm: “Seven Ways a Video Game Can Be Moral”, by Richard Rouse III

Wednesday 3:00

Last year: how a video game can make you cry. Sort of a joke talk; this year, on morality, more serious. Moral storytelling a rich tradition, and not easy when done well. Clint Hocking 2007 talk: great game with great systems helps a player explore themselves. He mentioned Ultima 4. That’s 1985; what has changed in the intervening 26 years?

1) Clarity of Intention

Romeo and Juliet lays out the scenario right at the start, with the two warring houses, star-crossed lovers. (Editorial note: spoilers right at the start! Shocking.)

Video games also signal moral issues: Star Wars games saying “Choose Your Path” on the back of the box, morality meters in BioWare game.

Flip side: don’t always have to make your intentions clear. E.g. Rod Serling positioned The Twilight Zone as pure entertainment, even though it wasn’t. Games can do something similar, e.g. Blade Runner game adapts outcome to how player is playing, with no meter in sight: make players feel like they’re doing the right thing.

2) Multiple Points of View

Star Trek example. From original series, and Next Generation; recent reboot movie left moral issues on the side. (But Battlestar Galactica reboot faces moral issues head-on with multiple points of view; answers are much less tidy than in Star Trek.)

Game example: Alpha Centauri. Different factions make different choices in how to build your society, other factions would respond from their own perspectives. The game designers deliberately didn’t take sides between factions.

3) Redemption

Twilight Zone again: characters make bad choices at the start, but learn something after their journey through the zone. (At least if Rod Serling liked the character…)

Mass Effect 2: two independent meters, filled up slowly: largest choice is 45 out of 1900. You want to fill up one, so are encouraged to chip away in one direction. In contrast, Fallout 3 has a single karma meter that you can completely trash with a single early choice: this sets up the possibility of a redemptive journey.

4) Complexity

The Man Who Shot Liberty Valance. Jimmy Stewart wants to uphold the law, but is notorious as man who shot Liberty Valance. Except he didn’t, John Wayne’s character did. Neither of those two is the good guy or the bad guy.

BioShock: Andrew Ryan plays role of villain, but not clear that he did anything villainous. Tenenbaum portrayed as good character, but she did concrete bad things early on. (In contrast, save/harvest is a lot shallower.) BioShock 2 has you decide to save or kill three characters; two have tried to kill you, the third wants you to kill him. More complex, but the “Savior” achievement undermined this complexity: the game’s creative director wished he’d removed it. Similar achievement in other direction in Red Dead Redemption.

5) The Quandry

Example from The Wire: drugs out of control, destroying a city, so police decides to ignore it if it’s in a few limited areas, improving rest of the city. Example from a movie where a kid was kidnapped out of a bad life, into a good one.

Not good example in video games. E.g. No Russian level: you have the choice not to shoot at all, but not more meaningful choices. Train is more successful.

6) Thoughtfulness and Respect

Never Let You Go: doesn’t treat some surface issues directly, instead more obliquely in the context of exploring the characters’ stories and grappling with their short lifespans. In games, The Sims: looks materialistic, but items will fail catastrophically eventually, giving a disincentive to buy for more experienced players.

7) Medium, Genre, and Message

The Grapes of Wrath. Tom Joad has to leave his family to avoid getting them in trouble with the law. Bleak departure speech in the book; movie version of that speech has a much more uplifting tone. And then Bruce Springsteen wrote it into a song; closer in tone to the book, but more lyrical. Rage Against The Machine performed the same song: Tom Joad is going to kick some ass! What would video game version be like?

Final thought: Truffault version of Farenheit 451. Interactive TV scene: looks like a superficial video game choice.

We’ve seen techniques; techniques are the easy part, committing is the hard part.

4:30pm–5:30pm: “Designing Limbo‘s Puzzles”, by Jeppe Carlsen

The game has minimalistic design: no levels, no cut scenes, no power-ups, two-button controls.

Puzzle design principles: challenging problem solving, simple elements, few elements, complex problems but simple environments, no repetition.

Showed a chain puzzle. Need to get chain swinging properly so that, when you set it in motion, you’ll be able to grab it and use it to swing over a dangerous area. Only three elements: chain, button to control movement, dangerous ground. But still not super easy: need to experiment and analyze failures to solve.

How develop the puzzle?

1) Predict the player: how will they approach the scene? Come in from left, almost certainly press panel when passing it. See chain slowly moving left to right, try to get on before it’s too late.

So: need to be fast enough to catch the chain? Try and fail, but learn something about environment while doing so.

If chain had gone right to left at start instead of left to right player would instead have gotten on and started swinging right at the start, immediately getting much closer to the solution. So that would make the puzzle too early.

The player is my enemy: devious trick. The player is my friend: accessible environments. Usually start out too devious, make it simpler. Showed earlier version with two switches and a movable block to stand on; way too complex, but while playing around with it, realized that key trick of the more complex version is setting the chain swinging to make it possible to jump to it from a distance. Then simpler version with the final elements, but missing the key initial misdirection.

The correct solution must be easy to execute: worst case is if player concludes that a correct approach he’s doing is not possible. Conversely, wrong solution strategies must clearly communicate that they are wrong, so you learn from your death.

Now: level editor demonstration!

Place boy, floor; boy automatically runs around on the floor. Add slope, crate. Boy tries to push crate, but it’s too heavy. Fiddle with weight, boy then pushes it up the slope. (Very impressive automous boy.)

Example of trigger modifying behavior of objects. Timer script example. Changing gravity example. Have gravity periodically flip up, down.

Great for fast prototyping; not easy to read scripts, though, even in simple cases. All the symbols for a puzzle are on the screen at all times. So once puzzle is pinned down, often replace script with a few lines of code. (He later showed a real in-game puzzle where the script looked unworkably complex.)

Wednesday, 1:30pm–2:30pm: “Prototype Through Production: Pro Guitar in Rock Band 3“, by Jason Booth and Sylvain Dubrofsky

The slides are available online.

In 2008: music games were a big thing, needed to innovate.

Harmonix has this idea of The One Question that they focus work on a game around. For Guitar Hero: is it rock? Rock Band: is it an authentic band experience? Rock Band 3: used the same question, but make it more authentic. Which leads to: pro guitar, have people play on a real guitar, really learn how to play!

First, 3 months of early exploration. Question: is the problem space to teach people how to play guitar, or to pay RB with a real guitar? These don’t actually intersect that much. Target audience: hard/expert RB guitar player.

Use the illusion: mute/unmute the sound of real tracks, so the first time you get it right it sounds great. This is very unlike learning to play on a normal guitar, where you sound awful for a long time.

How to notate frets and strings? First idea: fret relative. Columns represent frets, represent strings some other way. Didn’t work so well, so tried having columns represent strings. Worked a little better, still issues to work out.

And some early constraints. It had to: display notes, chords; be pitch accurate; target non-musician RB players. It didn’t have to: work with bass; work with all songs; work in all game modes.

This was enough to give them something to work with when they had time, and to assemble a small strike team. Benefits: implementers make decisions. Focused meetings. Seating proximity. 

How they prototyped. No good hardware solutions: cost, latency, accuracy problems. Do whatever works best for now, use info to inform later decisions.

Question: how to communicate what to play? Approach: focus on building muscle memory, not music theory. Traditional notation good for conductors, highly compressed (e.g. key signatures). Guitar players use tablature instead: physically centered. But it has more problems: doesn’t work well with chords, rhythms. Third possibility is chord charts, but only works well with chords.

Need something else. The notation should be physically centered, compressed enough to be recognizable at a glance, work with time.

Different chords have different shapes on your hand. Can play same shape at multiple places on fret board, how to represent that? Also, what about riffs, loose strumming, arpeggios? All opportunities for compression.

So: new notation system, string relative. Should it be horizontal or vertical? All music notation is horizontal, so it must be better. First version could work either way; they found horizontal moved too fast, hard to represent shapes. So vertical was better.

Song selection for early prototypes. Did songs that would definitely work, e.g. I Love Rock and Roll. Also simplifies early prototyping if doing a 3-chord song!

Next questions: how teach chord shape? What info do they need to understand what to do with their hand? What else do they need to know?

First idea: inline training into songs. Really jarring, though. Next idea: chord book. Tried virtual hand, but players didn’t look at that. Players just need to know what they need to do and what they’re doing wrong.

Added in a “wait mode”: when learning a part in real life, you pause periodically while figuring out what to do next. So they’d do the same thing, where the game would pause while you put your fingers in the right place.

They play tested with various internal groups: little musical experience, lots of musical experience, little guitar experience, lots. Asked how fun it was; players weren’t sure that was the right question, but they persevered.

Big question that playtesters had: what is their left hand actually doing? So they wanted to show the shape hand was actually in.

Still problems: upfront learning, complex chords, screen real-estate, not all songs work well. Won’t be able to solve all of this, but wanted to chip away.

Had done enough to inform hardware requirements: need to know what left hand is doing, need low latency, need low cost. Ideal is actual guitar, but that has problems: never been done, could be expensive, strings break. So maybe plastic guitar approach? Decided to pursue both approaches, and ended up shipping both. 

Prototyping suggestions: reduce team size as much as possible. If an idea / issue keeps on coming up, you need to try it. Don’t skimp on low-hanging fruit.

Cycle: establish core goals and constraints, hack it in, playtest, repeat.

Prototyping took 7 months; on to production. (Which took 13 months.) They were confident coming out of prototyping, decided to raise the stakes. Do it in every song, every mode; anybody can learn easy, every note is in expert. Training on all song on all four difficulty levels, plus bonus music training.

Still need to figure out: standard RB stuff (hopos, solos, …), advanced song techniques, song authoring.

Problem 1: hardware. No MIDI drivers. Seven bridge modules to translate from MIDI to Xbox. Eventually got 7 of the plastic controllers, 3 of the real ones.

Problem 2: late content. Don’t pick all of final setlist until shortly before shipping. Decided to pick snippets of famous songs, to shake out issues. Famous songs, songs that should work well, songs that would stress the system.

Authoring solidifies: easy, medium, hard, expert guidelines. (medium simple chords, hard still parseable in real time.) And 17- vs 22-fret guidelines.

Worked on general theory lessons, too.

Prototype to production took a lot longer than expected.

Problem 3: slow progress. Increased team size, so no shared history. Needed more external focus.

Got back on track: refocused on target audience. Switched to short-term deadlines.  Pulled playtest dates forward to expose problems sooner.

Playtest revealed lots of little issues, and the chord book wasn’t working as well as they’d hoped. But a lot of things worked well; if they could nail those, they’d work well with their core audience, move on to more advanced stuff.

Added numbers to hand shape; pulled chord learning into songs. Then that gave them time to implement a lot of wishlist items.

I asked about the lack out auditory feedback for mistakes. They thought about it a lot, but decided that preserving the illusion was so important that they wouldn’t even allow it as an option.

The entire day posts are getting too long‐Monday’s was almost 4000 words—so I’m going to break talks I particularly liked out into separate posts.

Wednesday 10:30am–11:30am: “Dynamics: The State of the Art”, by Clint Hocking

This is my favorite talk of the conference so far; I really hope he posts his slide deck and more thoughts, because I’ve only barely begun to process it, and I’m sure there’s a lot I missed. My notes:

A question Chris Hecker raised in the 2009 GDC: how do games mean?

In film, there’s something called the Kuleshov effect. Audiences read emotional response from context: an identical actor in an identical scene (literally identical, same film spliced in twice) is read differently based on adjacent footage. Editing is key in generating core meaning of film. Without understanding that, cuts would be at odds with higher-level meaning; we’d avoid cuts, do wide-angled shots, avoid opening and closing scenes while focusing on characters. Film would look like stage plays, but missing the fundamental power of that medium.

So: how do games mean? Answer: via their dynamics. Which are the run-time behavior of mechanics.

E.g. to whip in Spelunky, you need to raise it before you can hit. Leads to atmosphere of deliberation.

Does meaning come from rules governing the whip, or the way the player plays using the whip? Problematic word: “play”. Games are like player pianos. Different in that the player piano can play by itself: think instead of a player piano roll that’s half of a duet, expecting a human to play the other half. You can weight the piano roll versus the human contribution in different amounts; for video games, both parts are always present.

Splinter Cell (original and Chaos Theory) have meaning more on authored side; Far Cry 2 more on player side.

Chaos Theory is about chaos theory: sensitivity of systems to small changes. Sensitivity, proximity, fragility. Both Splinter Cells; original forced player to follow guard, use thermal vision to read finger prints on keypad. In fact, if you were too good, followed closely enough to not need that, you’d get a game over. Chaos Theory loosened that sort of restriction: use thermal visioning, follow guard, interrogate guard, hack computer, hack door. So add in possibility of domination and precision as meanings.

Far Cry 2. Original concept: human social savagery more savage than savagery of tooth and claw. And that’s still there: can mean that its horrific, intimate, shameful, in Tom Bissell’s playthrough. But in Ben’s permadeath playthrough, took safe options more, so reserved, safe, boring.

For sale: baby shoes, never worn. This abdicates as much as possible in a story to the player, while leaving an irrefutable meaning. 

Tetris. Dynamics about precision, anticipation, keeping possibilities alive. But it’s really about itself, not anything in the broader human experience. (Which is completely fine!) How could we change that? Borrow from Train: playing field is a train car at the edge of the Warsaw Ghetto. Each line is a car full of people, will only leave if it’s full. Gameplay otherwise identical.

How do you play? Dutiful servant. Schindler: most fill rows, but leave gaps to trains don’t leave. Saboteur: stack up pieces as high and as quickly as possible.

New potential meanings. Not from the mechanics: from the interplay between mechanics and the game’s fiction.

Street Fighter isn’t about a battle between Ken and Ryu, it’s about a battle between two players. Then, he talked about the Shusai—Kitani match, chronicled by Kawabata in The Master of Go. It’s about a shift in Japanese ideals just before World War 2.

Go has very simple rules. Add in tournament rules: time limits, sealed moves.

120th move: Shusai makes move that sets up battle in middle of the board. Lots of questions for how to respond. Kitani thought for an hour and a half; sealed move.

Sealed move was a forcing move elsewhere. So upshot was that Kitani got an extra two days to think about how to respond in the middle of the board. Shusai felt Kitani had ruined the match. Kitani didn’t see anything wrong. Shusai ended up losing by 5 points, died a year later.

Go isn’t about competing world views of Japan, but this game was. Meaning is a synthesis. Meaning is rigorous. And meaning is instantial, determined by how a specific match is played.

1991: Soviet Union collapsed, Cuba lost its dominant trading partner. Average Cuban lost 20 pounds over the next four years. But agriculture responded by moving closer to consumer, worked out well.

Dynamism isn’t a feature: it is the fundamental core of how games mean.

• City of Wonder: Postmortem
• Humanities Unlocked: The Value of Liberal Arts for Your Game Design Program
• We Don’t Need No Stinkin’ Badges: How to Re-invent Reality Without Gamification
• Intuition vs Metrics: How Social Game Design Has Evolved
• Rapid-Fire Indies

10:00am–11:00am: “City of Wonder: Postmortem”, by Troy Whitlock and Scott Jon Siegel

Actually, only Scott spoke, presumably because Troy is no longer at Playdom. (He left a week or two before I did.) At any rate, I was glad to see a postmortem of this game, it was one of my favorite social games from last year.

The game‘s original pitch: expand your city state, discover technologies, battle with armies, from the dawn of history to the present. Take the Social City engine, add in more choice and player-versus-player combat.

Scott thought the original pitch was a crazy idea, had little interest in working with it. Social City was genre-defining, which meant that it had spawned a lot of competition. And Studio 24 (the Playdom studio that he was part of) had previous experience with market saturation: that’s a big reason why Fish Friends failed.

Also, the pitch looked like a niche game; it wasn’t clear it would get the same nice demographic that Social City got. So why do it?

Reason 1: PvP + isometric city builders. Both of those factors do a good job of leading to item purchases. The former affects game mechanics (combat), but doesn’t affect customization. The latter has opposite problem: only aesthetic. Maybe you can merge the virtues: give a stat boost plus expression?

Reason 2: The challenge of making “hardcore” features appeal to casual players, let people do what interests them.

Social City had a good core loop: money, population, happiness: need to work on all three, leading to virtuous cycle. City of Wonder kept the same base mechanics, except it gated new buildings by progress along the technology tree instead of strictly by experience.

Also, the research / technology tree led to long arcs, longer-term goals. Leads to diversity of city appearance. But traditional tech trees look like spaghetti maze: definitely didn’t want that. So they made it much less intertwined: even that, though was potentially too overwhelming for casual players. So they left the full tech tree as a depth on demand feature, but presented a few choices through the main view, with advisors giving specific recommendations. (And, as a bonus, the advisors give the game more personality.)

Also wanted to bring across point of progressing through time, e.g. by giving a parade when you reach the Bronze Age. But in early playtests, players thought it was a stone age game, which not all players were as interested in. So they addressed the sense of progression in the loading screen, in splash text, and in having each age’s buildings having a distinctive look.

Title: Social Civ was its working title. They tested various names; City of Wonder consistently won. Scott didn’t like it – e.g. no use of “wonder” within the game. But they went with it; his current theory is that people like it because of a song lyric.

Embassies: they wanted a neighbor mechanic, and wanted to do that in a way that’s not just a one-time thing, but instead has a concrete ongoing effect on your own city.

PvP: provides a second trio of attributes for buildings, cultural / economic / military. It’s hard to do well on all three, so people could specialize in one or two. The combat outcome (and what played into it) is hard to explain; they iterated a lot on that screen. Emphasized differences between wins and losses, and reinforced distinction between different types of expeditions.

Legends were most fun part of development: enjoyed coming up with quotes (hat tip to Steve Meretzky).

Game as a whole was his favorite social game development experience. Havin said that:

What went right:

• Casual focus, or democratization is a better term – the iPod is an example of what they’re going for, letting user find any song in at most three button presses. So they made main game features accessible with minimal clicks; other features are optional, scalable.
• Iteration. Everywhere: e.g. the placement of buildings/roads in starting layout turned out to make a big difference. Supported via continuous integration, and always having a stable build available. Scrubbed the game every day: errors in text, glitches, feel of an aspect of gameplay, …  Started as 3-hour meeting, got shorter as game progressed.
• Amazing team, split between Mountain View and India.

What went wrong:

• Legends. So appealing that management encouraged them to double down with legends as a trading card concept. Sounded good, but trading card aspects were added in last minute, so not enough iteration: badly balanced, badly explained. (Most successful ones were promoted during pinch points.) Ultimately not sure if feature did more harm or good.
• Embassies. Added somewhat late; main issue they didn’t deal with at launch was “Embassytown”, where your city is cluttered with embassies. Thought it would only affect a few users, but affected many, especially your most engaged users. Eventually solved via multi-embassy buildings.
• PvP. Unexpected side effects of choices players could make, sometimes made players unhappy. No reward in attacking higher-level players: you know you’ll lose, or even if you won’t, there’s not a big reward. So don’t get the excitement of working towards big wins.

The game is still a live service. They recently released the first colony, and there’s room for more. Colonies let them grow the game, even adding new features (e.g. naval expeditions in the water colony) without hurting the core gameplay in the main colony.

11:15am–11:45am: “Humanities Unlocked: The Value of Liberal Arts for Your Game Design Program”, by Mia Consalvo

First, her slides:

She started with a word on advising: “advising itself can be problematic”. At her first job, she received signals that it wasn’t important. At her second job, it was easy to fall into rhetoric like “you only need to take four of these five areas”. Now at MIT: students like math / technology, hard to get them to take humanities.

What is the worth of the humanities? College costs a lot; what will you do with an English major? Humanities programs are getting cut. She’ll present four case studies showing how humanities courses are valuable for game design.

1) Philosophy

Mentioned Miguel Sicart, and a Project Horseshoe white paper on ethical issues.

Ethical theories: virtue ethics (good habits of character, but with balance); utilitarianism (look at consequences of action: are they more favorable or unfavorable (to everyone); duty theory (have specific foundational principles of obligation: e.g. stealing is wrong).

When playing games with good/evil split, players generally take he good side in the first playthrough: it’s easier, more natural, how they were trained. (Even when trying to be bad, players accidentally did good when playing on autopilot.) Why, exactly? Is the underlying theory duty-based? Is it the rules: the good guy always wins? More content: evil in games often means selfish, so you don’t get to do side quests?

Discussion of Zevran in Dragon Age: Origins: she thought she’d been being a good manager, but Zevran turned, she killed him. Then in Awakenings, she had a similar issue; this time, though, it was a character that she’d gone out of her way to cultivate. Ultimately, though, they disagreed about something important, no amount of convincing worked. Which annoyed her at first, but she rather respected the designer’s choice once she’d thought about it more.

2) Foreign languages

Western otaku: lead to interest in culture, languages. Many people took organized courses; some learned on their own, though. And then learned about Japanese people, culture, not just about their favorite anime/games. Almost everybody either had one to Japan or had plans to, almost always in study abroad context, not standard tourist stuff. So: “the cosmopolitan western otaku”.

Can even lead to business: e.g. Carpe Fulgur, who brought Recettear to the U.S., and were quite successful in doing so. Fan interest can open up new, viable markets.

3) Classics

Talked about Sophocles project from the GAMBIT lab at MIT. They had to figure out how to allow player agency while being true to the tragic ending. 

In general: there are a lot of stories out there, but we retell the same ones over and over again in games. How can we tell other sorts of stories? Classics have great source material.

4) Literature

Talks about Edith Wharton: read great example of characterization. Wouldn’t want that much text in games, but very much want characters who are such individuals. Also talked about roles in society: so much games can learn from that, too. (Not least “social games”.) How do we function as groups, as people?

1:45pm–2:45pm: “We Don’t Need No Stinkin’ Badges: How to Re-invent Reality Without Gamification”, by Jane McGonigal

I rather liked this talk. Or at least with a caveat: I didn’t take too many notes because it was going by so fast and because her slides are on Slideshare, so part of the talk turned into my nap. (I’m essentially incapable of going to a conference without napping through parts of one talk a day.) But I really like her emphasis on the positive aspects of what it could mean to bring games to a broader context, and her using the term “gameful” to refer to those positive aspects (emphasizing the intrinsic benefits of games, as opposed to “gamification”, which is generally used more for the extrinsic reward aspects of games). “You don’t need a badge when you have real power.”

3:00pm–4:00pm: “Intuition vs Metrics: How Social Game Design Has Evolved”, by Laralyn McWilliams and Brenda Brathwaite

This was my favorite talk of GDC so far. I don’t think I’ll be able to give a good feel for that here, however; go to Brenda’s blog for the slides, but imagine that they’re delivered with even more character than in the slides.

But beyond that: it was just a super sensible talk: of course you want data when developing games, of course you need to develop and apply judgment to make best use of that data, of course there are minefields that you’ll encounter when navigating this. (Especially because of the culture clash of traditional game design with traditional web app design.) This is a message that still bears repeating over and over again, and we still need a great deal of compassion while figuring out how to move forward.

My notes are below, but I’m not sure there’s anything in them that you won’t get from the slides.

Collision of worlds: traditional game industry versus web apps. Could be great, or one side could consume the other, with bad results. Both worlds have a way of doing things, both think they are right.

Traditional game design: level 30. Social game: level 3. But social game success is undeniable. “Yay! Cake. Ooh! Money!” (Is the “real cake” that traditional game developers make even something that Facebook gamers even want to eat?) Brenda: to make a social game to me is harder than making a Wizardry game.

Both sides nervously hire people from the other side.

Game designers: “I just know it’s going to be fun.” Worked for Wizardry, but to people from the web space, it’s crazy not to ask users and try things out.

Traditional game design: jam shit in, rip shit out, until you find the fun. Clash with web space PMs: your idea of fun is nice, but I think X will be a better user experience, how do we really know? Any data?

MMO experience: sure, jam shit in, but start with shit that’s similar to what you’ve seen work in previous games. And shipping the game is just the start.

To traditional game designers, shipping an unfinished game is terrifying. It might be horrible; what’s worse, people might see a horrible it and love it! Intellectually, alpha testing makes sense; and maybe a couple of years ago you could have released quietly; these days, everybody will notice as soon as you launch.

“The business and Silicon Valley culture is the game.”

Numbers sometimes tell you what you already know. Even if not, though, they’re just symptoms. So: don’t leap immediately from numbers to solutions.

Creativity flourishes within constraints: metrics are one way of providing those constraints.

Don’t blindly follow metrics. Game design is the map and the plan; metrics is the weather report which may cause us to re-evaluate.

Success story one: accidentally released Ravenwood Fair with super easy numbers on various design parameters. To make an appropriate challenge, set numbers back; monetization plummeted. Turns out that players wanted a lot less challenge than Brenda expected; good thing they made that mistake and had metrics to help.

Success story two: Free Realms launched; play time was great, but players didn’t progress beyond level 1. Tried simple fixes, didn’t work. Eventually, observing players, found: camera was a problem, but more important, they were partying! Having a great time, they didn’t care about quests. Would have been hard to find root cause with metrics (according to Laralyn, at least), but very useful info going forward.

4:15pm–5:15pm: “Rapid-Fire Indies”, by ten speakers

Not much to say here: I’ve pretty much given up on trying to convey the experience of microtalks. A pretty good series of microtalks, though.

Chris Hecker: AAA Indie games: polished to perfection, clearly contains lots of love, highly anticipated before launch. First two obvious, talk about the latter.

Petri Purho: Didn’t say much, then played a music video.

Eddy Boxerman: Old devs: he’s turning 40. (Yay!)

David Hellman: Just pictures, but good ones.

Kyle Pulver: Game jams are awesome.

Chris DeLeon: Lots of 20-second bits, followed by Thoreau quotes

Andre Clark: How to be an Indie Punk: The Story of pOnd.

Markus Persson (Notch): Piracy. Favorite bit: the idea of a “lost sale” is the stupidest thing ever. Also: game development as a service. Maybe people who pirate this week will buy next week.

Scott Anderson: Using Technology for Gameplay Innovation. E.g. using shadow physics for gameplay. Inspirations: demo scene; creative coding; molecular gastronomy.

Anna Anthropy: The words we choose as labels define the limits of our discussion. With new tools, distribution methods, game development is available to anyone: “indie” needlessly carves out a group.

This year, unlike previous years, I’m taking notes in my iPad instead of in my notebook. That means that I can generally read my notes, which is good; but it also increases my tendency to just write down slides with minimal commentary, editing, or even formatting. (And I’m sure that amusing iPad autocorrects will slip through, too.) So I apologize in advance for such infodumps: I wish I had time to do a better job, but if I let these posts pile up, I’ll be pretty unhappy.

In retrospect, it was kind of amazing how many talks I went to today: two sessions were really three separate talks each, so that adds up to 11 talks! Wow.

• Creating Your Building Blocks: Modular Component AI Systems
• Ethics for Developers
• Game Design by Accidents
• Click Zen: Zynga’s Evolution from FarmVille to CityVille
• Leave Enough Room: Design that Supports Player Expression
• Turning Depression into Inspiration
• From AAA to Indie: Three Start-Up Stories

10:00am–11:00am: “Creating Your Building Blocks: Modular Component AI Systems”, by Brett Laming, Joel McGinnis, and Alex Champandard

This talk (or at least its first third) was my surprise favorite for the day: I’m pretty sure there’s a lot of object-oriented wisdom here, if I understood what was going on better. Anybody have recommended books on the approach presented here?

It was really three talks in one; the first, by Brett Laming on “Component Systems Revisited”, presented the basic foundation.

He started off with problematic approaches:

• The class hierarchy Ogre : Monster is simply wrong.
• Next, he presented a complex inheritance diagram with multiple inheritance, including a diamond. Worse, you run into situations where you have existing classes A and B where A derives from B, but you want A’s behavior but not B’s. So “deep class” is a problem.
• Next, you push common functionality up, leading to a “fat class”.
• Or you use aggregation to get plugins; lots of indirection, though.
• A data driven approach comes next, but it’s hard to debug.

There are seeds of good ideas in all of these, but you need to know what to pick and choose from them. The metaphor that he suggests is that of a “component”, e.g. as on a circuit board: it gives a broad classification (diode, resistor, capacitor, …), with key properties (that aren’t visible in the class hierarchy!), with defined inputs and outputs, that are interchangeable.

He also added a note on reusable AI: its outputs feed to the gameplay, its inputs come from the gameplay world. And disciplined gameplay is naturally linked to good organization, purposeful data, and sensible lifetimes.

The body of his talk was on five aspects of a component architecture. The first was inheritance:

• Classify where necessary, to define key slots. (Surprising mention of RTTI, e.g. for sorting.)
• Name: RTTI Factory creation; ability to serialize.
• Combined: Data driven approach, with a shallow hierarchy.

This discussion of run-time type surprised me, because I generally see it as a smell. But he was pretty emphatic about its virtues: he called RTTI “as important a tool as a smart pointer or a weak reference”! I think naming is one key route into what he’s thinking: he wants to be able to serialize and deserialize objects in a very flexible manner, to increase the power of tools at game designers’ disposal, and sees RTTI as a key part to that. (But I don’t think that’s the only thing going on.) He also gave examples of macros to help with RTTI (as opposed to leaning solely on what C++ provides), which also makes it more efficient.

The next aspect was structure:

• Spatial: reference frame, world transform
• Functional: composition and aggregation
• Dependency tracking: conflict resolution, job ordering

The third aspect was data flow:

• Data flow: world state -> AI -> gameplay -> world state
• Changes to structure: messages upstream/downstream
• Changes to properties: signaling downstream/upstream, message for spatial barriers

The fourth was compartmentalization:

• Smart objects, reconstructable via RTTI
• This is nearly free, given good structure
• External instructions: AI, animation, etc., carried by signaling

And finally, parallelization:

• The ideal is still a way off
• But AI/gameplay still parallelizes, even in game graphs! (Mention of indirection, aliasing)
• Candidates for parallelization: Leaf output: animation, navigation, component update. Leaf input: sensory info, blackboards, ray tests

He ended with some design tricks:

• Remove temptation: minimal data (if per frame, put it on the stack), minimal lifetime (use new/delete boundary, object pools)
• Favor derivation: no equation contradiction, no duplicate data
• Potential deep class problem: generalize
• Locality of reference: abstraction+composition, placement new, embedded lists, object pools
• Minimize NULL checks: use Null Objects instead when necessary
• Non-virtual pathways: use RTTI filtering
• Many virtual pointers: package once and carry downstream

And his conclusion:

• Gameplay gives us fun buttons to press: tight gameplay leads to good, reusable AI
• Think: minimal classes, data lifetime, locality of reference
• Use: generalization, RTTI, placement new/delete, object pools

Next, Joel McGinnis on “AI Design Patterns”.

The pressures you’re under are: resources (compute cycles, memory), and design specificity (or lack thereof…). Component architectures give you flexibility, and allow performance balancing. He warned that it’s not a blueprint, though: you still need to architect, so it’s not a solution, but a framework for how things can get built.

One antipattern he mentioned was putting data on AI component. Instead, think about the data that the AI component needs to consume: focal point, targetable object, cover markup, interaction point, trigger volume… Granularity is great with component architectures, gives lots of flexibility.

Pattern: Component Matrix

Entities, behavior tree, pathfinding, targeting system, animation, standard movement. Makes it easy to substitute parts out: e.g. if going from lithe enemy to hulking enemy, prototype by swapping out pathfinding component. Lets you answer design questions with minimal investment.

Pattern: Find Via Registration

E.g. target selection looks for targetable objects; both halves register with the targeting system, so you don’t need to search all objects in the world. Reduces the search space by scoping, simplifies construction of behavior, easily done via lifecycle management.

Pattern: Late Construction of Types

Lets you change your minds late in the game, do load balancing: try it everywhere, keep it where most effective. Requires things to be light weight, and data driven helps

And the third talk was Alex Champandard on “Performance and Multi-Threading”.

His talk used influence maps as an example component. How do you make it high performance? You want to use vectorization: SIMD instructions give a 4x performance boost. Then parallelization might give another 4x performance boost.

The solution is to build your build your engine as modularly as your entities. And use the same breakdown in both cases.

He gave an entity example. Then he talked about the system, which does: batching and prioritization. Don’t process individual requests, instead schedule jobs. Custom allocation by jobs to allow interleaving, SIMD. (C.f. the mention of placement new in Brett Laming’s talk.)

Summary: very lightweight, simple interface, handles events, data-driven. Pay attention to memory allocation, computation limits, batching, prioritization. This leads to jobs that are computationally intense and support parallelization.

11:15am–11:40am: “Ethics for Developers”, by Miguel Sicart

His question: what kind of ethical knowledge do future game developers need to know? But first, definitions:

• Morality: a public system, governs behavior towards overs and how to avoid harm.   A system of rules, and principles for evaluating those rules; principles stem from ethics.
• Ethics: the philosophical study of morality. Framework for analysis of moral issues via a coherent, philosophically argued scheme. Provides evaluative standards for development of principles/morals, not only to avoid harm but also to help human flourishing.

There are moral issues of: profession, art form/medium, games in society, and play. We need guidelines. And his outline of a method for acting ethically was: Identify potential moral issues.  Analyze and contextualize them. Deliberate about them, applying ethical theories.

He then talked about four ethical theories, linking each with a problem.

The first theory was consequence-based ethics: decisions should be taken based on consequences. Evaluate based on most desirable outcome for society. This is either act-utilitarianism or rule-utilitarianism.

Data mining and profiling raise moral concerns, especially profiling. Utilitarianism suggests: informed profiling is good as long as most players feel it as not harmful.

His second theory was duty-based ethics: centered on obligations towards others, trying to pursue happiness without harming others. The golden rule.

Duty applies to software and hardware dev: duty of developers to players (which is different from consumers!). Software must allow for play (anti-piracy software problems); some games (e.g. educational) need to be played on legacy platforms.

His third theory was contract-based ethics: contracts between individuals that form society. Often used in the case of right-based issues.

Community management shows how you can use this: a game is not just an entertainment product, but also an implicit contract between developer and players. Developers should understand that the way their communities are managed should allow for ethical reflection.

And his fourth theory was character-based ethics: instead of rules, consequences, contracts, we should focus on being good. Development of virtues and good characteristics leads to general morally good behavior, even in unexpected/new cases.

This helps inform our understanding of player behavior: it’s done within spaced created by developers. Developers should think about good virtues of good players, and create appropriate affordances in the design.

One approach towards ethical issues is via professional codes: these give guidelines for solving issues. If an issue affects the profession, professional codes should help. E.g. crunch, bad management, sexism. Do we need a professional code for game developers?

(Time ran out here.)

11:50am–12:15pm: “Game Design by Accidents”, by Steph Thirion

His basic thesis here is that coding is an idea generator: seeing how code behaves is a great way to confront yourself with surprising realities.

Exhibit A: A programmer making a game based on pentominoes, in order to explore a new computer. No graphics, text-based. He’d just implemented bit where pressing key rotates the piece, and spent a while playing with it: this real-time component is surprisingly powerful, opens up a new world.

He simplifies pieces, adds gravity, leads to Tetris. But: when he started programming it, he didn’t even have the idea yet!

Exhibit B: Jonathan Blow talking about how billiards would change if you could see the future. He did prototype, felt weird seeing it unfold, how the balls ended up where they were supposed to. He didn’t figure out how to make a game out of it, but it sparked ideas that led to Braid.

Exhibit C: A Game Mod workshop for graphic design students with no coding experience. He started by giving them a Breakout clone with no void at the bottom (so balls never went away), implemented in a relatively friendly language called Processing.

He told students to download Processing and the code, to change it, and to make something awesome in six hours. He then showed a video of students’ results, which I thought was really impressive.

Exhibit D: He talked about his background: started as graphic designer, evolved into coder, where in his game Eliss almost everything is produced by code rather than static images.

The takeaways:

• Code makes you stumble into ideas.
• Coding is: complex; precise; unpredictable.
• Code is already there: if you discover something while coding, it’s working right in front of your eyes!
• Simplicity first: you can feel the complexity of code, so it encourages you to keep things simple.

Finally, he ended with a live example using Ruby-Processing. Starts with static circle, adds random movement. Leaves trail, which is kind of interesting; then redraws background to remove trail. Makes background white, circle black.

Then does same thing with 100 circles at once: starts as growing blob, then individual circles emerge from it.  Plays with size of circles: makes them small, more like particles. Large, makes everything a big blob. Random starting position, turns whole screen back, but then puts in outline. Then fills them with alpha, leads to smoggy cloud.

I really liked this example: at several points I was really surprised at shapes and behavior that emerged from such simple changes.

Lunch

I had a very nice chat with Ben Abraham, Jorge Albor, and Brendan Keogh.

1:45pm–2:45pm: “Click Zen: Zynga’s Evolution from FarmVille to CityVille“, by Mark Skaggs

Impossible 1.0: Red Alert 2: made by a team with no RTS experience, made it in 9 months.

Leading up to FarmVille: Zynga was “small”, Mafia Wars was the big dog. His team was trying to make a medieval RTS game, but was stuck in design limbo. Bing Gordon: “Wy don’t you just make a farm game?” Decided to take a small team and go for it.

Fast, light, and right. Single strong voice, passionate team, mission. 5 minute design: if you can’t figure out how to make something more fun, just go with the obvious solution. Only design screens and flows: what the player sees and does. Help from organization: took YoVille avatars, borrowed people.

Decision time: Zynga hardware or Amazon cloud? Zynga’s center ran out of space and power; would have had to wait 6 weeks for more servers, so went to Amazon, which turned out to be crucial for rapid scaling.

Minimal art content for shipping. RTS interface to remove friction, set context sensitive cursor, add queuing.

True Minimum Viable Product: no monetization, almost no metrics at launch! Not at parity feature-wise with other farm games, but a better user experience.

Team goal: 400k DAUs by June 30: 11 days after launch. SVP Biz Dev: if you hit 1M DAUs in 30 days, we’ll take you to the French Laundry. CFO: if you do it in 11 days, we’ll send you all to Paris! They hit it in 5 days; they got the dinner, but not the trip…

That’s Impossible 2.0: people kept thinking growth would stall at various points, it didn’t. Thank goodness that they were on the cloud. But still: had to watch the servers, had to scale the team.

Also unusual: keep the brand pure. Would Disney put this in Finding Nemo? Target audience is moms; don’t want anything in there that moms wouldn’t like; this led to tension with Mafia Wars ads.

One surprise: everything is much harder after launch.

Leading up to CityVille: Zynga was much bigger, they’d had another six games under their belt. FarmVille was still the biggest; Facebook had changed what was allowed, players’ expectations had changed, Zynga’s best practices had changed.

So: what’s Impossible 3.0? The wisdom at the time: FarmVille was a once in a lifetime success, Facebook policies mean you’ll never pass 10M DAUs, their internal model showed a city sim stopping at 5M. Lots of questions: gameplay style, who should develop it (send to their Austin studio?), full featured versus Minimum Viable Product. They spent too much time in paper design which led to imagining problems that might not materialize, so they switched to producing prototypes.

They set a date, locked in art style and rules. Lessons and features from FrontierVille: quests, stories, doobers (loot drops). Converged in Aug/Sep: narrowed scope, get real about date, push for quality. Still, story was missing, and fun wasn’t quite there.

Key mile markers:

• Aug/Sep: team gels
• Sep: game playable, but not fun
• Late Sep: first bits of fun emerge
• Oct/Nov: team plays the game
• Nov: hold for quality, public announcements. Was supposed to be launch date, but game wasn’t good enough. Very different approach compared to FarmVille launch.

Proactive launch steps: lined up external teams to help with live services. Quality high: easier to fix bugs before launch. Feature roadmap. Was smooth compared to other Zynga launches.

They reached 8M DAUs in 2 weeks, 14M in 30 days, over 20M now.

What turned out well: Social: people’s faces, franchising your business. Game loop: right balance of simple sim. Quests.

Could be better: Trains are only kind of cool. Simpler interface for franchises. Expansions were too easy to get. Longer runway on the simulation. More surprises and easter eggs.

Could be better in the process: Didn’t have single strong voice with clear vision. Bigger product, hence more test and integration time. Maybe should have done Minimum Viable Product; not at all clear, though. No scaling plan. No features in the back product, ready for quick deployment after launch.

Meta lessons for social game developers: It’s entertainment: good looking, fun art, fun core gameplay loop. You’re building a product, a team, a 24/7 business, a platform. The battle is won before the launch, fix bugs then. Learn the space, know key features/recipes, know the audience. Speed wins: get to market quickly, and it’s a web experience, so performance matters. Deliver fun: “you can’t make up for boring with volume”.

3:00pm–3:25pm: “Leave Enough Room: Design that Supports Player Expression”, by Randy Smith

He started off with pictures from Fallout 3 that involved posing large numbers of teddy bears.

Is player expression for you? (I.e. indies, this was part of the indie games track.) Yes: indie attainable, indie appropriate, for the good of the art form.

How? Don’t have a string of pearls guiding users down a specific route. Don’t include single solution puzzles. Then a Scrabble example: the game looks expressive, but to do well you need to use words that never get used in real life and that don’t say annoying you’d want to express. So: scoring can harm expressiveness.

Example from in-progress Tiger Style game: need to grow biomass to progress. But: all lifeforms contribute biomass, not much is needed to progress. So: tell the player “just play the game”, but there’s also depth on demand.

Also, units have multiple functions: can be enemies or allies depending on the context, depending on what you’re trying to accomplish at the time.

Empower the user to generate data; I didn’t quite catch the example here.

Finally, let the user use the generated data. (E.g. players sharing screenshots of avatars / levels.) Achievements also help acknowledge what the player is trying to do. Stats can do that, too: largest web, longest jump, not just a single score. (In particular, these stats in Spider never block your progress, they’re depth on demand.)

3:35pm–4:00pm: “Turning Depression into Inspiration”, by Michael Todd

Indie developers work at a job that can cause stress, overwork, being unhealthy, being poor, being lonely. And there are also potential personal causes of depression. So: some indie devs are depressed! Not always easily solvable, so need techniques for developing while depressed.

Being unproductive and being depressed reinforce each other. Or: if you can be productive, this gives control over our work, our lives. So, ways to increase productivity.

1) Work on rewarding projects

These are good to build. Get to the gameplay, don’t get bogged down. But be careful: don’t front load the fun stuff to the extent that there’s only slog left over. Instead, make as much of the project be reward as possible!

Complete vs. progressive gameplay. Progressive is semi-playable almost at once; a complete game needs almost all the systems before its playable. Lean towards the latter.

Awesome/crazy ideas are more rewarding, easier to keep the faith.

And: design for yourself. Keeps up day to day interest.

2) Try to stop being a perfectionist.

Don’t overthink everything. Get other people to play the game. Skype somebody else to tell them about the flaw you’re worrying about, they tell you you’re worrying too much. Play lots of games (Steam, XBLIG, demos.)

3) Shorter projects

That way you spend more of your building time in the phase where you’re excited about the game. So: small bad is no good, want small awesome!

4) Measure your hours

Otherwise, you’ll work less and less when depressed.

5) Design the game to suit your abilities

What do you love? What do you hate? Use the resources that are available to you. The trick is understanding what you have.

Finally: how does being depressed change how you work?

A game is a thousand tiny choices. These are affected by your mood, your priorities. The distinct choices of a personality can be an advantage; bad experiences can be a particular advantage. (Artists in love are boring, ones that have gotten screwed over in love aren’t.) And depression is an experience.

4:15pm–5:15pm: “From AAA to Indie: Three Start-Up Stories”, by Jake Kazdal, Daniel Cook, and Ichiro Lambe

Another three-speaker talk. First was Jake Kazdal: “From AAA to aaa”. I mostly napped during this.

Next, Daniel Cook: “Spry Fox, Year One: Lessons Learned”

A portfolio approach is key. Great games are not enough: have to hit right platform at right time with right theme. Portfolio model helps reduce that risk.

Flash portals are so used to taking games essentially for free that they don’t understand your asking for money. Very few portals that respect the needs of developers at all. They also don’t understand payment systems, microtransactions. Most important: bring people off of portal back to your website.

Too many designers are like too many cooks. His teams converge on the fun so much faster now that there’s a single creative director for a project.

Teams should aspire to iterate daily. A week is bad; two week iterations and your design may never converge.

Building meaningful hobbies is hard, but worth it. Want people to be playing ten years from now. Tend to be multiplayer, tend to be a service, tend to monetize well, tend to build relationships. But really, really hard to build. And game developers don’t traditionally have those skills, that’s why web developers are doing better in the social game space.

When hiring people, make them do a real project: that lets you see if they can finish. Great teammate: reliable, able to see big picture, works well with others, respects the game designer.

Missing from list: willing to work long hours. (Crunch is wrong.) Passion isn’t enough, and can mean obstinate. And no need for people to be located in North America.

Finally, Ichiro Lambe; I didn’t catch the name of his talk.

Think holistically. Conventional wisdom: wear many hats. True, but the mistake is thinking of things as separate problems, instead weave them together. (E.g. marketing + bug support.)

Tie marketing into design. Conventional view: marketing = getting people to buy crap they don’t want. Instead, create a game that people give hard-earned money for it, and that is remarkable! Make a game that’s both a game you want to make and a game that people want to buy. So: create a game that we’re excited about, and that will sell for stated reasons.

He ended with a bit on postmortems / retrospectives.

At work recently, I was writing some code which wanted to add all the elements of a collection of strings to a document writer. This seemed like a classic case for foreach, so I wrote something like this:

data.foreach(s => writer.addDocument(createDocument s))

(Warning: I’m typing this from memory, without trying it out in the Scala CLI, and I’m new enough to Scala that it’s entirely possible that I’m making silly syntax errors.) That was great, but Scala lets you use underscores in place of explicit argument names for arguments that you’re only going to use once, so I tried doing this instead:

data.foreach(writer.addDocument(createDocument _))

That, however, didn’t work. After looking at the error message and talking to some coworkers, it seemed like Scala was parsing it as the following:

data.foreach(writer.addDocument(s => createDocument s))

And there isn’t a version of addDocument that takes a function argument. Which is good: if there had been, it might have compiled but not done what I wanted, which would have been even more confusing! Still, I was frustrated: why can’t Scala just read my mind? But, honestly, the compiler’s choice was a perfectly reasonable way to parse that expression, and I certainly wouldn’t want Scala’s parsing to be dependent on the types that function calls accept. So I was willing to leave it at that.

Except that, as one of my coworkers then pointed out, there was another way of breaking it down: instead of writing as a single foreach call, I would write it as map plus foreach, as follows:

data.map(createDocument).foreach(writer.addDocument)

Which is much nicer! So, actually, Scala’s parse error was gently nudging me in the correct direction: yes, this sort of thing is potentially ambiguous to parse, but if you break down your function composition properly, then that ambiguity goes away. So it was nice of the compiler to help me write my code elegantly!

The funny thing was, I ran into a very similar situation an hour later: it involved two maps plus a foreach, but the exact same principle applied. That time, though, after writing it out as a chain of three collection functions, I didn’t really like the result: it was going too far into the details of how to use a library that I was integrating with, and I didn’t find the result particularly evocative. So I ended up going back to the single-foreach version, but this time I pulled out the function that I was applying to a member function, so I could give it a name that explained what was going on. It’s nice to have different tools in your toolkit, because ultimately you need to be guided by what makes your code the most expressive rather than falling in love with the most powerful tool.

For all you stalkers out there, here’s my best guess at my GDC 2011 schedule. And clearly I should bring snacks, it’s not at all clear that I’ll be able to eat lunch on Wednesday, Thursday, or Friday… Please say hi if you’re there and run into me!

Monday

• 10:00am: “Creating Your Building Blocks: Modular Component AI Systems”, by Brett Laming, Joel McGinnis, and Alex Champandard.
• 11:15am (half hour): “Ethics for Developers”, by Miguel Sicart.
• 11:45am (half hour): “Game Design by Accidents”, by Steph Thirion.
• 1:45pm: “Click Zen: Zynga’s Evolution from FarmVille to CityVille“, by Mark Skaggs.
• 3:00pm: “Leave Enough Room: Design that Supports Player Expression”, by Randy Smith.
• 4:15pm: “From AAA to Indie: Three Start-Up Stories”, by Jake Kazdal, Daniel Cook, and Ichiro Lambe.

Tuesday

• 10:00am: “City of Wonder: Postmortem”, by Troy Whitlock and Scott Jon Siegel.
• 11:15am: “Humanities Unlocked: The Value of Liberal Arts for Your Game Design Program”, by Mia Consalvo.
• 1:45pm: “We Don’t Need No Stinkin’ Badges: How to Re-invent Reality Without Gamification”, by Jane McGonigal.
• 3:00pm: “Intuition vs Metrics: How Social Game Design Has Evolved”, by Laralyn McWilliams and Brenda Brathwaite.
• 4:15pm: “Rapid-Fire Indies”, by ten speakers.

Wednesday

• 9:00am: “Video Games Turn 25: A Historical Perspective and Vision for the Future”, by Satoru Iwata.
• 10:30am: “Dynamics: The State of the Art”, by Clint Hocking.
• 12:00pm: “GDC Microtalks 2011”, by ten speakers.
• 1:30pm: “Prototype Through Production: Pro Guitar in Rock Band 3“, by Jason Booth and Sylvain Dubrofsky.
• 3:00pm: “Seven Ways a Video Game Can Be Moral”, by Richard Rouse III.
• 4:30pm: “Designing Limbo‘s Puzzles”, by Jeppe Carlsen.

Thursday

• 9:00am: “Classic Game Postmortem – Out of This World/Another World“, by Eric Chahi.
• 10:30am: “Biofeedback in Gameplay: How Valve Measures Physiology to Enhance Gaming Experience”, by Mike Ambinder.
• 12:00pm: “No Freaking Respect! Social Game Developers Rant Back”, by nine speakers.
• 1:30pm (two hours): “Experimental Gameplay Sessions”, by fourteen speakers.
• 4:30pm: “One Falls for Each of Us: The Prototyping of Tragedy”, by Brenda Brathwaite.
• 6:00pm: The game bloggers’ dinner.

Friday

• 9:30am: “The Game Design of Starcraft II: Designing an E-Sport”, by Dustin Browder.
• 11:00am: “HTML5: The New UI Library for Games”, by Chad Austin.
• 12:30pm: “The Game Design Challenge 2011: Bigger than Jesus”, by John Romero, Jason Rohrer, Eric Zimmerman, and Jenova Chen.
• 2:00pm: “An Apology for Roger Ebert”, by Brian Moriarty.
• 3:30pm: “Message Queuing on a Large Scale: IMVU’s Stateful Event Architecture”, by Jon Watte.

Ben’s latest post starts with a lament on the lack of blogging about multiplayer games (which I agree with; I hope Ashelia resurrects Hellmode soon, she had some great posts on multiplayer gaming), and then continues with

(competitive) multiplayer gaming has been hard to talk about unless you are something akin to a top-tier player. But that may only be the case if you are trying to add an explanation of things – anyone should be able to attempt a complete description of a multiplayer game regardless of their skill. The compulsion to explain so exemplarily embodied by the critical essay and its relentless push towards the ‘conclusion’ is a habit from the English department that we perhaps aught to consider jettisoning alongside the Comp. Science faculty’s reliance on ‘concreteness, definitiveness and finitude’, as I put it in Rhetorical Questions.

Latour’s approach, which I am hoping to make my approach, will be to stick to description. Description that will come, mind you, from a very specific and embodied perspective – that is, from my own. In this way we get to hold onto the best of the Sciences reliance on ‘facts’ and ‘objects’ and concrete things while maintaining our commitment to relativism, rhetorical persuasion and… beauty, I think.

(Emphasis and ellipsis in the original.)

Which rather struck me, because I’ve been doing a variant of this on my new blog, and I’ve been surprised at how that’s turned out. I’ve been really enjoying it, at least a few people have been enjoying reading it; but it’s also served as a source of raw material, and while the effects of that have been hidden so far, I hope it will start showing up here fairly soon. I’ve been doing descriptive writing in a matter that’s quite different from what Ben’s describing (in particular, not going into nearly as much detail about the actual games involved), so we may end up going in quite different directions, but right now it seems possible to me that we’re uncovering similar issues in our own ways.

I continue to be surprised by the variety of productive niches that online writing provides. First, I blogged (well, first I wrote static web pages, but never mind that); then I joined twitter. Then Tumblr, and Facebook; I’ve never really gotten into the latter as a publishing platform, but it has its virtues, and the ‘like’ button is a real advance. I also haven’t really gotten into Wave or Buzz, but they also have their virtues, even though I choose not to explore them. And then there’s Formspring, Quora, the list goes on. Not only do all these platforms have their own distinctive strengths, but they’re also all broad enough to support multiple usage styles. (E.g. I use Tumblr as a linkblog, many people use it for personal pictures, many people use it for short paragraphs of personal experience, and then there’s the whole reblogging thing.)

And if descriptive game writing is another one of those niches, great: blogs as research notebooks.

I haven’t started programming Scala in earnest yet, though I’ve been going through some books and typed a bit into the interpreter. (Whee, JVM startup times.) I had the Odersky book recommended to me, but I actually first read the PragProg book: I’ve had good luck with some of their books recently, it’s quite a bit shorter, and there is a tradition of excellent short introductions to programming languages in the field. I won’t exactly say I regret that choice, but the PragProg book isn’t anything special; I’m only 85 pages into the Odersky book, but I’m enjoying it quite a bit more.

A few things that amuse me so far, as a C++ fan:

Yet another book which has to explain that a variable being immutable doesn’t mean that the object it’s pointing to is immutable (just that you can’t reassign the variable to point to something else), and that there’s in fact no way to create immutable objects (assuming that the class allows mutation at all, of course). Is C++ really the only language that has a reasonable story about this?

Admittedly, C++’s story is far from perfect as well: all you have to do is hold a member variable via a pointer and then it’s up to the class implementor to declare const methods honestly, the compiler won’t have your back for you in that case. And that also points at C++’s main advantage in this area, that you can have variables that aren’t held via pointers: maybe without that, automatically enforcing constness is impossible, and without that there’s no benefit in letting class implementers declare which methods are const? I’ll have to think about that one; still, it’s certainly not an area that I would have thought C++ would be relatively unique in when I first ran into the language.

And after reading so many complaints about how you can’t tell what “a + b” means in C++ code, it’s great to see another language that unabashedly embraces operator overloading. And having operators that end in a colon be magically reversed to be methods of the object on their right is simply brilliant: not only does it naturally handle the cons case of

1 :: List(2,3)

but having /: be an alias for foldLeft is just brilliant: I think writing

(0 /: list) { _ + _ }

to sum the elements of list is super natural, much more so than a syntax with 0 and list reversed would be. (Think of it as smooshing down list starting with 0 at the front and with the function argument telling you how to do the smooshing.)

So yeah, Scala and I are going to get along just fine, I think.

Beginnings

As soon as Disney’s acquisition of Playdom closed, e-mails from recruiters started appearing regularly in my inbox. Most of them I essentially ignored: I’d been having a great time at Playdom, and while I didn’t expect to stay there for the six years that I’d stayed in my previous job, I certainly wasn’t planning to leave after just over a year. So I sent polite notes back to the recruiters saying that I wasn’t interested, and promptly forgot about them.

Eventually, though, one of those e-mails snuck through my defenses. It was from a startup that I had vague warm feelings about, enough so that I clicked through to their job ads; and, when I did so, I found that they used both Ruby on Rails and Scala. These are two technologies that I’m quite interested in, and that I wasn’t likely to get to play around with at Playdom; also, at that point I was in a bit of a rut at my current role at Playdom. So I responded to that e-mail in a more positive fashion.

That was the first chink in my armor; a little while after that, I got an e-mail from an industry recruiter whom I’d noticed appearing on my twitter followers list a week or two before. So, out of curiosity (or perhaps vanity), I responded to her as well.

This was the middle of December, so it was close enough to Christmas break that not much happened with those conversations for the rest of the year. But the conversations had planted a seed in my brain, enough to shift my mental story so that, when relatives asked me over Christmas how work was going, my answer was “fine, but I’ve been a little bored recently”.

Changing Stories

In retrospect, that was the key turning point. Before, the dominant stories playing in my head were all strongly in favor of my being at Playdom: the story about being in the games industry, the story about how Playdom was on the right side of an Innovator’s Dilemma market shift, the story of being part of a startup destined for great things, the story of learning new technologies. The first two stories were holding up fine; but Playdom wasn’t a startup anymore (and I was a late enough hire that I didn’t have much of a financial incentive to stick around waiting for options to vest), and there weren’t any technologies on the horizon at Playdom that I was actively excited about, so the third and fourth stories were losing their power. And we hadn’t had meetings within Playdom for a while that were reinforcing those stories or generating new stories to replace them. (Playdom had an all-hands meeting in early February that excited me an a couple of ways; if that had happened in December, maybe I never would have responded to that earlier e-mail.)

This meant that my brain had a narrative gap that it wanted to fill. And, right at that moment, the best new stories were coming from seeds planted by recruiters: maybe I wanted to be at a startup again, maybe I wanted to explore Ruby or functional programming. The very act of talking to recruiters and companies gave this a boost: such conversations inevitably turn fairly soon to the question of what you’re interested in, so unless you want to sabotage your chances immediately, you’ll come up with an answer expressing a story leading away from your current company and towards whomever you’re talking to. Yes, you’re doing that because of your audience; still, telling them those stories has a cumulative effect, and if you spin enough such stories, they’ll combine to lead you in a different direction.

Crafting a New Story

But that travel is more haphazard than I’d like. And potentially dangerous: if other people are driving the conversations and leading the stories, they’re not particularly likely to go in directions that will turn out well for me. So that suggested two courses of action:

1. I should think hard about what I wanted.
2. I should talk to as many people as I could manage, to maximize options and prevent any single external story from having undue influence.

The outcome of the first course of action was:

• I wanted to explore different technologies, Ruby and functional programming languages in particular.
• I wanted to be some place that was into the technical side of agile, that focused more on craftsmanship.
• I wanted to be at a startup again, and a smaller one: I’d tried 50-person and 100+-person startups, I’d tried large companies, and it seemed time to head down to the 25-person range.

None of which I was likely to get at Playdom. Now, I like playing and thinking about games, which meant that I liked being in the games industry; but I like thinking about programming, too, and about everything entailed in the art of creating software. And when it comes down to which of those two I’d most be able to make a rewarding career out of, I don’t think there’s much comparison: I’ll do better (both personally and financially) if I follow my nose as a programmer. So it wasn’t crazy to think that I’d gotten most of what I was going to get technically out of Playdom, and move on.

And the outcome of the second question was that I should cast my net more broadly: in particular, I talked to a couple of recruiters that had helped me land with Playdom originally. One of whom was at a different firm, so now I was talking to three recruiting firms plus a handful of companies that I’d met through other means, mostly LinkedIn e-mails that they’d sent.

Going for a Ride

Let me tell you: those recruiters did not mess around. They all did a very good job, and I’d happily work with all of them again: they’d come up with a first pass of ten or so companies that seemed to them to be plausible fits, I’d look at them and agree that all of them were plausible but pick out a few that particularly caught my eye for some reason, and they’d both set up conversations with those few and use that information to come up with further excellent suggestions.

The upshot of this was that I was spending a lot of time on the phone talking to various companies, and some amount of time (mercifully mostly on evenings or holidays) interviewing in person. (It was quite lucky that it was good weather, because I spent a lot of lunch breaks sitting in a nearby park and talking.) And it was nice to feel wanted!

But also a little disconcerting. I’d like to pretend that I’m so super-awesome that anybody would love to hire me; the truth is, though, that while I’m fairly sure I do have several good attributes, there’s also quite a bit of luck involved. I know several other people whom I have a lot of respect for who have had more protracted job searches recently; I’m not about to chalk that up to some sort of essential difference, it means instead that right now I’m in a situation where people are happy to work with me to spin stories where I sound good. So I need to understand what’s going on there, and see how to best take advantage of it and set myself up in the future.

I wasn’t consciously thinking about this during the job search, but I turned 40 last Tuesday. I’m in an industry that, to some extent, overvalues youth; so far I haven’t had any problems with that, but it’s an example of how future job searches could be a lot more prolonged and a lot less fun than this one was. Which helped confirm my feeling that now was the right time to leave Playdom: from a strictly mercenary point of view, it’s almost certainly going to be the case that I have a significantly higher expected value from playing up the story of “being part of a company that has sold for a good amount recently in a high-profile industry” than from the Disney stock options that I’d be giving up by changing jobs.

Ambition

The upshot of this was that I decided that I needed to change the story that I was telling myself and others still more, and to do so by increasing its ambition. Following the nose of technologies that I’m interested in but not yet fully fluent in remained important (both for personal fulfillment reasons and for setting myself up for further growth), but I didn’t want to go too far in that direction at the expense of underplaying everything that I’ve learned over the last decade.

Also, I ended up prioritizing functional programming languages over Ruby: Ruby’s been around enough that I’m definitely playing catchup there compared to a lot of other programmers, whereas I’m hearing a surprising amount of buzz about Scala while not yet getting the feel that there’s a huge amount of existing expertise in the language. (And I’m quite confident that my brain will do well at turning me into a very good Scala programmer: it’s good at that sort of thing.) I’m pretty optimistic that going in that direction will open up a lot of interesting doors a few years from now, positioning me well on the adoption curve.

In terms of company size, I should go still smaller: coming into a 25-person company would be interesting, but even then you’ve missed a lot of the early decisions. I didn’t quite want to be a co-founder or first hire, but being in the 10-15 person range seemed like it would be a plausible fit.

And then there’s The Innovator’s Dilemma. You can never predict what will turn out to be successful, but I figured there’s no sense not swinging for the fences. Which meant looking for companies that could tell a story involving disruption on a significant scale, and companies whose founders have the chops to pull it off.

This all adds up to a great story going forward: I’ll have worked at multiple successful startups, I’ll have had increasingly important roles within those startups, I’ll have a lot of experience in dealing with very large quantities of data, with cloud technologies, with new programming paradigms (or with half-century old programming paradigms that are making a deserved resurgence!), I’ll have the agile chops to look beyond my day-to-day programming to help the effectiveness of the organization as a whole. That is a story that I can get behind, and it will convert my getting older from a potential liability into a tale of valuable experience.

Outcome

At least that’s how I’d like things to go; then again, I certainly wouldn’t have predicted two years ago anything that has happened since then, so I don’t want to get too tied up in this particular story! I’m very glad to have spent time thinking about it, but in the mean time I need to dive in, start programming, work as hard as I can to help make my next company successful, and see where the future leads.

Which means I needed to pick the next step in my future! I was very fortunate to have the opportunity to talk to some very interesting companies indeed; I ended up joining Sumo Logic, and I’m super-excited about them. They have a great disruption story, their founders can pull it off if anybody can, I interviewed with all nine of the current employees and am very much looking forward to having all of them as colleagues. What they’re doing and the way they’re working fits well enough with my prior experience that I should be able to hit the ground running and contribute well, but there’s enough new that I’ll come out of it knowing quite a bit more than I know going in. It looks like a great fit from my point of view, and they seem to agree; I’m looking forward to spending the next several years with them, it’ll be quite a ride.

And I will pay more attention to the stories that are going through my head in the future: they are powerful, they control me more than I realize.

Last month, it seemed like most of my twitter feed (especially the game developers in it!) was playing Game Dev Story, so I decided to give it a try last week.

And it’s certainly addictive; I spent more time playing it than I’d like to admit, and while I was getting a little bored with the game towards the end of my first run, there were also some goals I hadn’t managed to accomplish, so I ended up launching into a second playthrough immediately. Having said that, I haven’t had any desire to touch the game after the second run, so its addictive qualities seem to be fairly short-lived.

Straightforward enough gameplay, though admittedly well-matched to the iPhone. To me, the most interesting thing about the game was the strategies that it encouraged: the path to success that I found was to find the best people possible to do whatever work needed to be done, and not to worry about how much it cost as long as I could afford them at all. Hear that, game companies: find good people, and pay them lots of money! (Alas, in the real world developers don’t come with stats meters to let you figure out which ones are five or ten times more productive than others…)

Actually, the game seemed to reward spending money in general: if I could afford it, I threw double resources at games when developing them and never regretted it, and spending money on advertising seems to have paid off, too. Once you do that, you’ll have a well-oiled machine where it’s impossible to develop a game that doesn’t do fantastically well, and where you’ll be able to make sequel after sequel for games with no loss in quality. So: not so realistic, and a bit boring. But there were some nail-biting moments in my first playthrough, when I was trying to save up money for a new console license while manufacturers kept on releasing more and more expensive consoles.

I wanted to like the iPhone version of Noby Noby Boy. Not out of any particular fondness for the PS3 version, but because I think Katamari Damacy is one of the most wonderful games of all time.

Sadly, I do not find either variant of Noby Noby Boy to be one of the most wonderful games of all time. I found the PS3 version strangely soothing, but I haven’t felt any pull to return to it. And the iPhone version didn’t manage that: you have a small screen with bad controls to stretch things (though the controls did improve once I discovered tapping to stick things), and with the addition of badly-done music library listening and clock watching modes. Some of the items that you can play with were worth a minute of fiddling; some weren’t.

On to Game Dev Story.

So. Dragon Age: Origins. I’m a pretty big BioWare fan, though more on their action RPG side: Jade Empire was the game where I fell in love with them, and of their two recent games, it’s not due to chance that I played Mass Effect 2 first. But I enjoy their games in general, and I’ve seen more interesting blog posts about Dragon Age than any other game I can think of, so certainly I was going to play it when I had a bit of free time in my gaming schedule. And any game that Kateri thinks so highly of has to be rather good: her liking it doesn’t necessarily mean that I will, but it almost certainly means that I’ll respect it.

Which I do. But I also have no idea what to say about it! So I’ll fall back on my favorite technique of free-associating; and, given the scope of the game, that will be a lot of associating indeed.

RPG Conventions

Let’s start off with the “action RPG” label that I mentioned above. Dragon Age isn’t an action RPG, but a lot of the time its combat plays like one. Which is mostly good: it means that you don’t have to spend more time than necessary on the simple battles. (It’s possible for a turn-based RPG to have similarly fast battles—see Chrono Trigger—but these days the style is for turn-based RPGs to spend too much time animating you into and out of combat.) Though that does raise the question: what is the point of the simple battles, exactly?

For the hard battles, though, the battle system started to fall apart. You really want all of your party members to be working well together; for better or for worse, however, I’d reacted to the action aspect of the battles by only directly controlling my primary character, which meant that I had very little idea of how I wanted to use my other characters’ abilities, and the interface left me with no desire to actively switch between them. (Incidentally, one aspect of the “Leliana’s Song” DLC that I enjoyed was having an excuse to try out playing as a rogue.) Maybe the tactics controls would have left me with sufficient control to pull that off without pulling out my hair, maybe it would have worked better if I’d been playing on a PC instead of an Xbox; as it was, I just fell down to easy.

There were a lot of items to pick up; I bought all the backpacks I could, but on the long dungeons, they still got full, which just increased my annoyance at said long dungeons. There were, potentially, some interesting choices to be made in my choices of items to keep, of armor sets to target; I didn’t feel like thinking about that too hard or looking up the community’s recommended courses of action in that regard, though.

I was expecting to look forward to learning about the history of the world. Thinking back, though, I skimmed most of the encyclopedia material in Mass Effect 2, so perhaps that falls under the category of something that I think I’ll like more than I actually like it. (I do think that building a history for your world makes it richer, but that doesn’t mean that you benefit from making that material available to players.) I can’t say for sure one way or another, though, because Dragon Age combined a huge amount of material with an interface that made it impossible to find bits of lore that you hadn’t read: there’s no way to tell unread lore from previously read lore unless its entry happened to be on the first screen.

Interlude

Which all adds up to a feeling of meh. Is that fair? Maybe I should look at the game through my musicals analogy: embrace the set pieces? I don’t think that analogy is really relevant here: that analogy suggests that I shouldn’t worry too much about the overall narrative structure, but here my feeling is that the set pieces don’t hold together particularly well. (They certainly don’t have the crispness of a good song in a musical).

Failing that, what about the Bohemian Rhapsody analogy? Embrace the overwhelming nature of the game, its ungainly aspects, the ways in which it sails past convention, heedless of the sharp corners that result?

But, of course, Dragon Age doesn’t sail past convention: that’s exactly the problem! In a weird way, though, there’s something here nonetheless: the game was so overwhelming in its adherence to RPG tropes that I ended up ignoring them, ended up going through them and coming out on the good side. If it broke me of the habit of reading through history, of opening chests just because they’re there, of swapping out party members and going through endless conversation trees just to see all of the choices and answers that ensue, and that’s all to the good. I don’t entirely approve of the methods there, but the outcome was curiously pleasing.

Relationships and Story

Speaking of choices and conversation trees: I was a female city elf mage. The most interesting part of my origin story was Jowan: I can’t remember the last tIme I’ve felt so conflicted about a quest in a game. Normally, I jump at a chance to be helpful, but what a drip!

And then Ostagar, and Alistair. Whom I was charmed by immediately, with his self-deprecating humor. Followed by the arrival in short order of Morrigan and Leliana: I really enjoyed being around all three of them, in particular Morrigan’s bickering with the other two; by the time other party members showed up on the scene, I couldn’t imagine swapping out any of those three.

(Side note: Leliana’s entrance, covered in blood spatters, is ridiculous. I read those omnipresent blood splatters as the strongest signal that the game is intentionally going so deep into genre and game conventions as to point out the absurdity and come out on the other side. But the game doesn’t manage to do that wholeheartedly (far too little camp for that to be the case), so it comes out as yet another sign of the game not making up its mind. Which, in its own way, is perhaps the strongest argument for viewing it through a Bohemian Rhapsody lens: the game throws in everything, you make of it what you will, and don’t expect consistency. I just wish there had been more fevered dreams, or indeed any fevered dreams.)

And characters kept on surprising me, and my attitude towards them changed. Sure, Alistair’s revealed as the potential heir to the throne; oddly enough, I reacted to that by mentally withdrawing somewhat. Which ended up making a lot of sense when I reached the part of the game where that really mattered: yes, I could have put Alistair on the throne, but to me the queen fit much better there. (Incidentally, I really appreciated her behavior towards me when I botched one aspect of her rescue.)

And then there’s the approval system. I could have tried to keep everybody’s approval as high as possible; I ended up completely ignoring it when choosing my actions. But I still really liked having the approval system in place: it was an accurate feedback mechanism for how I and the various characters approached the world differently. And it helped me notice that I was much more on the same wavelength with Leliana than with Alistair; I’d been charmed by him initially and assumed that I’d go on to romance him, but I ended up with Leliana, and I think she was a much better fit.

Morrigan generally disagreed with my actions; somehow, though, that never mattered to me, and I found that I really respected her and never questioned her fitting in as a member of my party. So when, towards the end of the game, she made two rather serious requests of me, I did them without thinking twice (or with only a little bit of thought): she was a party member, I had faith enough to go along with what she wanted.

And then there were the fringe party members: I was fond of the dog, certainly, but I never got to know Oghren, Zevran, Sten, Wynne. (Though I did end up disliking Wynne from what little contact I did have with her.) I was a little surprised when Zevran turned on me, but I’d been ignoring him the whole time, so I certainly can’t blame him.

Conclusion?

I have no idea where this all ends up. I’m still ambivalent about RPGs in general, and about a lot of the details of the mechanics of the game. The game seems to some extent aware of those flaws, and I’m not sure if that makes matters better or worse.

But, ultimately, the characters make up for that. Not completely, but enough so that I’m happy to have played through the game. It’s similar to how I feel about Persona 3: too long, too much of a slog in places, but it lets me view relationships between characters that I’ve never seen before in a game. And, in both cases, I wish the game went all-in on what makes it special. But I’m also a little scared of what the results would be of doing that, because I don’t feel I really understand the virtues of RPG slogs.

Time to play some shorter games, I suppose.

If you’ve been wondering at the slow pace of updates here, part of the reason is that a low-key job search suddenly got a lot hotter over the last couple of weeks. Fortunately, it’s over now: I’ll be joining Sumo Logic on February 21st.

More info to come eventually…

I’ve been trying to figure out my reactions to Minecraft recently, and to that end I thought writing down some of my experiences would be useful. Useful to me, that is; quite possibly boring to y’all! So I decided to create another blog for that purpose, and to expand the purpose slightly to include narration of whatever game-related experiences I’m going through.

I don’t expect to put longer-form material there, or even particularly analytical material: I’d like to largely confine it to experience reports. I hope that those experience reports will lead to deeper dives here, however.

It’s at scenes.malvasiabianca.org—have a look. (Or don’t!) There’s not much there yet, but my guess is that what’s there now is representative enough of what its content will look like for the next few months.

(I’ll also use this as an occasion to plug my linkblog, if you’re into that sort of thing.)

I was using one of our laptops on New Year’s Day, and it froze with an odd graphical pattern on the screen. I force-rebooted the computer, but it hung in the middle of the reboot; repeating the attempt showed that this was not a one-time coincidence. Whoops; I have bad luck with computers these days, it seems.

Though, to be honest, it wasn’t much of a shock: the computer was one of the original Macbook Pros, which meant that it was almost five years old, quite long in laptop years. So I’d been thinking about replacement plans for a while; in fact, disk space concerns might have forced my hand on that over the next few months anyways. (And kudos to Snow Leopard for reducing disk usage enough to not have forced my hand a year ago!) I talked it over with Liesl and Miranda, and we decided that my tentative plan of replacing it with a desktop machine plus a second iPad made sense, and that it also made sense to hold off on purchasing the second iPad for a few months, until the next model is released. (We have a Macbook around the house, too, so we’re not exactly lacking in options in the interim.)

So, the next day, I went to the Apple store and got a replacement (a base model 27″ iMac, specifically), along with the new Apple trackpad, an external drive for backup purposes, and a copy of iWork that was on sale. (Though, in retrospect, not on sale enough, given the appearance of those programs on Apple’s Mac app store the next week…) And, fortunately, for the second time this year, my backup strategy proved to be up to the task: when I turned on the new computer, it asked me if I wanted to restore from a Time Machine backup, I did so, and all our files and applications were back.

Though, as it turned out, not all of those restored applications worked. Almost all of the problematic ones didn’t work for the same reason, namely DRM. Some of that was straightforward but annoying (I had to re-enter license keys for a bunch of Popcap games), but I ran into real bugs with Spore and with iTunes’s ability to play Audible files that took some amount of googling to figure out. (The Spore problems were particularly special; the joys of PC gaming…) Also, on a non-DRM front, I ended up deleting and reinstalling Macports after some problems there (which, admittedly, may have been partially my fault); not my favorite piece of software, that.

Still, all in all, I’m quite happy: I’ve had two computers die on me this year, and in both cases I had a quite functional replacement working the next day. I still don’t feel entirely comfortable with my Mac backup strategy—Time Machine is magic enough that it seems to me that there’s more scope for bugs than I’d like, and the backups there are physically colocated—but it’s definitely passed the test so far. And the new computer is really nice (and Miranda seems quite fond of it indeed, it turns out that she really likes 27″ screens), and I’m quite happy with Apple’s trackpad as well.

I’m tentatively planning to install Windows on it as well at some point: I can’t imagine playing major new Windows releases, but it would be convenient for indie games or for Vintage Game Club stuff. No urgent plans along that front; I’m tentatively thinking a Boot Camp install plus Parallels, but I might go pure Parallels, or change my mind entirely.

So: Osmos. It’s a lot like Art Style: Orbient, no? In the mechanism of circles absorbing other circles until they become the largest circle, in the simplicity of the controls, in the puzzle nature, in the simplicity of the presentation, in the amount of content that’s perfectly reasonable for a five-dollar game. I like Osmos‘s aesthetics a little more (some of its forms of circles are quite lovely), and actually as far as gameplay goes, some of my least favorite bits are where it uses the orbiting mechanic that’s central to Orbient. (Hmm, I wonder why that is? Maybe because it’s the situation where Osmos‘s control scheme starts to become a bit obtuse, turning into an indirect version of Orbient‘s control scheme.) I like Osmos‘s pacing more, too: the directed version of the levels ran out just as I was getting frustrated, and it’s backed up by a solid procedurally generated arcade mode.

A pleasant way to spend a couple of hours when I was home sick; who knows, maybe I’ll dip into it more in the future, maybe not. I’m certainly glad that games of this weight exist, I should play them more.

Rock Band 3‘s signature song is Bohemian Rhapsody; and, as a video game, that song is a very odd experience indeed. Unless you’re singing, you spend large portions of the song waiting for your next chance to play; whether or not you’re singing, the style and difficulty vary wildly from section to section.

This is a huge change of pace from most games I’ve played recently. Yes, video games frequently involve standing around, in the form of cut scenes: but those are short compared to the action sections and are in a different mode, whereas the gaps in Bohemian Rhapsody are fairly long and are of a piece with the rest—indeed, you would be playing during them if you’d chosen a different instrument. And, while games move you from region to region, they do that on level boundaries: you’ll typically spend an hour or more in a given context and, outside of platformers, different levels in a single game typically have quite a bit more in common than the different sections of Bohemian Rhapsody. And Bohemian Rhapsody’s difficulty curve spiky graph would be completely out of place in any game that I can think of.

The thing is, none of this matters! Or rather, it matters, but in a good way, in that these comparisons completely miss the point of the virtues of playing the song. The song has a (quite!) distinctive vision, and the goal of playing through one of the instruments in the song isn’t to go through a checklist of what makes a game-playing experience pleasant (or, for that matter, what makes a musical experience pleasant), it’s to experience a portion of that vision.

I don’t want to throw away traditional guidelines for what makes a video game experience enjoyable, what makes a video game well crafted: I enjoy the sort of refined experience that is produced by years of thoughtful evolution as much as the next person, and I would find it exhausting if all games were as idiosyncratic as Bohemian Rhapsody. Having said that, the game that I played in 2010 that is rattling around in my brain the most is Killer 7, and for much the same reasons: it presents an experience that is quite different from anything else I’ve ever played, and that experience is a powerful one that I still don’t know how to make sense of. If you’d asked me what sort of characteristics an enjoyable action game would have, being on rails would be very low on my list; but that sort of checklist comparison is completely overwhelmed by the vision that illuminates Killer 7, and I’m more than happy to place myself in the light of that vision and see where it leads me.

By all means, refine your craft, and don’t put barriers in your users’ way out of carelessness. But listen to what emerges during the night, and if those visions lead you somewhere unusual, embrace them.

And now I’ve come to the end of Matthew. (Phew!) Many thanks to those of you who have read this far and commented, especially to Roger for his many insights. (And I apologize if I mischaracterize his point of view below.)

I came in expecting to dislike a lot of what I read, and I wasn’t disappointed in that. God is presented as a figure of petty evil; Jesus is working in support of that. Or at least, that’s how I initially read it; as Roger pointed out, prophecy isn’t necessary inherently moral, it can be simply descriptive, and warnings of evil are useful.

But, as I read further, I felt less and less that those statements were directed at me. Roger’s comments helped me see this more as an exercise of community forming within an existing Jewish community; most of Jesus’s strongest attacks are directed at the existing Jewish priestly elite, he explicitly abstains from opportunities to attack the secular government of the time, and he probably doesn’t care at all about an atheist on another continent two millennia later! The prophecies about the arrival of the kingdom of heaven within a generation also helped me root these statements as concerning a battle involving specific people in a specific time and place.

I was surprised by my reaction to Jesus’s healing: I expected to like that uncritically, but the repetition eventually got to me. That probably says more about me (and not in a particularly good light!) than about anything in the text, however.

And I was also expecting to find a lot to like, and I wasn’t disappointed in that, either. So many strong statements about forgiveness, my favorite of which was the passage about turning the other cheek. Linked to that are statements about not judging others but instead judging yourself (the mote in thy brother’s eyes), and statements about caring for others, and of faith in the generosity of humanity; great stuff on page after page.

I’m glad to have gone through this exercise; but it’s also been a lot more work than I expected! I’m still planning to read through the rest of the gospels, but I’m certainly not planning to do many posts on them; if something catches my eye, I’ll write about it, otherwise not. Again, my thanks to those of you who have stuck with me; to those of you who think this topic has more than overstayed its welcome, I reassure you that I’ll soon be back to my normal program of video game pontification combined with occasional bits on software development…