Skip to main content

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 Northern Game Summit on October 1st 2015.

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 for students

From Student To Designer - Liz England

100 things every game student should know - Kaye Elling

Again, many thanks to these ladies for their help with this talk.

The RSS feed of this site has changed

Following on from the previous post, here is the new URL to the RSS feed for this website:

Again, sorry for the inconvenience.

Update: Well, this is awkward. This post showed up in both the old and the new feed, even though I turned off the old feed on the WordPress side. I don't even know how this is technically possible. Undead accounts, leeching content from beyond...

Still. Better change your RSS feed URLs just to be sure.

Update 2: So that old Google account was not dead after all. Why am I not surprised. I managed to regain access to it, logged into FeedBurner, and deactivated the feeds there with permanent redirection to the proper URLs.

Read this if you subscribe to the RSS feed of this site

The short story: I am going to change the address of the RSS feeds for this site. And I am going to do it today, and then I will create another blog post saying that I'm done. This blog post will also contain the new URLs.

If you do not see this second blog post on May 4th 2015, then you're still subscribed to the old feed, and if you want to continue to read my blog, you will have to go to the site and get the new feed URLs. Which I cannot publish here for esoteric reasons explained below.

I apologize for the inconvenience. Also, if you subscribed to this blog by email through FeedBurner - and I have no way of knowing if anyone is doing this - then I apologize even more, because that will stop working entirely.

(Update: Changed "right away" to "today" because I am dependent on when RSS services like FeedHQ etc. query the current feed. So, eh, I'll do it tonight at some point.)

The long story: I want to switch away from FeedBurner, the service I used for my RSS feeds, because it is no longer useful to me, and it was bought by Google. I like being independent of Google in general, but even more so in this particular case, because FeedBurner has been languishing, and there have been rumors for some time that Google may kill it. Another reason for me to wrest back control over my RSS feeds while I still choose the moment to do so.

Additional wrinkle: I transferred my feeds from my old FeedBurner account to my Google account in 2009, then completely forgot about it. Sadly, that included when I moved everything from my old Google account to my new one some time ago. This was something I had to do because… I can't be bothered to explain it here, suffice to say it involved a GTalk account created for testing, and Google stupidity.

So I cannot even access the FeedBurner feeds anymore, because they're tied to a supposedly dead Google account. One which, by the way, is tied to an email account I am about to retire. Now you know why I'm trying to regain control over everything. (I looked into this in the first place because I am planning to move my blog away from WordPress.)

And I cannot give you the new RSS feed URL here because it would just redirect to the FeedBurner ones.

Time for a short, sharp shock. Good thing I am not a pro blogger.

Session evaluation of my GDC 2015 talk

Today I received the evaluation of my GDC 2015 talk on narrative design:

Total Headcount: 470 (holy shit)

Session Ranking within Game Narrative Summit: your session is ranked 13 of 19 

Session Ranking within GDC 2015 Summits: your session ranked 82 of 133

-The Total Headcount shows the number of people who were scanned for the session.
-Session Ranking within your summit and amongst all sessions overall at GDC 2015 Summits. Please note, the highest rank is 1 and it is out of the number of sessions within the summit and conference, respectively (excluding sponsored sessions. special events, roundtables, main conference track sessions, tutorials, etc)

Session Totals:
Evaluation Response -- Total Count of Each Response

Excellent --- Count: 62 , Percentage: 40%

Good --- Count: 78 , Percentage: 51%

Poor --- Count: 13 , Percentage: 8%

Terrible --- Count: 1 , Percentage: 1%

- Session total lists the number of people, who responded in each category (ie. Excellent, Good, Poor, etc.). Percentage lists the percentage of responses for each category based on the number of evaluations that were returned.

If 91% of people who responded thought my talk was excellent or good, and that got the talk a rank of 13 out of 19, that means the narrative summit got really positive responses. Congratulations to the advisory board!

Individual comments:

  • Could have been longer but still very interesting 
  • Really entry level thinking, could have read a "writing for games" book instead (Show me that book honey)
  • The content was well presented, but it wasn't anything I didn't already know. 
  • A good and thoughtful survey of some places where story/narrative and gameplay intersect and some theoretical analysis of how existing games treat narrative. I wanted it to get deeper, though, finding more compelling insights. It had that "I'm doing a good job articulating things you already know but haven't articulated this well before" problem. Great presentation materials and delivery by the speaker.
  • Topic was worth a complete hour
  • I wish he had had more time, because he didn't get to cover much. Really great speaker. Interesting ideas, and a great presentation overall.
  • The examples were good, but the talk felt a bit slight, possibly because of the limitations of the session length. I would have liked to see more examples of practical ways to mesh story with gameplay mechanics, a deeper dive.
  • Good thinking about diegetic elements which provoked me to closely consider some design choices I have in front of me. 
  • lots of great content, maybe moved too quickly through it. 
  • Forced me to consider writing as it relates to design in a new way! (That made it all worth it.)
  • Cool
  • Information covered was basic, and didn't seem to coalesce into a coherent point.
  • Great speaker. Good pacing, good flow, easy to understand (both volume, and topic), entertaining. Very inspiring topic. Majestic beard.
  • It was a thorough talk with inspiring material. Good food for thought. I enjoyed it.
  • I quite enjoyed the examples and the clean, clear presentation
  • Connected narrative to the mechanical aspect of games. 
  • It made me think a bit about story and how it ties to game mechanics such as UI, so I guess that's good. It felt light on the content overall but somehow I'm ok with that.
  • A few good examples, but not revolutionary.
  • Amazing insights into story and game design intertwined. The speaker was excellent in his explanations of less understood concepts. (<3)
  • i enjoyed the speakers thought process. but i was expecting more about "why the narrative side of a game is important in games that don't have a story." I don't believe all games need a strong narrative. but this talk seemed to not want to talk about games that arent' telling a story. (i think our industry is too accepting of "entertainment experiences" which really aren't very good games. so i'm interested how to learn from strong narratives, without just being a movie. + was a little offput by repeated callouts to some guy in the audience with some sort of opinions on what not to talk about. (Poor Lee) Still, i liked the speaker.
  • Interesting talk, though I feel it could have gone a little deeper, or provided some structure/process for implementing the ideas talked about.
  • I felt like there weren't any key takeaways from the talk. Needed more substantial detail. (I'll make the font bigger next time.)
  • It was really helpful to hear some of the common conventions that have become used to being called out, like audio logs in games, or "voice through the headset" in an FPS. 
  • Narrative design 101. Not a bad session but this is GDC, step up the level a notch beginners courses don't belong here.
  • Solid info but meh delivery. 
  • Really great points. I wish there were more notes on the slides (for easier note-taking), but I thought the speaker and the content were great. (Yeah, the downside of my slide style.)
  • Liked a lot of it, but at times he seemed disdainful of story and writers, which made it seem a curious choice for this summit. But still fun. (Not the impression I wanted to give.)
  • Overall a good session. had some great nuggets.
  • Interesting subject but did not go into real depth or insight. Less examples and going deep would be great. 
  • Interesting talk, always interesting to hear about writing.
  • Very little practical application or takeaway, and the underlying philosophy was kind of obvious. Felt like a talk suitable for students, not professionals.
  • "you can have a healthbar... or you can have a diagetic healthbar!!" -this talk (If you'd stayed for more than 5 minutes you would've known how to spell 'diegetic')
  • Really great speaker, really great examples. I love these sessions which call into question our most basic assumptions. (Love this comment right after the previous one.)
  • Great re-positioning of thought on how narrative and game design intersect.
  • Very charismatic speaker, really basic talk though, would've liked a bit deeper exploration. 
  • 25 minutes is too short to truly get into anything of real substance.
  • Awesome session, just wish it was longer!
  • Great content, I enjoyed the humor as well! 
  • The overall theme of this was simply, but appreciated. Essentially, gameplay and narrative are equally important. This is something I knew, but as with other panels, it was nice to hear this echoed in a panel setting like this. I do think the use of "mechanical" to mean "gameplay" and "fictional" to mean "narrative" was slightly unnecessary, when they mean the same thing. Just a lot of great points packed into 25 minutes, especially the takeaways at the end with regard to storytelling skills in dev teams, what's needed, who needs what, etc.
  • Very much enjoyed it.
  • Great talk, very insightful content!
  • I still don't know what the heck a "narrative designer" does...

The "this was obvious" comments are interesting. Either it is obvious, or it's obvious but nobody had quite said it so clearly. Naturally, I hope it is the latter :)

Overall takeaway: people seemed to like it, but quite a few felt it was short or wanted more. I intentionally tried to explain one distinct concept very clearly, which is why I chose the 25 minute length. Also, it's easier to get a 25 minute slot.

I think there's more to be said about diegesis, but I don't think I could have clearly expressed those things at the time I prepared for the talk.

The mystery of Miholjanec

I was reading the Wikipedia entry on Charlemagne, as one does, and noticed his sword had a name: "Joyeuse". Joyous one. And, since "épée" is feminine and Charlemagne was not, it is the sword who is joyous.

Named sword. So far, so cool. Hey, it says "sword in Vienna" (I used to live in Vienna). Let's check that out:

Sword in Vienna
Before the Miholjanec legend had been regarded, the so-called sword of Attila in Vienna was known as the sword of Charlemagne.

The what now? Let's click on "Miholjanec legend". It leads to a Wikipedia entry on the Croatian village of Miholjanec. But there is no mention of a legend (the URL leading me there contained the fragment #Legend, but that now leads nowhere).


What is this about the sword of Attila?

The real historical events of the discovery of this sword will probably remain unknown. More information about the origin of the sword is a legend about a locality of finding, see Miholjanec#Legend, because before this legend had been regarded, this sword was known as the sword of Charlemagne known as "Joyeuse".

That same broken link.

Before we click onwards: note that the sword of Attila is supposedly in the Imperial Schatzkammer in Vienna. Just like one of the items claiming to be the Spear of Longinus, the Spear of Destiny, the Holy Lance. And regarding Charlemagne's Joyeuse we know that "some legends claim [it] was forged to contain the Lance of Longinus within its pommel". So these two swords and the Spear of Longinus are related.

What does the history of the Miholjanec page tell us? There was a change on the 20th of November 2013:

"Deleting "Legend" section: unsourced and doesn't improve article"

So what was this legend?

A legend about Miholjanec describes the discovery of an unknown ancient castle in 1270, when the King personally visited Miholjanec is also a legend:

On the dreary heights of Grga was once a handsome village, whose inhabitants were elated. The abundance of gold and shiny possessions let the fear of God and morality dwindle more and more, and it attracted all sorts of wickedness and vice, as a permanent guest in the homes.


What do we get when we search "legend of Miholjanec" on Google?

The first hit I get is, OF COURSE, from the Bungie forums.

There is a legend that tells of a locality where an ancient sword, in some tongues known as the Sword of the War God, was found...

And then what looks like the deleted legend from the Wikipedia page, plus an interpretation of how this legend "embodies the resurrection of Christ and the coming end of the world in Revelation".

Uh. OK.

There's also a video, which looks like a Croatian powerpoint presentation about a city. I have no idea.

Back to Google. The second and third hits are Wikipedia pages we've already seen.

The fourth hit is an extract from "Zoroaster 177 Success Facts - Everything you need to know about Zoroaster" by Gary Holt, on Google Books. It says:

According to the Miholjanec#Legend|Miholjanec myth, Stephen V of Hungary had in fore of his marquee a made of gold plate with the inscription: Attila, the boy of Bendeuci, grandson of the significant Nimrod, born at Ein Gedi|Engedi: By the Grace of God King of the Huns, Medes, Goths, Dacians, the terrors of the planet and the flogger of God.

The English is a bit awkward, and the pipe characters look like Wikipedia-style text markers. It looks like someone did a very bad job taking text from Wikipedia and turning it into a book. And that looks like it might again be the link to the Wikipedia page.

The story of Stephen V of Hungary was indeed on the deleted legend part of the Miholjanec Wikipedia page.

Let's briefly search for this Gary Holt and his Zoroaster 177 Success Facts on Google. The Amazon US and DE pages say nothing about the book or the author, and list no other books by Gary Holt. It's a Print On Demand book, apparently. The Amazon UK page describes it as:

A New Benchmark In Zoroaster Biography. This book is your ultimate resource for Zoroaster. Here you will find the most up-to-date 177 Success Facts, Information, and much more.

In easy to read chapters, with extensive references and links to get you to know all there is to know about Zoroaster's Early life, Career and Personal life right away.

Well, OK.

Emereo Publishing looks like a mediocre website for mediocre books - like something generated. And funnily enough I can't find Gary Holt's book there.

Back to our search for "legend of Miholjanec".

There's a forum entry on a Catholic forum, in a discussion titled "Why are humans tribal?"

The entry contains a quote from a Wikipedia page, a quote we've seen before:

According to the "legend of Miholjanec". legend, Stephen V of Hungary had in front of his tent a golden plate with the inscription: "Attila, the son of Bendeuci, grandson of the great Nimrod, born at Engedi: By the Grace of God King of the Huns, Medes, Goths, Dacians, the horrors of the world and the scourge of God.

Which made me wonder whether Gary Holt wrote his book or copied and pasted it from Wikipeda?

But what struck me more was that this is supposedly a quote from the Wikipedia page on the biblical king Nimrod. And yes, there it is. And with the same broken link to the Miholjanec Wikipedia page. Nimrod has all kinds of connections to the Hungarians, Freemasonry, Finnish demons, etc.

Back to "legend of Miholjanec".

There's an extract from a book, again on Google Books, called "The Esoteric Codex: Magic Objects" by Mark Rogers. The extract looks like a copy of the Wikipedia page for the Sword of Attila.

Then there's an extract from a book called "Attila the Hun 170 Success Facts - Everything you need to know about Attila" by Ralph Vaughan.

Wait, what? Oooooh. That explains the stupid title of the book on Zoroastrianism. And yes, it's the Wikipedia page on the sword of Attila again.

And the next hit is "Boudicca 52 Success Facts" by Russell Leon, with our by now old friend the sword of Attila.

The second page of Google search results for "legend of Miholjanec" doesn't give me new information. This is all automated circle-jerking leading back to that deleted part of the page on Miholjanec.

So who wrote that?

It turns out the part about the legend was added on October 13th 2011 by an anonymous contributor. A lot of other changes to that page were made from the same IP address. This person or persons seem to know a lot about Miholjanec.

Funnily enough, that IP address is associated with UPC Telekabel in Vienna, Austria! Which is not a huge surprise since there are enough Croatians in Austria.

And that's where I will stop, before I have to do *real* research.

What have I learned?

Well, mysterious content is mysterious, briefly, and automated content is horrible.

And I've learned that Miholjanec is a pretty interesting place even without the legend. It's been around since the Iron Age, the Knights Templar were there, it has ancient vineyards. If I were doing a Kenneth Hite-style roleplaying campaign, it would be a cool location.

Recruitment bait-and-switch

À propos of nothing: the first in a series of recruitment war stories. 

Back in 2006, just after the closure of Rockstar Vienna, where I had been a producer, I received quite a few contact request from HR departments and recruiters. One in particular has always stayed in my memory, for reasons which will become obvious.

I received a LinkedIn contact request saying:

Hi Jurie 

Let me formally introduce myself, My name is [REDACTED]. I am Lionheads official recruitment manager in the UK. The hiring managers have recently constructed a list of what they believe are the best design talent in the world and they have specifically asked me to contact you to see if you are interested in potentially working on their latest projects in the future. 

Due to your location I wanted to sound out 1st if you could possibly be interested in an opportunity at Lead Designer level working on Fable 3 

If so please can you email me your contact details ASAP and a time/date to call you to catch up formerly

Unmodified except for the removed name. Who needs grammar, eh?

Please remember that Fable II had been announced in 2006 and was released in 2008. So working on Fable 3 seemed interesting, and gosh wow I was on a list of the best design talent in the world? Younger, more gullible me accepted the request.

The job offer I then got back was:

Associate Producer

This person must be an experienced, communicative individual able to take on management of a 22 man code team.

Duties include scheduling, meeting tracking and issue chasing.

If I remember correctly this was for a port or something, related to Fable 2. Nothing against ports or associate producers. I've done both, fun work.

Still, not quite "lead designer level working on Fable 3".

Slides and post-mortem for my GDC 2015 talk on narrative design

Here (12.8 MB PDF) are the slides from my GDC 2015 talk on narrative design. The black slides are my notes, which roughly resemble what I actually said. I have removed the bonus slide showing Verena Riedl - you had to be there :) (Or you can watch it on the vault eventually.)

And here they are embedded:

Inspired by Liz England, here is a little post-mortem of the talk.

This was strictly speaking not my first time as a speaker at GDC. Back in 2000, together with Mark Barrett, I moderated a round table on creating emotional involvement in interactive entertainment. In 2008 I gave a talk on being a producer at GDC Europe, the last time before it moved from France to Germany. But this was my first talk at GDC in San Francisco, and certainly the biggest audience I've ever spoken to.

It went well. The preparations went well, the actual speaking went well from my side, and I've only had positive reactions so far, including quite a few people coming up to me during the rest of the conference to tell me they had enjoyed my talk.

This was the third presentation I've given since December, the other ones being my talk at ENJMIN on the dark side of game development that I've briefly mentioned here and here, and a quick talk about storytelling in games I gave over Skype to Nathan Sturtevant's game capstone class. I feel I've learned a lot from giving these three talks, more so than from previous ones, so here are some unordered observations.


Passion counts. This was first pointed out to me by Jean-Michel Blottière after a lecture I gave to ENJMIN students in 2011. He said (I'm paraphrasing) that the students could feel when I was excited about a subject and when I wasn't. This didn't really sink in until I gave my talk on the dark side of game development, which I was quite passionate about. I exposed myself a lot more than I usually do, and showed more vulnerability. The only honest way I could think of to talk about topics like impostor syndrome, depression, sexism, etc. was to say how I experienced them (or not, in the case of sexism, racism, homophobia, and transphobia) and how I felt about them. And it lead to very positive reactions.

I am not quite sure which conclusion to draw from this, except perhaps to pay attention to my own excitement levels while writing and practicing talks.

The first practice run sucks. I knew this and you probably know this. It's the same when iterating in any creative endeavor. But, again, it didn't sink in until I did the first practice run of my dark side talk in a hotel room in Angoulême (yes, just a few days before the talk). It sucked, but this time I knew it would suck, and I watched my talk improve every time I practiced it. My edits started off big (changing the approach, changing the structure, cutting out huge sections) and then grew smaller and smaller. I think I practiced it 3 or 4 times. For my GDC talk, the process was a bit different, because:

Preparation begins way before the first practice run. This may also sound obvious, in a "Picasso lifetime story" kind of way. Obviously I am excited about storytelling in games and know something about it, but it has not been my full-time job for quite a while. I changed that by convincing several game development schools I could do workshops on narrative design. That forced me to pay more attention to the subject again, to re-read books, and to try and express my thoughts. The latter is one of the huge advantages of learning by teaching. The Skype talk I gave to Nathan Sturtevant's students was before I had done any practice runs for my GDC talk, but it forced me to express some ideas in ways that turned out to be extremely useful later. I will give some more examples of how key early preparation was below.

Talk submissions are a sales process. This is not meant to sound cynical: a lot of things are sales processes. What I mean is that there is a gap between me feeling excited about a subject, which happens a lot, and convincing someone else who is at best only mildly interested in my good fortune that my talk will be a great addition to their conference program. Which leads me to the next thing I learned:

Outlining had a bigger impact on my GDC talk than anything else. I have submitted GDC talk proposals for the 2001, 2002, 2003, 2006, 2010, 2011, and 2012 GDCs. That's just for the main GDC. Probably every time the submission website said something like "you can optionally upload additional materials so the advisory board better understands your talk". And I never did so, including for this year's GDC. But the narrative summit has a two-stage process, and the second stage involves close contact with someone from the advisory board, in my case Mary Demarle. In her first email to me, she wrote:

"I'd like to talk to you a bit more about your submission; there were no documents or files attached to it, so it's difficult for the board to get a solid sense of what you plan to talk about in the 25 minutes allotted. However, we all agree that the subject of how best to get writers and designers collaborating is an important one."

I wonder how many of my other proposals were not accepted because I didn't send an outline and didn't explain my talk clearly enough… There are a ton of factors that go into making a conference program, so it's not a guarantee for approval, but I now feel stupid for not having sent outlines before.

And there was another huge advantage. I exchanged some emails with Mary about the subject of my talk, then I iterated a couple of times on an outline with her. That gave me a rock solid base to start from. Once I heard that my proposal had been accepted and I had to start working on the "real" preparation, I noticed I was a lot less stressed than I have been for other talks. In fact, I think I mostly ignored it until February.

I also sent the outline or described my talk to a lot of people. Even the shortest feedback was valuable because it showed me what people took away from it, what they thought I was saying, and that allowed me to tweak the structure and wording. This is one reason why the first section of my talk contains some definitions, which I had written  for the Skype talk, and honed afterwards based on confusion I noticed.

Rehearsals. The GDC people sent me a link to this article by Chris Hecker on how to give good presentations. His key points are 1. rehearse a lot, and 2. rehearse in front of a live audience. The article also contains advice from Chris Crawford. Chris doesn't rehearse in front of a live audience but he rehearses up to 30 times(!). I think I rehearsed 5 times or so, and that helped a lot. One rehearsal was in a hotel room in front of a live audience, consisting of my wife Andy and our good friends Verena and Sebastian. That made me remove some problematic slides and add game titles to all of my full-screen game screenshots.

One weird thing I did in mid-February was a practice run in my head, just mentally talking to an audience, then writing down the outline of that, then comparing it to my original outline. It was very close.

Talking to the advisory board is not cheating. I only learned this in 2005. Last year I bounced the idea for this talk off of Richard Dansky. He said that in principle it might be something that fit the summit, but also gently reminded me that most of the narrative summit attendees are writers (which I, perhaps naïvely, hadn't realized - I've always gone there as a game designer). That helped me make sure the talk fit well. Again, early preparation.

I am a big fan of presenter notes, meaning the feature many presentation apps have, including Keynote, PowerPoint, and Deckset, which allows you to add notes that are just for you and that are shown on your laptop's screen while you're presenting. I tend to basically write out what I am going to say in the presenter notes. I did that for my GDC talk as well, except during some slides (e.g. 40 and 42) what I said was more elaborate than what I wrote down. I am not quite sure why this is - some bits come natural, I guess, but they are not necessarily bits that I rehearsed a lot. Perhaps these are just things I've already said a lot outside presentations i.e. I'm passionate about them.

Related to this: I like to support my transitions in my slides and my presenter notes. It's usually not difficult to have a topic on screen and talk about it - what I find harder is stringing those together into a coherent structure. So those are the bits I tend to be more literal about, to make the presentation flow better. I am not sure why. E.g. "Here is an example" on slide 44. I think I have two approaches to slides: either I set the transition up for myself, or I trust that I can make the mental switch when I see the new slide, and can avoid making the transition seem jarring. Rehearsals help with this too.


Using Deckset worked well. Not perfect, but well. I felt it was a bit risky to not use PowerPoint or Keynote for my GDC talk, but I also knew I'd be able to re-do all the slides in either of those tools if I needed to. And being able to write all of my slides in Markdown in the text editor of my choice meant I could write and modify drafts a lot faster. And unlike Reveal.js, which I used in 2013, I could have presenter notes. I found I could use Remote Buddy to add remote control (which I then ended up not using, see below).

Deckset's (and Markdown's) limitations meant I couldn't spend time tweaking the exact positions of text blocks (good) but also that there were certain things that were just not possible. That's why the presenter notes are centered and white on black… and also why I needed Verena's help to put the game titles on the game screenshots using Photoshop: I couldn't find a way to do it with Deckset.

The speaker rehearsal room was nice. GDC has speaker rehearsal rooms which you can reserve and where you can rehearse your talk in an actual GDC room with actual A/V tech managed by an actual A/V person. I did that just before my talk. Then I hooked up my laptop in the real room and it didn't work! I had to reboot my laptop, and then RemoteBuddy wasn't loaded, so I couldn't use the remote. But I didn't have a lot of space to pace around in anyway, so using the keyboard was no problem.

Feeling your entire presentation is worthless during preparation is normal. It's normal for any creative process in fact. For me, additionally, I had no idea whether people would be interested in hearing what is arguably a design trick I came up with in the 90s. I could think of a thousand reasons why they wouldn't be! But I just trusted the advisory board, and it ended up fine.

In the end I felt as if I didn't spend as much time ("at least 30 hours") on this talk as I should have done, but when I read all this back I probably did, it's just that a lot of it didn't feel like actual talk preparation. It was a great experience, I learned a lot both about storytelling in games and about communicating, and I hope I can do it again sometime.

Update: I've added the slides as an embedded widget. I also just realized that having done some teaching has made me more aware of how one can try and convey something effectively, and that made me approach the outline differently (not that I consider myself a great teacher, but I definitely learned from the process). I tried to explain a pretty esoteric point, one that I had known for over 15 years. I don't know if one year ago I would have front-loaded the talk with examples the way I did.

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:

What if I told you Crash Bandicoot was made according to precise metrics about what happens when? There was an interview in Next Gen magazine back in the 90s that explained how they did this. It had a big influence on one of the teams (hi Stéphane) at the company I worked back then. If I remember and understood correctly, this was Mark Cerny's big contribution to the game, Naughty Dog used it in later games as well, and Michael John, who worked with Cerny, used the same method on many other successful games. I recently found my photocopy of the interview - I've not been able to find it online. I should really scan it.

What if I told you that to me the most interesting part of the 1999 post-mortem for Half Life was not the cabal process (remember that?), but this single paragraph:

Toward the middle of the project, once the major elements were in place and the game could be played most of the way through, it became mostly a matter of fine-tuning. To do this, we added basic instrumentation to the game, automatically recording the player's position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.

(While searching my email archives on this topic I just found a 2007 email I wrote to a mailing list that says:

Quantified analysis of gameplay has fascinated me ever since I read the Game Developer post-mortem of Half-Life 1.

And I'm still fascinated over 15 years later.)

What if I told you that Ensemble and Bungie used gameplay metrics since at least 2000 or so? And that Microsoft gave regular presentations on how to do usability testing with metrics at GDC in the early 00s?

What if I told you that Ubisoft was using playthrough analysis tools in 2004 for the multiplayer modes in Splinter Cell?

Naughty Dog, Valve, Ensemble, Bungie, Ubisoft… see a pattern?

This is all pretty much public knowledge. But how come I don't read about this in game design books? How come I don't regularly see Gamasutra articles or conference talks about this? It feels like game design's best kept secret sometimes.

Update: And of course pretty much every MMO has done this since forever! And have given talks about it!

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.

Terminology is a big problem in discussing storytelling in games. I could write a blog post about why that is, but it is not this blog post.

Because I've been teaching storytelling in games and am about to give a talk about storytelling in games at GDC, I've been forced to sharpen my arguments a little bit. (Which is great! Learning by teaching.)

And so right now my personal definitions for story-in-games-related terms go like this:

"Story" is pre-authored and about something happening to someone.

"Story" is obviously the most overloaded term because everybody thinks they know what it means. But between laymen, writers, game designers, and other game developers _and interactivity_, things get messy. (I believe that we are far from understanding how stories in games work.)

This definition just clears up a whole bunch of stuff. Whatever it is that happens as you play a game? As in, the thing Thomas was referring to? I just don't call that "story". More on that later.

"But Jurie, won't you need an awful neologism later on?" - Maybe. But this works for me now.

The "something happening to someone" is a crude attempt to distinguish it from world-building and backstory.

The whole confusion about "the story that you tell someone else about the game you played, afterwards" (as opposed to "the story as it happens" that I just mentioned): that just goes out the window. Because I think that kind of "story" is useless in the context of this discussion. It just confuses things. (Richard Dansky calls this "warstory", which, if you're going to call it something, is a great word.)

"Narrative" is a noun I won't use.

Awkwaaaaard. It's in the title of my GDC talk. As an adjective - phew! But I find it useless to distinguish between narrative (as a noun) and story. I've seen too many conflicting definitions.

I don't use it much as an adjective either, except for the nebulous "narrative design", which is what a "narrative designer" does.

"Narrative context" is a term I've used, as a vague synonym for "setting". I dunno.

Basically, I consider "narrative" identical to "story", and why not make things simpler and just use one word?

"Syuzhet" and "fabula" are words I won't use.

Uh…. here. Because while useful in principle, I just don't need them in this kind of discussion.

"Fictional" means "things I am asking you to pretend are true".

I hope it's obvious this refers to willing suspension of disbelief.

I originally referred to this as "imaginary", because I developed this theory in France in the 90s, and "imaginair" just sounds great in French. Less so in English. So, "fictional".

So this is the big difference between my standpoint and Thomas's. I think every game up to and including Tetris has a fictional side to it, but not a story. See this other quick blog post for my reasoning behind that.

(Note that in that blog post I talk about metaphors. I think this is kind of what Thomas means when he says a dragon comes with a ton of story. Metaphor is not an ideal word for that, but the amount of information you can convey by putting a dragon in your game is huge, and that's what I mean by that. And that's why I learned that lesson in casual games, where you have communicate very quickly, very succinctly, and to a very large audience.)

I used to call this, uh, aspect "story" instead of "fiction", but I found it necessary to distinguish between story and fictional. Because otherwise people get hung up going "where are the three acts in Tetris?" And it becomes hard to talk about story in a sandbox game with dragons versus in a highly scripted IF game, say.

And also it allows me to say, at the same time, that "story" and "game" are orthogonal, while "fictional" and "mechanical" are two sides of the same coin. And while preparing my GDC talk, I found that that was what I had to say, and in a clear and non-confusing manner.

So those are the words and definitions I use now. Maybe that will change. Ask me after GDC :)

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:

Lots of tiny parts

Web tech is many layers of simple parts adding up to a complicated whole. The individual parts are really quite simple, but it's when you're going RBDMS -> ORM -> Python -> JSON -> websockets -> JavaScript -> jQuery -> DOM -> browser that occasionally you start to feel light-headed. But it's all doable. I should probably say that every part is simple until it isn't, but it's astounding how many layers of tech written by strangers you can mash together into a working application.


The most important thing in web tech is your stack: the combination of technologies you use to handle user (meaning browser) requests in the front end (meaning in the browser or perhaps in a mobile app's UI) and the back end (on the server).

The original stack is LAMP: Linux, Apache, MySQL, and PHP. But while solid it's also a bit... old-fashioned. (Gameconfs uses Linux, whatever Heroku uses as a web server, PostgreSQL, and Python.)

Front end and back end

Front end and back end tend to use different technologies (unless you use Node and write JavaScript on the server) and skills, so they are often done by different people. Someone who can do both parts (like me) is a full-stack developer.

Front end developers often work with "designers", meaning graphic and UX designers. Web designers often use Photoshop. Some front end developers do web design as well (like me, although I'm mediocre at it).

This is why social game companies, which grew out of web companies, often have front end and back end programmers in their teams, and their game designers are often expected to do 2D graphics.

Stateless protocols are weird

HTTP is probably the most important protocol to understand in the web world. It's fairly easy to work with but the big mindfuck coming from games is that it's stateless, meaning that the protocol requires no state to kept between requests on either the client or the server side. Every HTTP request arrives in a fresh new world of possibilities. This has advantages: HTTP is simple, you can easily send HTTP requests to a different machine from last time (great for scaling), etc. But when I first tried to "quickly" store something in a global variable only to find out it didn't work, it hit me that I was going to spend a lot of time managing state myself. And so you get to cookies, sessions, and databases.

Databases are useful - who knew?

Your technical career may not be like mine, but I had sort of vaguely heard of relational databases yet never needed to use one or knew people who did (in PC and console games, in the 90s). Well, it turns out they're useful and even cool, especially PostgreSQL, which is kind of a beast.

I'd say start with an ORM (an Object-Relational Mapping, meaning a layer between the database and your programming language). But know that there are good reasons for eventually digging deeper and getting into SQL and really using the power of your database.

And of course the kids these days like to use so-called NoSQL databases, like MongoDB, Redis, etc. My opinion on these is that they are cool, but I have not yet had a problem that *really* required a NoSQL database, especially since PostgreSQL can handle key/value and JSON data. So I prefer using a tool I know and that has been around for a long time. But, as I will explain below, that is not the typical web tech way.

Lots of Linux and OS X

For historical reasons, web development, on the back end side, is very Linux-oriented. On the client side, OS X is very popular because it is historically artist-friendly *and* has a Unix inside, so you can develop both front end and back end software.

So get used to seeing a lot of OS X, and to some software not working or not being available under Windows, or being a pain to install.

I love this aspect of web development, but then I would say that, as I switched to OS X in 2003. And I've even slowly started learning about Linux system administration.

It's all online

It's all online. By definition. That might seem obvious, but in my experience game programming tends to be very conservative, and for a very good reason: at some point you had to compile that puppy onto a CD or DVD and then it was a major pain in the ass to make any changes. That is slightly easier now, but nowhere near as easy as on the web, where by pressing a single button you can route half of your audience to a different machine on a different continent where the software is written in a different language and nobody notices and *it's not witchcraft*. And by pressing a different button you can undo all that.

(And that audience often grows slower than in games too. Being able to do *real* MVPs, where you start with a dumb website and then scale up to potentially millions is very nice.)

Lots of languages

Because game-like performance is not the highest priority for web development, there is a lot more choice in languages, and most of them are interpreted. So web development can be done in PHP, Python, Ruby, JavaScript, Java, Clojure, Scala, you name it.

This has pros and cons. Pros: languages that are easier and faster to develop in than C++ *hugs Python*, much more choice, and you get exposed to a lot of different languages and programming concepts. I learned a lot about asynchronous and functional programming by working with Pythona and JavaScript.

Cons: Pick the wrong language and you'll have trouble finding programmers, or the right programmers.

Lots of open source

Most of the software you'll work with is open source. This is very different from game development on Windows, in my experience. The downside of this is that licenses matter, so you better be aware of those, and sometimes projects get abandoned and bugs remain unfixed. But that's not *that* difference from commercial software, and in open source you can (and I do) fix bugs that bother you and even get them included back in the original software.

New technology *all the time*

Everything changes really quickly, and new frameworks and tools are developed all the time, often per language. They all have stupid names: Capistrano, Desert, Rake, Mongrel, Pip, Rails, Django, Lettuce, Jasmine.

People tend to run towards the Next Cool Thing, which can be annoying and counterproductive.

Rapid development, scalability, then maybe performance

I am not saying performance is irrelevant in the web world. I am saying that many technical choices are made to make development faster and scalability easier, rather than code faster. E.g. Python is fast for a dynamic language, but not fast compared to hand-tuned C++. But it's easy(ish) to set up a nice coding workflow with Python (say) and to quickly deploy your code to a server in the cloud, and to add additional servers to your web application.

Performance is an issue, but perhaps more in terms of page load times or server responsiveness.

Different tools and practices

Automated testing and continuous integration are popular in the web world - I think more popular, or at least common earlier, than in game tech.

I think automated testing became popular because a) as someone pointed out, HTTP is *ideal* for automated testing because it forces a clean interface, and b) if you don't have a compiler checking for a certain class of bug, it's worth doing something else to catch bugs.

You now see continuous integration in game development as well. And rightly so because it's awesome. Of course, by now the web world has moved to continuous *deployment*. Which leads us to:


One big part of these different tools and practices is a concept called DevOps. In the Days of Old, server programmers would write server software, put it on a disk, put that disk in a capsule, put that capsule in a pneumatic tube, and send it to the IT department. The IT department would put that software on a server and curse when it crashed at three in the morning because it took up too much memory. Meanwhile the programmers were lying on a beach somewhere.

Slightly more seriously: DevOps means considering developing, deploying, and operating software as one whole. In practice, for me, it means there are awesome tools for automatically setting up AWS instances and loading my software onto it and telling me when it crashes.

A more official version is here. And if you want to read a cool story about continuous deployment from 2009, here you go. IMVU: it's not just creepy ads, they also have cool technology.

Front-end has workflows now

Maybe you've written an HTML file and a CSS file and even a JavaScript file at some point. That is now old school, the web equivalent of hand-assembling opcodes by the light of a candle made from the wax of your own bees. Hip kids these days write their JavaScript in CoffeeScript or some other -Script, or at least get the JavaScript linted and minified and concatenated using some tool like Yeoman or Grunt (stupid names, told you). Style sheets are written in LESS or SASS and then transformed into CSS. Just as you have package managers to manage software packages for your back end language (Python uses Pip to install egs, Ruby install Gems, Clojure uses a tool called Leiningen), you now have package managers for front end packages as well. One is called Jam, the other Bower. I rest my case.