Skip to main content

Some quasi-funny German text I wrote once

TL;DR: Only funny if you speak German. And even then.

A couple of years back I worked on a game concept set in an existing fantasy setting. The potential client was German so I wrote it in German. I wrote a little example of what the game would be like. This was not sent directly to the client, for reasons that will become obvious.

It began like this:

"Dingsbums Zweiarm ist ein Zwerg der Ersten. Seine Aufgabe ist es, eine wichtige Nachricht nach ab zu liefen. Er traegt der Axt von Langobart, sein Urgrossvater und grosser Held seines Clans. Zusaetzlich hat er eine Flasche Magiwurz und eine "Hilfe in der Not" Karte dabei.

Er wird begleitet von Grummdil Knonfuttr und Aroma, eine Halbalbin."

We didn't get the contract.

Update: My poor German is not the joke, you nose-bears. At least that is not what I am laughing at.

"A 440 432": A conspiracy theory

If you like a good conspiracy theory, I just stumbled upon a great one.

Modern day music is stuck in a tuning frequency that was implemented throughout Nazi Germany by propaganda minister, Joseph Goebbels in 1939. His implemented 440Hz codified a New World Order of central pitch that was instrumental in leading our world into a state of discordance. For this tuning of A=440Hz is inherently out of sync with the divine music of the universe.

It is also known that Hitler and his Nazi regime were fervent in their search of the Holy Grail's secrets in order to manipulate the masses and control the world. Their study of esoteric principals, use of occult powers, advanced technologies, altered states of consciousness, including that of sound and frequency only helped to satisfy their goals.

Recent studies have proven that 'sound entrainment' has been, and is still being used today to coax brainwaves into certain patterns of thought and mood, and in Hitler's case, martial music broadcasted in 440Hz aided in altering his people into an aggressive and unbalanced state.

(From a forum thread on David Icke's website - this alone should tell you you're not in Kansas anymore. Unless Kansas is infiltrated by lizard people.)

A simple Google search for "A 440 432", and what a nicely cryptic search phrase that is, leads to a number of other entertaining websites:

And much, much more. What a fun rabbit hole to fall into.

"Reverse innovator's dilemma"

I like explaining things to other people for entirely selfish reasons. I often find myself saying unexpected things, such as today, when I was trying to explain the state of the art in interactive storytelling to a friend, and found myself using the term "reverse Innovator's Dilemma". That seemed interesting enough to jot down, and perhaps even interesting enough to write a blog post about.

"The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail" is a classic business book by Clayton Christensen. Unlike some classic business books, this one contains a pretty useful idea. I say this never quite having finished reading it, as I recall.

Regardless! The idea is this: if you're building something that is high quality and expensive, your market may be destroyed (disrupted - Christensen started with the whole disruption thing) by something that is cheap and good enough, especially when that something can get better much faster than you.

So PCs disrupted bigger computers, MP3 disrupted CDs, downloadable games disrupted disk-based games, browser-based games disrupted downloadable games, etc.

My point in the discussion today was that some things - specifically, certain approaches to interactive storytelling - are so hard that it is almost impossible to get them good enough before you run out of time or money, although Chris Crawford is definitely testing that idea.

Is "reverse Innovator's Dilemma" a great term? Perhaps not. The classic diagram in the Innovator's Dilemma maps quality over time, it doesn't talk about development costs at all. "Local maximum" is probably a much better analogy for the situation in interactive storytelling. To add insult to injury, my casual use of "reverse Innovator's Dilemma" may hide a concept that is much more deserving of the phrase.

But I thought it was a fun thing to say, so there.

Metaphors and originality: the power of explosions

I was reading this interview with Bungie's Jason Jones on Destiny, and this bit really jumped out at me:

And then it evolved, as we evolved into sci-fi, because we felt the pure fantasy was missing all these things we loved. Literally, explosions. It's kind of a joke, but it's not really a joke. Explosions are awesome, just as a gameplay device and all kinds of other things. People understand them, they're a really easy metaphor for projecting power into the world.

There are two aspects about this quote that struck me.

First of all, metaphors are an incredibly powerful aspect of game design. Game design often (I would argue virtually always but that's an argument I'll try to make another time) involves melding mechanical aspects (rules) with fictional aspects into one coherent experience. Metaphors are the most basic and most powerful technique to do this. My personal hierarchy of interactive storytelling techniques goes something like: metaphors, world-building, actual stories.

(I'm not using the term 'metaphor' in a very precise way: 'analogy' would probably work as well. But most people roughly understand metaphor.)

Second, I've been working on mobile and casual games the last couple of years, and I really learned to appreciate and respect proven techniques, sometimes referred to as 'clichés'. Especially when we tried very hard to question, reinvent or abandon all well-known techniques in one particular project.

Using proven techniques often helps you understand and explain the game, which benefits players, the team, and yourself.

If you cannot explain the game to others on your team, you will probably encounter friction because it will be harder to imagine why it will be fun, and how you will build it. And really, that goes for yourself as well as for others on your team. "If you can't explain it to a six year old, you don't understand it yourself" and all that. (Although as any game designer knows, you can have a very clear vision and still not be able to explain it sometimes.)

If you cannot explain the game to players, and I would count the press as players in this case, you have a marketing risk. It's not impossible to make a successful game that's hard to explain, but it's a lot harder. And these days every developer should think more about marketing. (I always hated the demand to "explain your game in one line", but I changed my mind as soon as marketing became something I had to think about myself.)

(Should I mention that I think that players and developers learning what games are is how the medium evolves? Let's not put too many asides in parentheses.)

I'm not arguing you should use clichés, but that you should understand a rule (or proven technique) before you try to break it, and that originality purely for its own sake is a bad idea. (And those rules are themselves hardly original.)

In the context of having to ship a certain kind of game into the marketplace with a limited amount of resources, I prefer a risk-oriented approach to game development. Breaking rules you don't understand is risky.

Games are often criticized for being unoriginal. And it is not a bad thing to criticize: games are often unoriginal for bad reasons. But there are, in fact, good reasons why certain things, like explosions, come up again and again. (That doesn't mean they are essential, or that we will never find a better way.)

Update: In fact, after thinking about it a bit more, the power of metaphors and of proven techniques (patterns, elements) are probably two of the biggest things I've learned about games in the last five years.

Update: From the same interview (which I haven't finished reading yet):

And classes are a great short-hand so that when I look at you, I can have some expectations about what your abilities are and how you're likely to behave in the world, and what kinds of things I might depend on you to do, and a lot of games have done this very successfully. I would say that one of the origins of class is that it gives people some way to look at each other and talk about their abilities without actually talking.

Remember, this is one of the best and smartest studios in the world, who have enough money and creative freedom that they designed an entire fantasy universe then threw it away. (I was at their GDC art lecture, it was crazy to see all the art they did only to then go "Naaaaah let's do science fiction". Because of explosions.)

Also the classes they have, while not groundbreakingly original, are already different from the classical Holy Trinity that people have been talking about changing for 3 decades.

It's not impossible to use something else than the classes Bungie picked. They have constraints and biases others might not have. They have to please an enormous amount of players, including their own fan base, for one. But there are some good reasons why Bungie chose this approach.

On Albion And Avatar

We recently watched the ultra-long cut of James Cameron's Avatar on Blu-Ray, and I was again reminded of a) how much I like the film, and b) what a striking resemblance it bears to Albion, the PC role-playing game I co-wrote in the mid-nineties.

I googled Albion and Avatar and Google suggested "Albion vs Avatar" and "Avatar ripped off Albion", which was kind of cool. The hits were all comments from people who had played Albion, often in articles listing all of the other works Avatar supposedly ripped off. For what it's worth: I don't think Cameron "stole" from Albion at all, although it'd be interesting to know if he ever played it - it's not impossible.

I am going to write about the similarities. Most of my memories of Albion are from 1994-1996, so details may be cloudy or even plain wrong.

Both Albion and Avatar have a big spaceship from Earth, owned by a big corporation and with the purpose of extracting resources from far-off planets. The corporation in Albion was called DDT, which originally stood for Daihatsu-Daimler-Thomson, but which we bastardized a bit to avoid lawsuits (as if). Ironically, both the look of the spaceship interior and the big evil corporation trope were probably partly inspired by Cameron's Aliens. In Albion the spaceship is called Toronto. I have no idea why, although I think I came up with it.

In both Albion and Avatar, rotation is used to simulate gravity. Erik (Simon, co-designer of Albion) argued that if you can create artificial gravity, you can probably do a whole bunch of things that would preclude the kind of world we were building. But we wanted to have the spaceship land on the planet's surface, I think because otherwise we couldn't plausibly stop the threat at the end of the story. (Cameron found a different solution, although one that may turn out to be temporary in the sequel.) So I came up with a structure that could rotate in space and then unfold like a flower (hence "Daisy class") and land on a planet's surface and all the floors would remain floors. It probably wouldn't work at all.

In both Albion and Avatar, even though the expedition is run by a big corporation that is in it for the money, there is a small representation of people with different, nobler goals: scientists. In Albion, every spaceship had to include a governmental scientific team, and of course planets with certain characteristics - say, alien life forms - could not be exploited.

Surprise! The planet in question, while absolutely filled with valuable resources, is not barren at all and inhabited by intelligent aliens. This information is hidden from the scientific team. They fly down on a routine check and then have an 'accident', thus starting the adventure. Avatar's conflict and plot are much, much better than Albion's.

The local aliens are tall, cat-like, have long prehensile tails and use spears. They have bits in their foreheads which they use for magic and which enable them to commune directly with others. So that's quite similar. Unlike in Avatar, the female aliens in Albion have four breasts, and only partially cover them:

Albion Iskai

Two whole nipples! If you're going to make a game in Europe, you should use any advantage you get. Funnily enough, this was never an issue for the US version, even though typically we'd be asked to make things more aggressive and war-like and remove any hint of sex. Perhaps because at this time Blue Byte was doing its own publishing in the US, although they'd still need to deal with big retailers? I don't know. It's more likely nobody noticed and the game was never that popular.

The US cover (swiped from Mobygames) shows the similarities with Avatar quite nicely:

Albion cover

Alien world, cat-like, tribal alien, spaceship. This image was actually commissioned by Ubisoft for the French release of Albion. I have no idea who made it. Blue Byte then used the image for the US and Korean versions, because it sure beat the German cover which just had the logo on it. And later Ubisoft bought Blue Byte so they now own the rights to the game. Although given that it can be downloaded for free they don't seem to be doing much with it - not that I'd expect them to.

The main storylines of Albion and Avatar are quite different. Avatar has a super-tight plot. Albion is a bit more rambling. I didn't realize this at the time until I started talking about it with Mark Barrett, a friend who is an actual writer. He mentioned Albion's story was more of a picaresque than he expected. That surprised me, but he is right. The protagonist's goal is to get back to the Toronto to warn everyone they're making a huge mistake, so he'd want to travel as directly as possible and not dawdle or explore, and so the story is a pretty linear string of exotic and increasingly difficult - this is an RPG, after all - locales.

There's a big mismatch between the premise of the story and the demands of the genre. Visiting one place after another, rather than deepening the meaning of a few locations, is a weakness in many video game stories. Thinking back on it now, we could have solved this and given the game a more interesting structure and a deeper story. But we probably couldn't have solved the tension between a ticking clock, must-save-the-world premise and a game genre built for exploration. Ironically, this same tension was a big reason why I stopped playing Oblivion, many years later. Our decision to have a fixed protagonist, rather than a player-created one, similarly came from our desire to have "more" story.

The other big, big difference between Albion and Avatar is that on Albion there are humans living on the alien planet. And this ties into what is probably the single biggest source of influence on the game's story: me having read Marion Zimmer Bradley's Mists Of Avalon shortly before work on the game began. (Harriet = Morgaine by the way: small, dark-haired, knows magic. Oh, and the three main characters are called Tom, Dick the AI, and Harriet. Placeholder names that stuck.)

The Celts are on Albion's alien planet because they were being pushed away by encroaching Christianity (like in Mists Of Avalon), and they disappeared into the mists, which I believe corresponds somewhat with Celtic mythology - walls between worlds being thin etc. Only this trip was a deal between two planetary consciousnesses, which is another similarity with Avatar. Only Cameron has a neat scientific explanation for it, whereas we just stated it as fact - it was probably inspired by me reading Giraud and Bati's Altor series.

(Regarding those Celts: I've explained earlier why we named our game Albion. We had a Celtic dictionary and a book on Celtic myth and that was pretty much it in terms of research. In 2008, I befriended a Celtologist in Vienna who was a fan of the game. I once asked him how bad our Celtic influences were, and he politely refused to comment.)

I hope that was vaguely interesting. Albion is available on Abandonia, among other places. You'll need to find a DOS 486 emulator somewhere too.

An idea for writing web games in Python

Here's an idea that popped into my head last night: What if you had a framework that allows you to write a game in Python as if it were a local game, only it runs in your browser?

To make it simpler, let us assume this game is turn-based and features few if any graphics.

That might seem a big restriction, but think about Candybox and A Dark Room and Fallen London and Kingdom of Loathing. Fun games can be built within these constraints.

A framework like this would be ideal for prototyping turn-based online games (and guess what kind of game I am working on right now?). It might also be ideal as a way for people to get into game programming.

The framework

For the simplest version let us further restrict ourselves to single-player games with no time-based aspects at all. So time advances because the player performs an action. This allows us to avoid doing real-time, in the web technology sense of the world, which is a bit tricky. The server can always just wait for the player and never needs to push anything to the browser. This is a big restriction but it makes for a good base that can be built on later.

So then all we would need is to design an API that resembles how you would write a game "as if it were a local game" and translate that into web technology. The two big things that API would need to handle are graphical user interfaces (GUIs) and game data.


For GUIs, one part is a simple system to handle screens, UI elements (buttons etc.), and layouting. The system generates HTML behind the screens and sends that to the browser, a bit like a GUI API generates graphics and sends that to the user's screen. More complex UI elements (e.g. tooltips) will require some Javascript but I'd say that's more work but not a major impediment.

The other part is mapping URL-based event handling to the button-based event handling you'd expect from an offline game API. You register or otherwise create a button, passing the function that should be called when this button is clicked (much easier than event binding IMO). The system generates a URL for this button, or however it wants to handle it, and takes care of the rest.

The classical game loop then becomes a very simple function the user writes which gets called when the next turn starts. Of course the next turn starts because the user told the system this has to happen. The player sees an 'End of Turn' button, clicks on it, the button handler calls a 'next turn' function, which then causes the 'game loop' to be called. Perhaps that appears cumbersome but it sets things up nicely for the next step which is to allow the server to push to the client.

To do that, you need some additional technology, namely realtime or push. ("Realtime" is confusing in this context because we're still talking about turn-based games, but it makes sense in a web context.)

Armin Ronacher, the creator of Flask, my Python web framework of choice, writes about that here. I've not done a lot of stuff with realtime web technology and I've certainly not thought through how to use it in the context of this game system, but right now my gut tells me it's doable somehow.


Handling data is interesting because of the amusing fact that on the web, the computer forgets everything after you talk to it. There are really good reasons for this, but it can be a bit challenging if you move to web development from other programming areas.

Anyway, I'd try to make it so that data automatically gets saved after each web request. A little layer on top of a typical ORM should do the trick: Basically, commit a transaction at the end of each request. Perhaps I am being naive.

Player and game session management could be built into the system.


What would be the advantages of such a system? People can use Python to write games. Python is my favorite programming language, so it's a big plus for me. But Python is also pretty easy to learn, which is a plus.

It's not so hard to imagine a system allowing people to instantly distribute these games on the internet.

The API would be simple - simpler than Unity3D because the games are more restricted, which is a good thing in my opinion. Also simpler than doing this with, ahahaha, 'bare metal' web technology. (I started this blog post with a rant about using Ruby on Rails to learn programming, but it grew too big.)

To sum up: this hypothetical system would make game programming easy to learn and to distribute, for a restricted but interesting set of possible games.

So what do you think? Stupid? Interesting? Boring? Already done? Way harder than I imagine?

Update: I should add that any HTML-based game has to kinda do what I am describing here, and conceivably although not necessarily, they've built systems that resemble non-web-game APIs. But I don't know of any such framework that is available for others to make games with.

Where to eat or drink in Vienna

Putting this here for future reference. Part of a series - see this.

Without further ado:

Zum Weissen Rauchfangkehrer
Pricy, Austrian, very good food
Weihburggasse 4, 1010

Pure Living Bakery
Great US-style coffee place
Burggasse 68, 1070

Die Burgermacher
Best burgers in Vienna
Burggasse 12 1070

Glacis Beisl
Breite Gasse 4, 1070
Good Austrian food, reasonable prices

Very good sushi
Ungargasse 6, 1030

Cute French tea salon
Operngasse 30, 1040

Cha No Ma
Japanese tea
Faulmangasse 7, 1040

One of the best Italian restaurants in Vienna, reasonable prices
Mayerhofgasse 22, 1040

Indien Village
One of the best Indian restaurants in Vienna, reasonable prices
Hohenstaufengasse 7, 1010

Taste of India
Good Indian food
Margaretenstrasse 34, 1040

Daniel Moser
A Viennese cafe with decent coffee (rare)
Rotenturmstrasse 14, 1010

A traditional Viennese cafe with nice food
Michaelerplatz 2, 1010

Tiny hole in the wall place with maybe the best coffee in Vienna
Favoritenstrasse 4, 1040

Dino's American Bar
Best cocktail bar in Vienna
Salzgries 19, 1010

Very good cocktail bar
Esterhazygasse 33 (in the Fuerst Metternich Hotel)

Update (September 2016): As I write this, I haven't lived in Vienna for 3 years. I go back about once a year. To the best of my knowledge, all places above are still open and haven't changed.

Laid back Vietnamese restaurant with good French pastries for dessert.
Lindengasse 35, 1070

Another very good third wave café in Vienna.
Zollergasse 5, 1070

Best croissants in Vienna - better than those in Lyon! Good coffee.
Downstairs in the Schottentor metro station, 1010

Unity3D for teams of 6 people or more

I've done this rant live to various people, but I thought it was time to write it down.

First of all: I like Unity3D. I sincerely think Unity3D existing makes the games industry a better place.

But, basically, I don't see how it can be used for efficient, professional game development, with teams of 6 people or more all actually using Unity. I'm sure people are doing this, but I'd like to know how.

This rant is based on my experiences on a project that used Unity 3.5. Maybe Unity 4 is better. It was our first Unity3D project, but to be honest we spoke to a lot of other Unity developers and if there were any major rookie mistakes we made I don't know what they are.

Final caveat: It's been a while since I've gotten my hands dirty on this, plus I wasn't the one who set up the project, so I might get some details wrong.

We used Unity3D with Perforce, with a team of 6 to 8 people, most of whom had to work within Unity itself, as opposed to just making bitmaps or something. The daily workflow for pretty much everyone on the team was:

  • Check out everything in the Unity folder in Perforce. Not 'get latest'. Check out.
  • Open Unity3D.
  • Do your work and test it.
  • Save, then quit Unity3D. You must do this.
  • Go into Perforce, reverse unchanged files, then try and guess if any files, particularly all of those tiny .meta files, have been added or removed and tell Perforce about those.
  • Repeat.

Unless you want to change a scene, then you must yell through the office that you're going to change a scene, lock the scene file, then do all of the above. So this was pretty much like not having a repository. We had things set up so scenes and other data are text files, but to be honest, just because it's now YAML doesn't mean you can just merge scenes - all those internal references don't necessarily match up.

That's a pretty sucky workflow, and it took us a while to get it through everyone's heads that they really, really had to do all this. I personally suspect - I never investigated this - that we had to quit Unity because of one plugin that saves important files on exit. But to be honest if that's the case I still see that as a design flaw in Unity.

So, internet: what did we do wrong? What are your experiences with Unity3D and teams of more than a couple of people? We did not use the Team License - could that have solved our problems, and if so how?

The three most common techniques for telling stories in games

Mainstream games, or at least a significant subset that I’m too lazy to define here, make use of three big techniques to tell stories:

  • Cut-scenes.
  • Invisible boxes.
  • Environmental storytelling.

I think both game developers and players understand these techniques by now, and in fact I think players are getting tired of them. I know I am. And that means it is time to surprise people again, to innovate, by moving beyond these tools or by using them in new ways.


Cut-scenes are the most conventional and, perhaps not incidentally, also the most controversial tool. We’re splicing another medium, film, into our games. It is an effective medium to convey information and evoke emotion. Players and developers both understand cut-scenes, important reasons for their popularity. The effectiveness of cut-scenes balances out the fact that they are not interactive, and therefore tend to break immersion and take away agency. But it’s an uneasy balance. Cut-scenes, by definition, do not fit well in an interactive medium.

Over the last 20 years, innovation in cut-scenes has been about technology (how complex a scene can we show), production (how do we economically make more complex cut-scenes) and filmmaking craft (how do we make effective cut-scenes). There has been almost no innovation in the interactive aspects of cut-scenes, and this is to be expected since cut-scenes are pretty much defined by not being interactive.

(I classify dialogues as cut-scenes for the purpose of this article. How to do dialogue better or make it more interactive is beyond the scope of this blog post. People tried cool stuff in the 80s and early 90s, we did some reasonable things in the role-playing games I worked on, by now people have kinda stopped trying to invent new things, at least in AAA. I haven’t played enough Mass Effect or Skyrim to have an opinion on how they did, but I didn’t get the impression it was groundbreaking.)

Invisible boxes

Invisible boxes (or planes, spheres, volumes, etc.) are the tool that level designers use to trigger events. When you walk around a corner and a ceiling collapses, enemies come running towards you, or some characters act out a little scene (just out of your reach), then you just hit an invisible box. When you’ve seen them once, you see them everywhere.

And that is the problem. As a player, you develop a sense for these things. You know stepping into that big room or walking around the corner will trigger something, just as you know that if you just stay there, nothing is likely to happen, forever, except for the eerie and foreboding music. (The tendency for games to get stuck, when nothing happens because the player isn’t doing something, is a big immersion breaker.)

Invisible boxes are used to orchestrate events just so for the player’s enjoyment, to make sure she meets the right challenge at the right time, sees the right thing at the right moment. They are an easy tool to understand and to use, although hiding them requires finesse.

But they can never be fully hidden. At some point, the player realizes that the world arranges itself around her, and then the reality of being on a well-orchestrated ride dominates the illusion of being inside the fictional world of the game, and her behavior changes. She knows what to expect.

Invisible boxes are stupidly easy to implement, so there has been no innovation here for decades. We’ve become more sophisticated in how we use them, but the scripts in the games I wrote in the early 90s are conceptually the same as the scripts in current games.

Note also that invisible boxes are orthogonal to interactivity. We can use them to orchestrate spectacles, but they are not inherently interactive, they do not in themselves create or enable interesting choices for the player. In fact, they are often used to trigger or to artfully replace cut-scenes. Characters talk or interact in real time, scientists are drawn into ventilation shafts, but in such a way that the player doesn’t notice that she cannot interact with them.

Environmental storytelling

Environmental storytelling is telling a story through a game’s environment, specifically a story about what happened before you arrived in said environment. I believe the term was coined by Henry Jenkins, but I’m not an academic so I’m not going to research it. I first saw it used in System Shock. Remember finding those little cubby holes with a corpse and some empty food containers and recordings telling increasingly bleak tales of the bad stuff that happened before you arrived? Well, that was kind of the best use of that technique, and it’s been used more or less like that ever since. It was used well in Portal and Manhunt. It’s a useful technique, but limited. I recently saw a blog post critiquing the diaries and recordings in Bioshock 1 or 2. I surprisingly felt a bit disappointed at the start of Dishonored when early on, in the sewers, I found a little cubby hole with a corpse and some empty food containers and letters. I remember thinking “Oh no, it’s the 90s again.” For all I know it was a homage. Dishonored is great, you should play it.


These three techniques have a number of things in common. They’ve been used a lot over the last 20 to 30 years, especially in ‘mainstream’ AAA games. Players understand how they work, they’ve learned the conventions. Developers understand how to use them, and have refined them over the years.

And there are signs that people are getting tired of them. I’ve got a whole different blog post on a back burner somewhere about techniques and gimmicks and genres. I don’t have an opinion why this is happening, whether people just get tired of any technique. Maybe they do. Maybe you can see this when you look at the evolution of TV and cinema and comics, how things are rebooted and reinterpreted. But I claim it’s happening.

Finally, none of these techniques are very interactive. Only invisible boxes can claim to be somewhat interactive, in the sense that they react to the player.

(Just a few days ago I read this profile of Mohammad Alavi in Edge:

Once more, Alavi charged into the wilderness alone, eventually writing over 10,000 lines of scripts that anticipated every way the player might disturb or be noticed by the patrolling soldiers, handling each case with different animations and behaviours. "It was crazy and jury-rigged together, but the end result is that you can enter the situation from any angle and it's legit — if they thought they saw you from a certain distance, they'd behave differently than if you popped up right in front of their face."

So maybe you can do some cool stuff with invisible boxes if you’re crazy. But they rewrote his scripts and turned it into proper AI.)

And I believe this shows that all of the current techniques we currently have are smoke and mirrors. Well-executed, cunningly used smoke and mirrors, perhaps. But we’ve taken things that we as developers understand and that our players understand, and have tacked them onto games. We’ve taught our players how to overlook the joins and seams, that we all know are there. And we’ve taken this as far as we can. Now the end is in sight. We’re close to not being able to do better, to not being able to afford to do more, and players have caught on to us.

We’re on a local maximum, a beautiful hilltop where things are great, but any movement leads downward. And that’s scary, because that means we have to leave behind what we built, pack a small backpack and trek through the wilderness to find new beauty. And we only have a vague idea of where to go. Some of us won’t make it.

I’ve been thinking about storytelling in games for a long time, since before I became a professional developer even. For years I chased immersion and used the techniques I described above. But I knew there had to be more. Now I am seeing hope, in games like FTL, in Spelunky, in Rebuild, in Dwarf Fortress, perhaps in Minecraft. It’s not the discovery of something blindingly new, but more suddenly looking at things in a different way. (And then seeing a trail leading from these games back in time to older games. It was there all along.) I don’t know where this trail will lead. I’m sure it will be different from where we were before. I can’t wait to find out.

Why we called our game Albion

Some time in 1994 we (the Albion team) were thinking of a name for our new role-playing game. We knew it would involve Celtic culture somehow. As well as spaceships and aliens, of course.

Some of my personal criteria for game titles were:

  • It's nice when a game’s title starts with an "a", because then the game shows up at the top of alphabetized lists.
  • It's nice when the game’s title is not truncated by the operating system. Albion was a DOS game, so it’s nice to have a name of eight characters or less.

However. Albion started off as an Amiga game, and Amiga’s operating system allowed longer filenames than DOS. So either we came up with the name after we made the decision to switch to DOS (because Commodore had gone bankrupt), or we were just lucky in this regard.

So someone, maybe me, came up with "Albion". We didn't know what it meant, but we knew it sounded vaguely Celtic. As this was before we could have looked this up on Wikipedia or Google, we had no idea Albion meant England… In retrospect it’s a weird name that creates associations that have nothing to do with the game. This is probably how Japanese developers pick names all the time.

Anyway, that's how we came up with the name.