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.

GUIs

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.

Data

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.

Summary

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

Benkei
Very good sushi
Ungargasse 6, 1030

Suessi
Cute French tea salon
Operngasse 30, 1040

Cha No Ma
Japanese tea
Faulmangasse 7, 1040

Sebastiano
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

Griensteidl
A traditional Viennese cafe with nice food
Michaelerplatz 2, 1010

Kaffeefabrik
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

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

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

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.

So?

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.

A rant about games and how they’re perceived

Last night I had a discussion on Twitter with Luke Dicken about game definitions, and why they matter. It reminded me of some strongly-held views I’ve had for some time about attempts to place games in a larger context: art, society, culture, et cetera.

I don’t care if games are a legitimate art form, medium or whatever. I don’t care if they have a pedigree going back to 1971, the 50s or the 18th century. I don’t care if they’re older than the novel, older than writing. I am not convinced, nor do I particularly care, that computer games are direct descendants from board games, children’s games or play in general. I don’t care if animals used play to learn before humans learned storytelling to transmit knowledge. I don’t care if play is an essential part of human culture.

If someone were to convincingly prove that computer games are not a legitimate art form, I’d still be making games. If someone could convince me computer games were a trivial hobby, I’d still be making games. If computer games were not derived from something else, if they had been invented ex nihilio, out of whole cloth, sprung fully formed from the brow of Nolan Bushnell or whoever, I don’t care, they’d be even more miraculous.

What unites most people making computer games is their passion. We want to make games. We know how to make games. We strive to make better games. But it makes absolutely no difference to me where we fit into other people’s questionable value systems. Fuck ’em if they don’t get it; they will die out anyway.

If we have to play power games to protect our medium, if we have to argue that games have cultural value in order to gain legal protection or subsidies: why not, it needs to be done. But let’s not mix that discussion with actually making games, with making people happy, with evoking emotions and giving people means to express themselves which are fundamentally new.

We’re working in the newest and most exciting medium in the world. That doesn’t make it a ‘better’ medium – I don’t even know what that means. It doesn’t make our lives easy. It doesn’t mean we bear less responsibility, that we don’t need to work hard to do better every day.

But it is a good thing, no matter what anyone else thinks.

Pushing ideas to different parts of your brain

A couple of months ago The New Yorker published a profile of Hilary Mantel by Larissa MacFarquhar. I found this paragraph particularly interesting:

When she’s starting a new book, she needs to feel her way inside the characters, to know what it’s like to be them. There is a trick she uses sometimes, which another writer taught her. Sit quietly and withdraw your attention from the room you’re in until you’re focussed inside your mind. Imagine a chair and invite your character to come and sit in it; once he is comfortable, you may ask him questions. She tried this for the first time when she was writing “The Giant, O’Brien”: the giant came in, but, before sitting down in the chair, he bent down and tested it, to see if it would take his weight. On that occasion, she never got any further, because she was so excited that she punched the air and shouted “Yes!” But from then on she could imagine herself in the giant’s body.

This reminds me of the Rubber Duck debugging technique:

The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

Peter Reiterer, a programmer I work with, occasionally uses this technique. (I myself have used a similar technique but using a graphic artist instead of a rubber duck. I have not compared the two approaches but my method is also quite effective, if perhaps more boring and confusing for the participant.)

The way he explained it to me, or rather the way I remember his explanation, is that this technique forces you to express thoughts and then absorb them again through a different part of your brain, and this allows you to see them in a new way.

I always thought the mere act of expressing your thoughts to someone (or something, I guess) forces you to reorganize them and in the process discover new insights. A bit like learning by teaching, and incidentally the reason why I do public speaking or write blog posts. The difference is subtle and I can’t think of a way to test which explanation is better.

But the interesting thing, to me, is seeing two techniques to unblock yourself, to get a new perspective on things, that involve forcing a different part of your brain to interpret something. Of course it’s just me saying that is what’s happening in Hillary Mantel’s head, and I am not a neuroscientist. I don’t know for sure if she is using two different parts of her brain: this is just my intuition.

After discussing this with my wife it struck me that prototyping is similar to these techniques. It is easy to imagine a logical, abstract structure for a user interface, but once you visualize using it in your head, or, even better, prototype it on paper, you see it in a different way and can perceive things you couldn’t in your abstract model.

Of course, this raises the question: does prototyping work because you’re perceiving something using a different part of your brain? Or ‘merely’ because you’re seeing an approximation of the real thing? It is unlikely that I can better understand a game design idea by using, say, interpretative dance.

Food for thought, perhaps. Can this approach be generalized? Can we express, transform, and re-experience our ideas in other ways?

Game definitions and the designer’s toolbox

When you hear someone say “that’s not a game,” they usually mean “this is not what I was expecting from a game”.

Game definitions are like tools. You need to get something done, so you open your toolbox, pick the right tool, and then use it. As a craftsman, you care about your tools, you polish and clean them, you try to make better use of the ones you have, and judiciously add new ones to your toolbox, all in service of the craft.

A game definition based on Huizinga’s magic circle allows me to do different things than a game definition based on Crawford’s toy/puzzle/game taxonomy or Costikyan’s resource-based definition. All of them are useful, they all make sense and are ‘true’. But each operates in completely different perspectives.

And this is the value of a varied and well-selected set of tools. They allow you to look at things from different angles. When you have a screwdriver, you look for screws, for things to open.

Similarly, when you’re using the magic circle perspective, you might be thinking of how playing relates to non-playing, how people can be drawn into a magic circle, how their behavior can be changed, or how you can draw attention to their behavior by manipulating the magic circle.

When you’re using the toy/puzzle/game perspective, you might be thinking of player goals and replayability. Do you give explicit goals to the player, or do you let them select their own goals? Is the game about figuring out a problem and then moving to the next one, or is it about dealing with an opponent or a complex system?

Costikyan’s definition of game draws your attention to resources and allows you to design independent of whether you’re working with cardboard and tokens or on a computer. It makes economics applicable to games.

A final perspective – I hesitate to call it a definition – is that of ‘it’s a computer game because it looks like a computer game’. Here we get games like Proteus or Dear Esther. They are sold and discussed alongside other games. They contain 3D worlds we can navigate through. They don’t have a ‘serious’ purpose – they’re not email clients. Note how none of the previous definitions of games said anything about navigation in 3D worlds, or any kind of navigation or worlds at all. Yet the representation of and navigation in worlds is an unspoken assumption underneath a lot of people’s idea of what a game is.

The toy/puzzle/game taxonomy is the clearest about games like Proteus and Dear Esther. In this system, seen from this perspective, these games are toys. This helps me understand them. It makes them tractable, understandable, ‘known’, even before I play them. This doesn’t mean they’re boring or predictable: just that I can recognize them from a certain perspective.

Game definitions are tools, and knowing your tools well, understanding their differences and their strengths and weaknesses makes you a better designer. In the case of mental tools, knowing exactly which tool you’re using is perhaps one of the most useful things to learn.

Game definitions can also be used in a rhetorical way, as a form of argument. This is always about power, and thus political. I define games this way, therefore your game is not a game and thus you lose power. I define games this other way, therefore games become more worthy than your medium and thus you lose power. I define games like so, therefore it should not be a part of your department and I get to raise my own funds.

There is nothing inherently wrong with rhetorics, politics and the use of power. But it’s important to distinguish between politics and the truth inside your toolbox.

Andy and Jurie are looking for jobs

TL;DR: Game designer Andy Schmoll (profile) and grizzled veteran developer Jurie Horneman (profile) are looking to move to an English-speaking country in the near future. Hire us while we’re hot!

Continue Reading »