gamedesignerben

I could only find abridged versions, or blurry photos of the original handouts, so I transcribed everything, and here it is.

This is an analysis of Firewatch's form. While specific details of the main story won't be mentioned, I will be talking about the beginning and ending of the game. So: spoiler warning.

Campo Santo's game Firewatch has been out for a couple of weeks now, and seems to be performing well enough to ensure that it will be "part of the conversation," one of those games that takes enough chances and glows with enough wattage to ensure games coming out in its wake will be seen as referencing it. Developers interested in building on ideas in Firewatch may be looking for other games, perhaps less well known, that attempt similar things. They should look at Nordic Larp.

If you're unfamiliar with Nordic Larp, it's a form of live-action roleplaying that was developed in the Nordic countries of Europe. Instead of medieval battles or superpowered vampire adventures, stories are character-focused and often more grounded in the real world (although notable exceptions exist). The players are like actors, cast into the roles of people with their own opinions and goals that may not be shared by the players who bring them to life. An individual larp can last anywhere from a few hours to a few days, or in rare cases, weeks.

The basic structure of a Nordic Larp is: workshop, larp, debrief. I'm going to talk about each of these phases in turn, and how I think Firewatch fits them. I'm also going to talk about a few other concepts that inform larp design: Bleed, and Playing To Lose, and how they are incorporated by Firewatch, or might be incorporated by similar games in the future.

Workshops

A larp workshop is a pre-game activity that serves a couple of purposes. It acts as an icebreaker to bring a group of people together in a shared activity and defuse the fear of looking stupid in front of each other. It is an opportunity for the facilitators to teach any special techniques required to play the game. Finally, it's a chance for condensed character development, where players can establish back story and introduce themselves to each other so that when the story-proper begins time doesn't need to be spent establishing characters and relationships.

Firewatch notably opens with a sequence where choose-your-own-adventure style text is intercut with short playable sequences within the game's standard 3D first person engine. The text portions will feel immediately familiar to anyone with experience of Twine, an interactive story engine that has become associated with character- and narrative-heavy games, and usually have a voice that is much more mature than commercial games allow.

In the text sections, the player quickly figures out that they are establishing the backstory of Henry, Firewatch's main character, and the events that lead to him taking a job sitting in a tower alone in the woods. In standard commercial games, these sequences usually give the player choices between a couple of different personalities or points of view: kind or cruel, brave or cowardly, violet or reserved, etc. Not so here. When you play the sequence where Henry meets his eventual wife, you are drunk, and none of your choices of flirty introductions make you come across as suave or intelligent. When the game then informs you, "One week later she is your girlfriend," it doesn't feel like an accomplishment, it feels like maybe this woman is not terribly picky. While not every choice the player is given makes Henry come across as a total sad-sack, the player is never allowed to define the kind of person Henry is; the choices are of degree, not kind. In effect, the game developers are guiding the player through the experience of being Henry, helping the player get into character.

The 3D sections are more familiar to videogame players, and acclimate the player to the basic movement controls: looking around, walking, picking things up, and using things.

So ignoring the group icebreaker portions of larp workshops, we see that Firewatch's opening sequence teaches the basic mechanics, and also takes the character through a condensed character establishment sequence so that when the action of Day 1 begins, we already know Henry's secrets and can focus on the plot and on the evolving, present relationship with Delilah.

Larp

The main play phase of a larp maps cleanly onto Firewatch. Henry and Delilah evolve as characters and the relationship between them develops similarly. A plot unspools over the course of several scenes. Given that modern adventure games and Nordic Larp can trace roots back to 70's D&D and all of the human storytelling tradition, it's not surprising that there's so much overlap here.

Debrief

If Firewatch has a debrief in the Nordic Larp sense, it is the final radio conversation with Delilah. In larp, debriefs accomplish a couple of goals. They allow the player to validate their experience of the game with the other players. They begin the process of turning the experience and emotions of the larp into lasting memories, reflections and learning. Finally, they let players voice any difficulties they experienced so that they can be addressed, and reinforce a culture of mutual trust within the larp community.

In Firewatch, Delilah guides the player through a final conversation where they try to figure out what just happened. The mid-game in Firewatch takes a left turn into techno-thriller territory (with possible supernatural elements) that is ultimately revealed to be an elaborate hoax. Henry, without player input, summarizes what the player witnessed, and Delilah confirms it. Then the subject changes to the future of Delilah, Henry, and their relationship. The player gets to propose the ending they'd like to imagine for Delilah (whether or not it would "really happen"), and Delilah tells Henry what she thinks should happen to him. By summarizing the player's story, and letting the player propose an epilogue, Firewatch validates the player's experience and starts to package it into some sort of takeaway.

The missing component of a larp debrief here is the discussion of difficulties. But of course, this happens anyway. Early players and critics went online to voice criticisms about the length of the game, the lack of open world exploration, whether the ending worked, and so on. Could Firewatch have given the player agency through Henry's voice to tell Delilah about these issues? Would it have reduced negative coversations about the game online if players had been able to express those feelings in the game itself? Right now, there is no way to know. However, if Firewatch is a larp, or at least larp-like, the decades of development within that form suggest that some amount of formalized airing of grievances improves the overall reception of games of this type.

Bleed

The idea of the player using Henry as an avatar to express their own thoughts and feelings is known by larp makers as Bleed. There are two kinds of Bleed, Bleed-In and Bleed-Out. Bleed-In is when the real life out-of-character experiences and emotions of the player override the motivations of the character being played. Bleed-Out is, like you'd expect, when an in-character experience or feeling influences the player back in their real life, usually after the game is over. Here, I'm mainly interested in Bleed-In, so when I talk about Bleed, that's what I mean.

In most videogames, especially first person games, it's assumed that the character is mostly an empty avatar. The character's motivations don't matter, everything they do is at the whim of the player. Videogame designers assume All Bleed All The Time. This is why no one bats an eye when the player learns about an imminent, existential threat, and promptly wanders off to rescue lost cats and loot random dungeons before getting around to dealing with the end of the world some 60 hours later.

In Firewatch, the player is always stuck in the voice of Henry. Henry is kind of a dick, but he has a sweet spot, and mostly he just wants to avoid conflict. In the low-stakes world of Firewatch there's not much opportunity to push outside of those parameters. Even moments in the game that could lead to Henry growing are undercut: crimes are never properly investigated, conspiracies are imaginary, you can't even do anything about the fires that are your whole reason for being there. But that powerlessness enables the player to have Henry break character during moments of perceived crisis. When you learn about a crime, you can make Henry advocate reporting it, or covering it up. You can worry about the fire, or assume it's all under control. As the player, you can pilot Henry's inner journey, which it turns out is the only thing actually under Henry's control.

Playing To Lose

This brings me to the last larp concept I want to talk about in respect to Firewatch: Playing To Lose. This phrase is used to express the idea that a character-focused game where all the characters are acting as their best selves does not make for a very good story. Instead, players are encouraged to get into character and make choices that create narrative grist, rather than compromise in hopes of getting a "partial victory" for their character. Neither Henry nor Delilah are their best selves. Both run from responsibility, drink too much, are petty, and somewhat ashamed of themselves. While the game doesn't explicitly reward the player for leaning in to Henry's faults or compare the player's choices to some sort of data curve that describes a developer-approved character arc, it puts Henry in a position similar to Scrooge in A Christmas Carol, where he sees the world progress as if run by the sort of person he was when he first arrived in Wyoming. Even in the event that the player Bleeds In and makes Henry advocate for taking responsibility, Delilah is there to secretly undercut those choices. By never acting as her best self, Delilah keeps the story tumbling forward.

In the first of what will hopefully end up being a series of larp-related developments, I’m proud to announce LightLeft, a flashlight prop for larps and other live-action games, is now available for free on Android and iOS.

LightLeft is the result of a collaboration between myself and Eric Mersmann. It’s a simple tool for using light as a limited resource in all kinds of live-action games. Prior to this you had to... I guess give people a flashlight, a stopwatch and a shrug?

WELL THOSE DARK DAYS ARE OVER, THANKS TO... TECHNOLOGY!

(“Dark” days. Ha. Did you see what I– You did? Moving on.)

If you want to run a game that uses LightLeft, you set the total amount of light available, configure how that information is shown to the player, and whether the light is steady and reliable or not. Then you hand the device to your player and go. That’s it!

Did I mention that it’s free?

Google Play Store: https://play.google.com/store/apps/details?id=com.DozenEyes.LightLeft

iOS: https://github.com/GameDesignerBen/LightLeft-iOS

iOS is more complicated, because Apple does not allow new apps that serve primarily as flashlights to be added to the App Store. But it’s now possible to install development code on devices running iOS 8 and higher without purchasing an Apple Developer account, so we’ve shared an Xcode project on github. Just follow the setup instructions (short version: download a few things and click some buttons) and go. The installation stays valid for 365 days before you have to press the button again. Plus, maybe you’ll decide you can add “App Developer” to your resume? I don’t know your life!

The only difference between versions is that iOS gives you the option to dim the light output as the “battery” runs down, which is not widely supported on Android.

One of the most fun projects I had the opportunity to work on this year was a recreation of the 1958 videogame Tennis For Two, which is fully playable and installed in the New York Historical Society as part of their “Silicon City” exhibition. Since the exhibit opened to the public two weeks ago (the first time Tennis For Two has been publicly playable for longer than a few hours!), I’ve gotten a lot of questions about Tennis For Two and how the project came together.

In early 2015, Jeanne Angel, Media Producer for Exhibits & Special Projects at the New York Historical Society, got in touch with my game studio, Dozen Eyes, about Silicon City, a planned exhibition about the early history of computers in New York City and the surrounding area. We ended up making several interactives for Silicon City (one of them, a projection housed in a giant geodesic dome featuring mid-century collaborations between New York performance artists and computer scientists is a must-see for anyone interested in modern “new media” venues like Babycastles or Eyebeam), but the most exciting piece was a recreation of 1958′s Tennis For Two.

William Higinbotham built Tennis For Two for Brookhaven National Laboratory’s 1958 Visitor’s Day. Higinbotham wanted to showcase the latest developments in computing. One of the lab’s analog computers was able to compute trajectories for ballistic missiles. Using this as a foundation, Higinbotham drew up the program diagram for Tennis For Two in a couple of hours, and spent two or three weeks building and debugging with Robert V. Dvorak (even in 1958 videogames were associated with their designer, and not their programmer). While much of the game’s state is controlled by resistors, capacitors and relays, the real-time simulation of the ball, as rendered by an oscilloscope, required blazing-fast 2N140 Germanium-alloy transistors (developed by RCA in 1957). If Tennis For Two is not the very first videogame, it is almost certainly the first videogame intended to showcase bleeding edge graphics technology.

Hundreds of people lined up to play Tennis For Two on Visitor’s Day in 1958. So many that Brookhaven showed it again in 1959. After that the machine was apparently cannibalized for parts.

In May, Jeanne arranged a trip out to Brookhaven National Laboratory. BNL consists of rolling grassy fields punctuated by buildings in wildly differing architectural styles (it remains a popular shooting location for period tv shows), and it is the sort of place where the nice man in the polo shirt that you met on the way to lunch is actually one of the top physics minds on Earth. Despite all the cutting edge research and technology at BNL, it still feels like something out of a different era, or an alternate universe. The cafeteria feels less like Google than a small liberal-arts college. Nobody looks like a 20-something brogrammer. Few people look under 30. Everybody has a government job and a pension. All the people I talked to had worked there for at least 20 years. Perhaps there’s some egalitarianism left in tech after all.

At Brookhaven, we met with Peter Takacs, a physicist who as part of the lab’s 50th anniversary celebration in 1997 helped rebuild Tennis for Two from Higinbotham’s original schematics using vintage parts (vacuum tube-powered Donner analog computer, and all). Peter took us to a small storage room deep in the bowels of a literal Cold War bunker where the game was kept, and after playing with a few connections, managed to get it up and running for us to play.

The actual machine is a pretty amazing thing, with relays that make a loud physical CLACK every time a button is pressed, updating the game’s state. There’s a subtle electrical hum in the air, joined about 30 minutes later by a faint burning smell. A 2010 attempt at installing Peter’s build in the Museum of the Moving Image showed that, unfortunately, it was far too fragile to be publicly playable for more than a couple of hours.

(Relatedly, Peter mentioned an anecdote I hadn’t heard before, which is that on Visitor’s Day in 1958, Tennis for Two was so popular that components burned out while it was running, and electrical engineers had to stand by to quickly swap in fresh components in order to meet the demands of the public. This aspect of the 1958 machine is not replicated at NYHS, which was made with Unity and runs on a Mac mini with a 4k monitor at full resolution)

If you look up Tennis For Two online, you’ll quickly learn that Higinbotham’s schematics contain a couple of errors. We know that Higinbotham and Dvorak must have found and corrected these bugs, but they never bothered to write down what their fixes were. It’s a reminder that videogames have always had a difficult relationship with conservation. Recreating the actual plans would result in nothing, so we have to improvise our own solutions in order to recreate what we know about the experience as best we can.

Tennis For Two has two controllers (ours were made by Adelle Lin and are powered by Arduinos), consisting of a dial for setting the angle of a hit, and “Hit” button. A separate button resets the ball to the service position of the last player to score.

Not that the game keeps score.

Having watched people play Tennis For Two, I’ve noticed two phases that players seem to go through. First, players used to modern videogames are surprised at how Tennis For Two subverts their expectations. For one thing, the game has no notion of score, or how long a match should be. The effect of this calls to mind modern mobile games like Super Hexagon or Downwell, where as soon as the immediate game ends, the player is only one button push away from an instant rematch. Players will zone out for 15-20 minutes going back and forth, perhaps only stopping when somebody taps them on the shoulder.

Most players also quickly figure out that any time you press the Hit button, you hit the ball. It’s impossible to miss, and the ball’s speed is slow enough that you nearly always have time to react. This causes many players to ask if Tennis For Two is “even a game,” since we’re used to thinking of tennis videogames as being like Pong, where the whole point is to “AVOID MISSING BALL FOR HIGH SCORE”, but then a funny thing happens: somebody spikes the ball downward.

One of the few rules Tennis For Two enforces is that you can only hit the ball one time after it enters your half of the court. This means that a hit that fails to put the ball over the net will lose you the point, and the easiest way to force your opponent to do this is to get them to hit the net by volleying the ball back and forth, and then spiking it downward before they can adjust. Spikes can be defended against by waiting for the ball to bounce back up, but the timing of that wait can be subverted by a strong horizontal slam, which is itself vulnerable to a spike.

Players who figure this out discover that Tennis For Two is actually a reflex bluffing game, similar to Street Fighter II, where competitive play is about building momentum and forcing your opponent to make an error you can exploit. As a game developer, it’s fun to watch players pick up the controllers and twist their mouths as they wonder whether this “game” is just some glorified mid-century tech demo, only to see their faces light up when they discover the real game hidden behind the word “tennis.”

That photo is from a playtest I ran at NYU Game Center a few weeks before it was installed. The man on the right is Masayuki Uemura, who ran Nintendo’s R&D department during the development of the Famicom and the NES, who happened to be there to give a talk later that evening. From across the room, he immediately recognized Tennis For Two, and came over to play it.

After about 5 minutes he looked at me and said, “Quite simple, isn’t it?”

You can see Tennis For Two, and a lot of other cool parts of New York history at the New York Historical Society as part of “Silicon City: Computer History Made in New York” through April 16, 2016. For best results, bring a friend to play against! If you’ve got a fun project and you like what you’ve seen here, get in touch: ben at dozeneyes dot com.

Five years after reimagining the arcade as a venue for independent games, Babycastles is taking on a new challenge: reinventing the licensed movie game. We'll be teaming up with distributor Oscilloscope Laboratories to make a game based on their upcoming film, Buzzard.

The dominance of licensed film games, spanning a decade from the late 90's to the late 00's, saw video games shift from all-ages mascot games, like Mario, Sonic or Bubsy the Bobcat, to mass-market entertainment aimed at older audiences, such as James Bond, The Lord of the Rings, or The Chronicles of Riddick. This was the era that gave birth to the "games make more money than movies" claim, the ESRB and PEGI with their content warnings and rating systems, and the beginnings of a wider acceptance that videogames could be "art" for "grown-ups." Licensed film games also financed the massive profits of the companies that would become the large third-party AAA publishers that dominated the industry by the mid 00's.

It was not to last, however. Film studios saw how much money games were making and started charging more for film licenses, and then the mobile market exploded and AAA studios were left clinging for dear life by duplicating only the most successful gameplay models. The age of the licensed film game was over...

... until now!

At Babycastles, we focus on encouraging collaborations between game developers and artists from other mediums. A collaboration between indie filmmakers and indie gamedevs feels natural. And just as we discovered that bringing a D.I.Y. spirit to an arcade brings out the best features of both, we're looking forward to seeing what can happen when we bring that same D.I.Y. spirit to this mostly abandoned creative partnership.

My parents took me to see Groundhog Day while it was in theaters, and at the time I didn't think much of it. This is to say that too cool for elementary school Ben Johnson thought it was kind of a dumb movie about a guy who can't die or something. So imagine my surprise when years later it kept coming up as an example of Great Comedy.

Older, wiser Ben Johnson regrets the error. It's a good movie. But even I came away with a deeper understanding of just how well the gears in that movie turn by listening to the Scriptnotes Podcast discussion of Groundhog Day.

The PixelTron is a project Liz and I created for the 2012 Northern Spark outdoor lighting festival in Minneapolis. Originally called the PixelTron150, it is a 15 x 10 grid of pixels, each measuring 6" on a side, leading to an overall screen size of 7.5' x 5' x 8", housed in a custom-built arcade cabinet that stood 8' tall and 8' wide, with a total depth of about 4'.

Each pixel is lit from behind by a single color-changing LED, similar to the kind used for the lights on the Bay Bridge connecting San Francisco and Oakland.

The PixelTron accepts an arbitrary video signal and can be used to show absolutely any image, game, or video imaginable. However I created a custom game for the festival, a 3-player racing game called Low-Rez Racer that was designed specifically for a resolution of 15 pixels by 10 pixels.

I've been playing a couple of games that have gotten me thinking about maximalism in video game design recently, Blizzard's Hearthstone beta, which is a collectable card game, and the iPad port of Full Control Studios' Space Hulk, an adaption of the Games Workshop board game.

Both of these games are obviously influenced by AAA videogame aesthetics. On top of a base of a fairly well established gameplay tradition (Magic: the Gathering, and Space Hulk / skirmish miniatures, respectively) they layer on 3D animation, character voices, and lots visual effects. These are, of course, unnecessary for gameplay, since both games could comfortably be played with cards, dice and paper. They're entirely spectacle.

In particular, my experience with Hearthstone was to install, play for about 2 hours until I thought I had a pretty good sense of the game in my head (Magic: the Gathering, but built for speed, and with slightly larger numbers), and then uninstall. I uninstalled not because I wasn't having a good time, but because it didn't seem to be doing anything to resolve the basic tension of collectable card game design: the promise of putting together a strategy only to be surprised when it is undone by playing against someone with cards you'd never seen before, versus the reality of dominant strategies evolving and being available to anyone willing to spend the effort to put a dominant deck together.

I think back to times in my life when I was more interested in spectacle: mostly when I was a teenager. I don't think it was so much that I was easily distracted by shiny objects and now I'm somehow more resolute, but rather that a lot of gameplay was still brand new to me, and given the option to explore a new idea a couple of ways, I'm happy to pick the pretty one. These days, I'm less interested in spending time on something that seems new, but really isn't, and so I've developed an attraction to sparer aesthetics that make it easier to tell whether I'm dealing with something new or not before I spend a lot of time with it. Maybe that's because I'm a game designer, and so finding clever things in games is a big part of my life, or maybe it's because I'm just older and more aware of my own mortality.

Because of the great response to my "Ludic Century" essay, NYU has invited me to participate in a panel discussion about Eric Zimmerman's Manifesto, beside Zimmerman, Abe Stein, McKenzie Wark, and moderated by Heather Chaplin!

The panel, on Thursday, November 14th, is free, but requires an RSVP, which you can find links to, along with more information about the panel, here.

I'll start with the background.

NYU Game Center professor Eric Zimmerman wrote a manifesto to appear in a forthcoming book, The Gameful World. In this manifesto, Zimmerman lays out an argument that the 21st century will be a century of ludic revolution as the 20th century was a century of information revolution.

About a week later, MIT Game Lab researcher Abe Stein publishes a retort on KillScreen. His fundamental concern is that Zimmerman's manifesto relies too much on digital technology, and as a result marginalizes cultures and persons who aren't privileged enough to participate (the poor, the non-coastal non-urban, the developing).

I think both are fundamentally flawed, for different reasons. However, there are things being addressed here that are scratching at a breakthrough, and I am of the belief that "it's complicated" is more than a relationship status, but the way of the world.

vs.