Gameplay metrics: game design’s best kept secret?

So Laralyn McWilliams just wrote:

And I agree so much with that that I had to write something about it.

When game developers talk about metrics, we typically mean one of three things:

1. F2P metrics, like retention, DAU, ARPPU, etc. This all came out of online marketing, and it’s what people associate with “evil f2p”.

2. Level design metrics, like how high are cover objects, how high are walls the player can’t jump over, etc. This is needed to build level geometry that plays well.

3. Gameplay metrics, which is what Laralyn is talking about, and which seems like the best kept secret in game design or something.

Let’s look at some history:

Continue Reading »

What I talk about when I talk about “story”

First of all, if you’re interested in narrative design at all, you should follow Thomas Grip on Twitter. There are few people who write so many tweets that I agree with. That said, I don’t agree with every single thing he says.

Today, for example, he said:


To which I replied:


And so here is the longer (but still very quick) explanation of what I mean by that.

Continue Reading »

What I learned going from game programming to web programming

I foolishly promised Amandine on Twitter that I would write about my experiences going from hard-core C++ game tech to web tech. And so, before this ends up on the pile of Things I Could Write About, let me take a stab at actually doing so.

Back in the 90s I wrote hard-core game tech in C++ (and before that in C and 68K assembler). Then, in 2001 or so, I changed careers and programming became more of a hobby. I used Python to write small tools, then later got into HTML and CSS. Then, while ostensibly being creative director of the company I co-founded, and despite being surrounded by hard-core C++ programmers whose knowledge, unlike mine, was not literally from the last millenium, I was writing a lot of tools in Python, as well all of the HTML and JavaScript and what have you.

Additionally, I developed Gameconfs and am currently developing full-stack web-based tools for Moon Collider, an AI middleware company. So I guess I’m a web developer now.

Anyway, very quickly and in no particular order, here are some of the things I found remarkable in going from C++ to web technology:

Continue Reading »

A brief note on the formalism discussion

After having read ‘Parley’ by Frank Lantz, I wanted to write down a couple of thoughts about the discussion on formalism that has been going on recently, even though I haven’t followed every part of it, and can barely spell ‘Deleuzian’.

First of all, Parley is great on several levels. It is well written, well argued, and a nice summary of the debate so far.

Second, I am very glad that Frank explains why he felt that:

folks who are aren’t as interested in theme and narrative see an emphasis on theme and narrative everywhere, so they are baffled by the claim that attention to theme and narrative is being crowded out or dominated by attention to rules and structure.

Because I sure don’t feel that way, which is why I must admit that despite my great respect for Frank I felt a hint of annoyance when I read his “we see pretend worlds and childish make-believe” line. (A line which for most people failed to make the point he wanted to make, as he explains in Parley.)

I now completely understand why he feels that way, and that has been enlightening.

But here is what it looks like from where I am sitting, looking more at the design side than the criticism side:

I’ve led a workshop on narrative design last year, and am about to do another one in two weeks. And to prepare for that, I have reviewed my book shelves to look at what other people have been doing.

My books on writing: check. Some good stuff there, and I kinda know how to adapt and integrate that. (You can find some of those books here.)

My books on storytelling in games: sure. Lee Sheldon’s Character Development And Storytelling For Games. Katherine Isbister’s Better Game Characters by Design. I know there’s a couple more, but I’m not really doing a workshop on writing, I’m doing one on narrative design.

So what about my two shelves with books on game design? Meager. Very meager. Here is what I find when I take some books off the shelf and riffle through the table of contents and the index:

  • Salen & Zimmerman’s Rules of Play: 10 pages out of 638.
  • Schell’s Art of Game Design: 4 chapters out of 33. Better than most.
  • Bates’ Game Design: 1 chapter out of 14. And Bob is a writer and adventure game designer.
  • Fullerton, Swain & Hoffman’s Game Design Workshop: 1 chapter out of 16.
  • Brathwaite & Schreiber’s Challenges for Game Designers: 1 chapter out of 21.
  • Fields & Cotton’s Social Game Design: nothing.
  • Trefry’s Casual Game Design: 6 lines.

Chris Crawford’s later books are the only ones dedicated to what one could call narrative design. Maybe The Game Narrative Toolbox will be good – I won’t know until June.


Here’s another fun example. Please allow me to unfairly pick on Stone Librande, someone whose talks I’ve enjoyed and who I’m sure is a perfectly nice gentleman. Here is the syllabus for the Game Design Fundamentals course he teaches at CMU. And here is part 12, out of 15:


While a game can be abstract, adding a theme can help draw players into your game world. This week’s lecture will examine how the “flavor” of a game can enhance the game player’s experience.

Workshop: Thematic Decisions

Design a character that could appear in a low-budget zombie movie. Create a set of options that describe how that character would move and attack if trapped in a room filled with zombies. Make sure that all the options are thematically appropriate. For instance, a Sheriff would be expected to carry a gun, but a Priest would not.


Work on your final project. Focus on elements that will add atmosphere to your game such as colors, fonts, characters and story. 


Flavor. Theme. Atmosphere. Elements such as colors, fonts, characters and story.


That’s what things look like from where I’m sitting. The people teaching, writing, and speaking about designing games, the ones who shape the debate, are primarily focused on the mechanical side of game design, and not on the fictional side or the integration of those two. (I am primarily looking at designers, not critics, although of course there is some overlap.)

That doesn’t mean we shouldn’t look at the mechanical side – we should, and I find that aspect fascinating, and important. And different people like different things about games, and have different approaches to games. That’s all fine.

It also doesn’t mean every game needs a “story”. But most games have a fictional side, a world in which they take place. For me, the mechanical and the fictional are two aspects of the same thing, and I find the best way to approach designing them is in an integrated manner, and this goes for most games, all the way down to ostensibly abstract games like Tetris (see here).

And that is exactly what I will be talking about during my talk at the GDC narrative summit this year, so this formalism kerfuffle better have died down or I can see I will have to add some slides to my talk.

Extreme data-driven development on Ambermoon, Amberstar, and Albion

More war stories from the depths of time! My first job in the industry was main programmer on Amberstar, a big role-playing game by Thalion Software for the Atari ST.

Amberstar was developed in a very interesting way. It was the brainchild of Karsten Köper, who before joining Thalion had developed a role-playing game called Mythos for Atari XL and Commodore 64.

He had spent about eighteen months developing a set of editors in GFA BASIC, a very powerful BASIC for the Atari ST that was quite popular in game and demo development. (Fun fact: Karsten is mentioned alongside Eric Chahi on the GFA BASIC Wikipedia page.) These editors allowed him to create data for any role-playing game in any setting – a bit like GURPS for computer role-playing games. Characters had attributes like “number of ring fingers”, for potential sci-fi settings.

So what I received when I started was a description of each screen in the game (typical for this kind of role-playing game, it was very GUI-driven), and a description of the binary data formats of the files that Karsten’s tools generated.

And that was it. I spent about a year writing a program on Atari ST that could handle these files while Karsten created all of the maps, quests, items, etc. and the artists created all of the art (from, if memory serves, lists that Karsten made using his tools).

The interesting thing was that a two man team based in Hamburg was doing the exact same thing for the DOS version. I met them at the start of the project, and I talked to them once during development over the phone (to discuss something I was doing in code that was, for once, not coming from the data), but that was the only contact we had.

After a year, we had the same game for two different platforms. I’m still impressed that this worked out so well. Arguably it’s an inefficient way of porting, since the DOS version required twice the programming manpower as the ST version, and the Amiga port was done the “traditional” way. But it still feels very different from any normal approach to game development. Of course, these days you can achieve the same effect using RPGMaker.


We used the same system for Ambermoon, the sequel to Amberstar. Ambermoon was developed for the Commodore Amiga, but we kept editing the data on Atari STs.

We made some changes to the underlying system. I came up with a couple of those changes – if I remember correctly I made some improvements to the conversation system.

This time two people created the data for the game. Since we didn’t have a network, this meant putting certain core files on a floppy disk, and whoever had the floppy could edit them.

At the end of 93 things were going downhill with the company and people started quitting. The remaining developers, me included, went to Blue Byte (actually we just changed the name on the door). In order to “quickly” deliver a game to them, we decided to make another role-playing game using the same editor system. This turned into Albion, and took two years and an enormous amount of crunching.

(Careful readers may ask: Hey, did you take key technology that represented years of development from one company to another? The answer is: Yes, we did. Yay the 90s.)

Everyone except me switched to PCs for development (and we got a network). Since the game was being developed for the Commodore Amiga, I was using that, until Commodore went bust and the entire project switched to PC and C (from 68K assembler which is what I’d been using since 1991).

But wait, you ask again, you were using PCs, but those tools were written in a custom BASIC for the Atari ST! How could that possibly work?

The answer is: hardware ST emulators. Every developer who used the tools had a special card in his PC, and we switched from DOS to GEM and back. And to make things weirder: the emulator was entirely done in software: the hardware just contained a chip with the ST ROM (TOS) and perhaps a peripheral interface or two.

We made a lot of changes to the system for Albion, often driven by me, to allow us a lot more flexibility in our content. That flexibility was not always used by the scenario designers, which was a very valuable lesson.


After spending the first 5 years of my career doing extreme data-driven development like this, and being a designer as well as a programmer, I have a very special relationship to both data-driven development and hard-coding. I think I am now pretty good at creating data-driven systems, but I am also very aware of the advantages of hard-coding. Or, rather, mixing design and programming.

How organizations react to ideas

It’s time to talk about disruption again. This article in The Economist contains some bits I very much agree with:

Yet even short-sighted or embarrassed managers should react when the threat from upstart technologies becomes clear. They do not, economists reckon, because of organisational rigidities. Ms Henderson suggests firms can be seen as giant information-processing organisations that evolve a structure and personnel to fit their respective business. Information on sales or production is efficiently filtered to decision-makers, who can then direct new research. When new technologies are no more than tweaks to old ones, this set-up is a competitive advantage. When innovations are more radical, however, the old networks are a hindrance.

In other research with Sarah Kaplan of the Wharton School of Business, Ms Henderson considers why older firms struggle to pursue new technologies. Many of them have systems in place to detect and respond to changing market conditions or new technologies. But they have also built up a system of incentives to ensure employees meet existing goals. Systems designed to encourage consistency and efficiency in the production of established goods or services might be a powerful deterrent to experimentation or creative thinking about new markets, regardless of what the corporate memos say.

Companies and other organizations are systems set up to produce certain results. One might hope that they are set up consciously, designed and monitored to produce clearly defined results, but in my experience this is not often the case. Companies tend to form and develop organically, rather than consciously. But maybe my impressions are skewed because I work in games.

In any case: this is why, among other things, you usually don’t have to worry about companies stealing ideas. Those companies have their own thoughts about what they are going to do. To quote Howard H. Aiken:

Don’t worry about people stealing an idea. If it’s original, you will have to ram it down their throats.

The ideas people inside companies have are often based on incentives that are hard to see, or easy to forget, from the outside, such as “don’t get fired”. Sometimes, especially with projects that are very stressful and difficult (hello, games industry), people cling very, very hard to the one way they can conceive of finishing the project, and they do not want to hear about other ideas. I’ve been on both sides of this situation. My gut feeling is that this is related to studies that found people are biased against creative ideas, even if I’m not sure I agree with many of the popular interpretations of those studies.

Belated thanks

As I have mentioned on Twitter, I gave a talk about the dark side of game development at ENJMIN in December last year.One of my topics was sexism (and racism, homophobia and transphobia). I was very nervous about this subject. What do I have to say about this? I’m a white straight cis male.

So I asked for help. Specifically, I asked Amandine Coget (@LiaSae), Abi Sutherland (@Evilrooster), and Laralyn McWilliams (@Laralyn).

Their feedback helped me turn that section into the best part of the talk. I got a lot of great comments (and a hug) afterwards, and a lot of it was about this part.

(If you saw my talk: the list of things you can do to deal with sexism came verbatim from Abi.)

What I forgot to ask beforehand is whether I could mention them by name. Things being as they are these days, I erred on the side of caution, and did not mention them. I did say during the talk that I had gotten help from women, and why I wasn’t saying who they were. But I should have asked this before. So this belated blog post is my attempt to make up for that mistake.

On narrative in Tetris / Match 3, and mechanics in IF

Chris Billows asked the following on Twitter:

I want to reply very quickly and briefly, but without having to split things up into 140 character chunks. So:

1. Any statement about games will create edge cases where the statement breaks down. But the statement can apply to a sufficient amount of games to be useful. Tools, not rules.

2. I make a difference between fictional (non-abstract) and narrative (some form of ‘story’, something happening to someone).

3. Every game can be said to have a degree of ‘fictiveness’: some games have more, some games less.

4. There are very few purely abstract games which have no fictional element whatsover.

5. I used to think Tetris was one of them, but no longer.

6. The setting, the fictional part, is enormously helpful in casual games to quickly and efficiently explain how a game works. They provide metaphors.

7. I learned this working on casual games. I also learned this trying to fix the UI of an existing game, and realizing that the UI was wrong because the metaphors of the underlying mechanics (what those mechanics ‘meant’) were wrong.

8. (In case you wonder, the relevant metaphors in Tetris are gravity and solidity. Obviously this is an edge case and I don’t blame you if you scoff at it. But please think about fiction and metaphors. It’s very powerful.)

9. Regarding the mechanics of IF games, I answered that here:

Hope that helps a little bit.

Resources for my talk on the dark side of game development

Here are some resources to go with my talk about the dark side of game development that I gave at ENJMIN on December 18th 2014.

Talking to people

Effective Networking in the Game Industry – Darius Kazemi


Impostor syndrome

Kill The Goddamn Vulture – Richard Dansky

Your body language shapes who you are – Amy Cuddy (especially 16 minutes in)

Sexism, racism, homophobia, transphobia

1ReasonToBe panel (GDC 2013) – Leigh Alexander, Mattie Brice, Robin Hunicke, Kim McAuliffe, Brenda Romero, Elizabeth Sampat

Straight White Male: The Lowest Difficulty Setting There Is – John Scalzi

But WHAT CAN BE DONE: Dos and Don’ts To Combat Online Sexism – Leigh Alexander

Geek Feminism wiki

Misogyny, Racism and Homophobia: Where Do Video Games Stand? (GDC 2014) – Manveer Heir

Stress & Depression

The Belly of the Whale: Living a Creative Life in the Game Industry (GDC 2010) – Bob Bates

General tips

From Student To Designer – Liz England

100 things every game student should know – Kaye Elling

Some notes on narrative design

This morning I reviewed some student projects at the Ecole Bellecour here in Lyon, from a narrative design point of view. This meant listening to small teams as they presented their ideas for their projects, then giving them feedback and suggesting things they could do. In some ways, this is the most fun part of the concept phase, but with neither the investment nor the effort of fleshing it out and making it work.

I am a big believer in learning by teaching. When I explain something to others, I am forced to express it as simply and clearly as I can. And so I want to capture here some of the things I’ve learned by trying to help students.

Teaching the player

The player will need learn how your game and your world work. This applies to the mechanics as well as to the story. This is not just something that happens in the beginning, in some kind of dedicated tutorial phase, but all through the game. So you need to think about how you are going to introduce characters, convey backstory, etc., knowing that players will skip texts and cut-scenes, and that showing is better than telling.

In fact, you can even flip things around. Instead of saying “how will I convey this information to the player”, start with the constraints and try to come up with a story that can be conveyed within those constraints. Don’t be afraid of stereotypes: embrace them and use them well.

And remember that you can leave things open and explain them later, or even not at all.

The fictional and the mechanical

Make sure the logic of your fictional world matches the logic of your mechanics. Or rather, that your gameplay can cash the check your world has written.


Think about what is a convention in your game, meaning something you want the player to just accept as is, and what is diegetic, meaning something that is part of the fictional world you are trying to evoke in the player’s head. (‘Diegetic’, as used here, comes from sound design. The song from a radio inside a movie is diegetic, the song that is playing without any source is a convention of the movie medium.)

You may have things on the mechanical side of your game that you can make diegetic. By doing so, you give meaning to these elements, and you can combine them with other elements on the fictional side, making them contribute more to the player’s experience.

(I was particularly excited about a suggestion I made along these lines for one of the projects, and the students seemed to like it as well.)


Think about how you can make what happens on the fictional side change depending on the player’s actions. This is how you give meaning to what the player does.


What are you trying to express with your game? It doesn’t have to be directly in the game, it can be in the subtext.