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:

Atmosphere

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.

Homework

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.

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.

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.

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.

Chris Billows asked the following on Twitter:

@jurieongames Hi Jurie. What about Tetris / Match 3 games? What's the narrative there?

How about IF games? What's the mechanics there?

— Chris Billows (@Doc_Surge) January 9, 2015

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:

Also note that a lot of IF uses *no* game systems, or at least none that the computer intrinsically knows about.

— Jurie Horneman (@jurieongames) January 8, 2015

Hope that helps a little bit.

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

Gameconfs

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

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.

Diegesis

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.)

Interactivity

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.

Expression

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.

A quote from a Polygon article on Battlefield Hardline:

Polygon spoke with Hardline's Executive Producer and Vice President of Visceral Games Steve Papoutsis at E3. EA did not provide a response to recent follow-up questions about Papoutsis' answers.

"We did some research on the [internet]," Papoutsis said, "and we found out law enforcement have a lot of cool, kick ass stuff. These heavily armored BearCat-like attack trucks. They've got cool motorcycles. And they've got helicopters. They even have police planes. They have all this cool stuff depending on where you're at in the country. So they have some pretty awesome gear. And then like SWAT guys. Come on, who doesn't like all the stuff SWAT guys load up in? They look pretty sweet."

I find it incredible this person actually said this. This is a caricature of the bro game developer. If one presented this as satire it wouldn't be believable.

And yeah, I bet EA did not provide a response to recent follow-up questions, while Ferguson, Missouri is burning.

On June 18th 2012, so a bit over two years ago, I announced Gameconfs on Twitter.

I have never talked about Gameconfs on this blog (or elsewhere), so why not do so now?

Back in 2009-2010, as I was starting to do more business development at Mipumi, it bothered me more and more that there was no good list of game events to be found anywhere. Some industry press websites have one, but they were (and are) not very comprehensive. (I've written to one of those websites, repeatedly, about cooperating, and they never got back to me.)

Looking at my Pinboard history, I first started collecting information about a possible game event calendar back in 2010. Back then I tentatively called it "gdcal". I decided to actually build my own calendar in May 2012.

My goals for Gameconfs

I had (and still have) a couple of goals for the site.

First of all, I wanted to provide a free and useful service to people in the game industry, solving my own problem in the process.

Second, I wanted to use this project as an excuse to do some more web development. In 2012, I was creative director of Mipumi, and while I did more programming than the average creative director, I wanted to have a small project that I controlled and where I could apply a lot of the things I had learned about web development in my spare time.

As a consequence, Gameconfs could have been built simpler and faster. For instance, I could have just put up a public Google doc, or a page on this blog, or added every game event I came across to Lanyrd.

Gameconfs didn't really need a database and perhaps it still doesn't. But I wanted to use Python and learn how to use a real database, and so Gameconfs became a Python app getting event data from PostgreSQL. Right now, a dump of the entire database is about 87 kilobytes, so PostgreSQL is overkill. But I did learn a lot about web development, and that has been generally useful for me.

Third, I wanted to provide a high quality, consistent service with as small a time commitment as possible.

I've been paying attention to the web startup etc. scene for a while. I knew that while I wanted Gameconfs to exist, I wouldn't be passionate enough about it to make it a full-time project. I also couldn't see a reasonable way to make money from Gameconfs. So I was very careful to not put myself into a position where I'd have to choose between abandoning the project or doing work I didn't want to do.

This has had a big influence on the design. I want to do things as well as I can, as consistently as I can, or not at all. This is why I don't cover every possible event I could (more about that later). And it is why the data I collect per event is quite limited. People have asked me about adding submission dates or conference schedules, but that'd be a lot of work to do per event.

And before you ask: yes, I could use crowdsourcing. But crowdsourcing isn't free.

For one, it requires technical infrastructure. For the first year of Gameconfs, I couldn't even add or edit events directly on the site. Instead, I added the event data to a big text file, generated the database from that, dumped the database, uploaded it, and imported it into the live database. A bit cumbersome, but it worked.

Eventually, I added user management, creating / editing / deleting forms, data validation, database backups, etc. This is not the hardest thing to program, but it's not something you roll out after an hour's worth of coding either.

Extending this to support proper crowdsourcing would take a lot more work. I'd want to have multiple user roles, auditing so it's clear who changed what. I'd need views to make it possible to review recent changes and edit user roles.

Beyond the technical side, it requires some form of community management. And also some kind of forum somewhere where discussions within the community can take place. And community management takes time.

Gameconfs' dirty little secret is that I can ignore it for a few weeks or so before it becomes obvious that I've not been adding events. And while that's not something I do on a regular basis, it's nice to know that I can do that, in case, you know, I decide to move to another country, like I did last year.

What I learned making Gameconfs

The biggest thing I learned building Gameconfs, and what most people learn when they see it, is that there are a ton of game-related events out there.

It's been really interesting to see what's happening in countries I didn't know much about, or sub-sections of games I wasn't aware of. It has also given me trivia about game events to break the ice at parties, like that conference that took place on Christmas.

I also found that there are entire classes of events that I better not add to Gameconfs. Competitions, game jams, game-related concerts, tournaments, board- and pen-and-paper-related events: they're all not on Gameconfs, because there are other people who do a much better job tracking them than I ever could, and whose sites are better suited for it.

Andreas Zecher is more on top of independent game submission dates than I will ever be. The person behind Compohub tracks more game jams, and has a site that is better designed for it, than Gameconfs. So I link to them here.

The future

What's in the future? I've been talking to people about sponsoring the site, in a tasteful way, and that might happen at some point. Because while I've invested a lot of time, I've not invested any money so far. So getting a proper logo, or letting a real web designer go over the site, have been out of the question so far.

What I do next in terms of development depends on what people ask for. Because that's another thing I learned: the stuff I thought I'd need turned out to not be necessary.

So if you have ideas for features you'd like to see: let me know. Or, if you just like the site, let me know too, or share it with your friends and co-workers.

Here's to many more years of Gameconfs!

George Buckingham, aka v21, has written this really interesting reading list for game developers. I like it because it has a lot of material on it I don't know yet, and comes from a different angle than I tend to come from.

He asked for feedback (actually, argument) on Twitter, and so I replied, one thing led to another, and now I've compiled a very quick and decidedly non-comprehensive list to complement/extend George's. I've read all the books on here - some classics, such as the full MDA paper, are missing because I somehow still haven't read them.

Here is the list:

Greg Costikyan's I Have No Words & I Must Design: Toward a Critical Vocabulary for Games. Deservedly a classic.

Chris Crawford's The Art of Computer Game Design. Also a classic. I actually recommend reading everything Chris has written, even if you may not agree with everything.

Donald Norman's The Design of Everyday Things.

Donella Meadow's Thinking In Systems: A Primer (thanks Martin for reminding me of this).

L. Rust Hills' Writing in General and the Short Story in Particular and Thomas McCormack's The Fiction Editor, the Novel, and the Novelist, two books on writing written by editors, not writers, a crucial difference.

Those two books were recommend to me by my dear friend Mark Barrett, way back in the 90s. Mark is a very smart guy who has taught me more about storytelling than anyone else - stuff I'm still digesting to this day. I recommend reading some of his articles here.

Lajos Egri's The Art of Dramatic Writing was recommended to me by Hal Barwood. It may take years before I can tell you how it has influenced me, but influenced it has.

If you're going to read one book about classical story structure - three acts, five acts, a thousand faces, etc. - I think it should be John Yorke's Into The Woods, because it references and analyzes all the other ones.

Lee Sheldon's Character Development and Storytelling for Games, because Lee wouldn't forgive me if I didn't add it. And also it's a good book.

Jesse Schell's The Art of Game Design, probably the best general book on game design out right now.

Any game design by Robin D. Laws. I've learned something - specifically, something about how game mechanics and theme interact - from all of his games. As a Vance fan, I love his Dying Earth rules. I also recommend Hamlet's Hit Points, although I think you can probably get the gist of that just from reading the archives of his blog.

And last but not least, Scott McCloud's Understanding Comics.

There. It could be shorter. It could be longer. It could be more balanced - it's heavier on books and on storytelling than George's. But perhaps it's of interest.

Update: James Wallis also wrote a list. There's some overlap with this one. He has gone deeper into the screenplay books. I've read Syd Field's Screenplay but can't remember a thing about it. Save the Cat sits on my shelf, unread. I've read Hero With A Thousand Faces but I consider it more a psychology/anthropology book. I bought and read Impro on his recommendation and remember liking it, but it obviously didn't pop into my mind this morning, but please do not consider that to be a... whatever the opposite of an endorsement is.