GDC Report – Tuesday

Learn Better Game Writing In a Day

Tuesday was mostly spent at an all-day workshop on game writing by Evan Skolnick. Overall, it was really interesting – a lot of stuff I’ve heard of (the Hero’s Journey and such) but it was good to go into depth on it, and use game examples to do so. Here are my notes.

First, join the IGDA Game Writing SIG.

Journalism is good to study when it comes to game writing. Make your writing short and succinct, and cover the most important points first. Ensure that even if the player only reads the ‘headline,’ they get the information they need to finish the game.

Writing for games can be a unique challenge. Movies and novels need stories – they’re nothing without their conflicts and plotlines. However, a game resists story – the core of a game is in its mechanics and interactivity, which are mostly story-free. The writer needs to hang on and craft that story that makes the game better, while remembering that gameplay is king – and in a question of story or gameplay, gameplay always wins!

What is a story? A story is conflict. Characters experience conflicts. Over the course of its progress, a story has many conflicts that escalate. Gameplay relies on conflict too!

Three-act structure is one of those things that’s really basic and simple when you see it written out. Stories have a beginning, a series of rising conflicts, and a conclusion. Try going back to your favorite movies and identifying the act changes. What is the moment where the introduction ends, and the adventure begins?

Havok AI

During lunch, I took a break to go to a panel on Havok AI. It seems quite adept, quickly marking out walkable areas and finding paths across them. Also stuff like handling characters marching in formation, and avoiding moving objects as they go. As a designer, I worry about turning over control of my characters and gameplay to a middleware solution, but Havok’s got a pretty good reputation.

Back to the Writing Workshop

We spent a lot of time on the idea of the Hero’s Journey and the Monomyth, both of which express the same concept: that nearly all stories have a very similar structure. Beyond the ‘beginning, middle, end’ of the three-act structure, there’s a lot of individual characters and plot details that all stories share.

For example, the monomyth presents the ‘herald’ as an archetype: a character (or event, I suppose) that announces the conflict in fairly explicit terms, and gives the hero the opportunity to take up the quest. It’s M in James Bond, R2-D2 (or rather, Leia) in Star Wars, or Trinity in the Matrix.

There are plot similarities, too, such as ‘An ordinary world, the hero gets a call to adventure, they deny the call, meet a mentor, then cross a threshhold and end up squarely in the middle of adventure.’ Luke lives on Tatooine, meets R2-D2 and Obi-Wan, refuses to join the rebellion, finds his foster parents dead, gets advice from Obi-Wan, and goes with him to Mos Eisley.

In regards to games, an interesting takeaway is that the introduction to the story is usually very shortened. We don’t want to play through a half-hour of the hero denying their call to adventure, we want to kick some ass! Often, the introduction of the ordinary world, the threshold, and the beginning of the adventure are covered within the first minute of the opening cutscene. The first part of the Hero’s Journey might not be in the game at all; especially in older games, the conflict might be expressed on the back of the box, in the manual, or in the marketing.

After this, we moved on to Dramatica, which is both a theory and a writing software. I should check out the software shortly.

The theory is that stories are models of a decision-making process. You take some initial ideas, try them out in different situations to see what works and what doesn’t (different trials and events of the story) until finally coming to a conclusion where you understand what the hero needs to do to overcome the villain. Essentially, the author is making an argument that their idea of how to solve the problem is the best one, and they show why other options wouldn’t work.

Characters trying to resolve a conflict (make a decision) are often limited by two factors: timelock (not enough time to make or execute the decision) or optionlock (can’t, must, won’t – constraints that limit their possible choices).

After Dramatica, we covered some basic writing guidelines, in the areas of exposition, believability, and impact.

Exposition

Show, don’t tell. This is a common piece of advice. Don’t say the villain is coldhearted – show them casually murdering people. Don’t say the sidekick is lazy, show them missing their alarm and skipping work. Don’t say this gun is powerful – give the player a chance to blow a bus in half with it.

Seeding is the concept that you put exposition throughout the story, giving just enough information to keep the viewer’s interest, and giving them new exposition when they’re ready to process it. The example we used was The Terminator. The basic premise is pretty heavy: An unstoppable murderous cyborg has traveled back in time to 1984 to kill Sarah Connor, the mother of the man who will lead humankind’s resistance against the machines that rule the world in 2029.

The movie takes about 45 minutes to actually express all of that premise. We first learn that he’s murderous, then that he’s interested in Sarah Connor, then that he wants to kill Sarah Connor, then that he’s unstoppable. We don’t actually get the infodump of “he’s here to kill your future child” until about 45 minutes in.

Planting, as opposed to seeding, is taking one story element and placing it into the story for a particular reason. A common example is Chekhov’s Gun: if you mention a shotgun above the fireplace in Act 1, it needs to have been fired by Act 3. Planting places something specific into the story, makes sure the audience remembers it, then gives them time to forget it – so that when it comes up again, they’re surprised by it, not not disbelieving.

Foreshadowing is like planting, but with a softer focus. Rather than pointing out one element that will be important later, you’re just hinting at what’s to come ahead. It’s often presented just as a vague warning or idea, the importance of which only becomes clear much later.

Believability

The audience wants a world that’s easy to get into. It can live by fantastic rules, but those rules should be consistent.

Don’t allow too many coincidences to creep in: those erode your believability, when things just happen to occur at the right time, or the characters just happen to stumble across a critical piece of information. Can you suggest a reason why these coincidences happen?

Small flubs in believability are way-homers: the audience only thinks about the problem on their way home. If you can get them to swallow it for that long, you’re probably okay. The real problem is the huge coincidences that make the audience roll their eyes and think “that’s absurd.” Then you’re losing them.

You get one ‘gimme’ – a big lie that sets up the story. Something like ‘being bitten by a radioactive spider gives you superpowers.’ More than one or two of these, though, and the audience starts to groan.

The rules of the world should be consistent. An example was Who Framed Roger Rabbit? The human world and the toon world operate according to completely different rules, but within each world, the rules are consistent.

Character personalities and motivations should be consistent, too.

Impact

Not every story need to be an epic adventure about saving the world. Setting the right scale can make the story come alive. Think of romantic comedies – the only thing at stake is often someone’s relationship, or a little social embarrassment. Or the PS2 game Mr. Mosquito, where the only goal was keeping a single mosquito alive.

The best stories surprise their audience often. Try to throw in those little moments of interest and delight. Surprise your audience, but keep it believable.

Android Vampires and Pirates

Lured by the potential of free Google swag, I skipped the last part of the writing workshop to go to a presentation on security for Android. I didn’t get any cool stuff, but I did learn a bit about security.

Point one: code obfuscation. Write your code so that it can’t be easily decompiled by automated programs. Often, just by poking around, crafty individuals can find the bit that says “Registered = False” and change it to “Registered = True.” So don’t make your code that simple (at least not your authentication code).

Point two: host content online. It’s harder to spoof the registration when the game needs to communicate with an external server. Google naturally suggested Google App Engine, and offered some suggestions on how to prevent vampires from using up your bandwidth.

(Pirates, you see, just steal your game. But vampires steal the game AND suck up your bandwidth, so you’re actually paying for them!)

IGDA Party

Tuesday evening, I went to a mixer/party for the IGDA. It was all right – I met some people – but the layout of Ten Fifteen is kind of hilarious.

There’s an area at the entrance with a bar. Everyone was milling around there. To the back of the room are some signs and hallways for the bathrooms.

However, if you go past the signs and down the hallway, there’s an entirely separate back room, twice as large – and that’s where all the food was! I was constantly telling people about this, and they’d look over at the bathrooms and be like “There’s another room back there?”

Even more mysterious, there was a staircase in the back marked ‘coat check’. However, upon going downstairs, I found another large room, this one with numerous booths and tables, and tons of board games laid out! I had a nice game of Incan Gold, a drink, and headed home.

(Incan Gold: Fun premise, delve into a temple to recover treasure. The gameplay mixes a bit of ‘push your luck’ with a bit of ‘bluff your friends.’ It felt good, but I’m not sure it filled a role for me that isn’t already filled by Pass the Pigs or No Thanks!)

Human Speech for Computers

After working with code a bit, I’m really looking forward to computers that can interpret language. Not artificial intelligence, per se. You see, I spent about an hour last night debugging a simple game I made. One of the sticking issues was that a UI button turned inactive when you beat the game, but remained active if you cheated and flipped the ‘you win!’ variable.

I needed to call a statement…GUI.enabled = true, or something like that. A computer could have found it instantly, if I could just communicate with it naturally. “Why is this button turning grey?” “The GUI is set to disabled.” “What’s the difference with this button, that’s active?” “The script doesn’t run this section of code that enables the GUI.” “What do I need to change?” “Put this line of code here.” It’s not particularly difficult language, which is why I’m hoping we can achieve it in the next decade or so.

The ultimate goal is to have a computer that can work as fast as I can think. Our primary limitation is just translating human thought to machine thought. If every idea could be executed perfectly…well, things would begin to be judged by the quality of their concepts, rather than the quality of their execution.

I was reminded of this when making an event in Google Calendar. I typed “Catch the 6:04 train.” Google changed it to “Catch the train” and set the start time to 6:04. In a very limited context – making calendar events – computers can understand human language and structure. We just need more of that.