Sunday, 29 May 2011

Battle for Venga Islands Post Mortem...

So, the game has been out for a few days now, and I've some chance to reflect, I figured I'd write down some notes.

The Good

As a pretty mature technology, there are a lot of libraries that people have created for XNA game programming.  This is wonderful.  I love using stuff that other people have made and provided for free.  I'll even modify my own game design vision if I can find free tools that are cool enough to lead me in another direction.

When I first started playing around, I tried to implement Andy Shatz's lighting algorithm, with only moderate success.  I was never really able to able to get it working 100% (my own fault).  I soon after discovered the Krypton Lighting Engine, and immediately thought it was a better choice for my purposes.  It was simple enough to conceptualize, but powerful enough to perform well and do what I wanted.  My game isn't very light/shadow intensive, but it added some cool effects.

I also used the Mercury Particle Engine again, and will always continue to do so.  There's absolutely no reason I can see for anyone to ever write their own particle engine while this thing still exists.

I also used Renier Prokein's character sprites, and am amazed at how much awesomeness he has just given away for free.  Love it.

And finally, the key to the whole project was using the fantastic Spyn Doctors high score sharing component.  This is an extremely well done peer-to-peer data sharing component, with nice documentation and example implementation (for sharing high scores).  This is the backbone to the game.

When it comes right down to it, the game was kind of an experiment.  Was it possible to do a persistent peer-to-peer world?  A massive p2p structure isn't really something you can test on your own little network, either, so I did a lot of visualizing and thinking rather than coding and testing.  I'm pleased to report that it works perfectly.

Releasing the game was a thrill, because the high score list started out blank, and the map started with default positions captured.  But as time passed during release day, the high score list started filling up, and regions started being captured.  In fact, with so little data per transfer, you could see people responding to previous captures, trying to head them off at the pass and so forth.  With "Bad Golf", I had to wait a couple days for feedback, so it was neat to see people actually playing the game.

I'm also pretty pleased with the actual gameplay.  I like the four weapons, and think they have distinct strengths and weaknesses.  The enemies are ok, but maybe not varied or interesting enough.  Initial testing indicated, though, that the gameplay was fun and addictive, and some of the high scores bear that out (you simply can't play the game over 500 times if it's really that bad, right?)

Adding the health drops were a late change, and I though they added a fun decision point.  Go for the health that's in a dangerous place, or stay safe?

I was also put in touch with a student musician, and was pleased by the music he created for the game.  My boy Eryn also created a really nice loading image for me, which was awesome.

The Bad

After enough time passes, I simply lose motivation.  The map data has things like elevation and biome type, and it would have been great to have more varied environments to fight in.  I sufficed to change the background color of the ground, but that's it.

I also didn't realize how locked up the map would be once all the regions were full.  New players were entering the game with only "Difficult" and up regions available.  I wish I did more testing to realize that would be the inevitable result.

The reviews that I've read are pretty spot on.  The game is good, but not great.

The Ugly

When writing the game, I didn't take any measure to data security.  Spyn Doctor even warned me that my data files might be at risk, but I ignored his advice for security.  I figured that if my game was popular enough to get hacked, then I was ahead of the game anyways.

So when it actually happened, when I woke up to see a high score of over 19000, I was surprised by my emotions.  I was upset and pleased and happy and angry all at the same time.

I also released the game right at the end of a big list freeze, and also just before some other big names were dropped onto the New Releases list.  So that timing wasn't optimal.

The Future

Given the success of the peer-to-peer persistent world, I'm encouraged to try something like that again.  I'm also excited about my upcoming 1.1 patch that will fix some of the above problems (data security, difficulty issues), and I'm just sorry it wasn't part of the initial release.

In the end, I'm pleased with the game.  I had secret hopes of it being a huge cult hit, but I'm happy that it all worked as well as it did.

Saturday, 28 May 2011

Monsters Unleashed V.1 is... ummm, Unleashed

Monsters Unleashed V.1

Monsters Unleashed V.1 is the first release in an exciting line of short monster supplements designed to update a host of 3.X monsters to the Pathfinder Roleplaying Game ruleset. The monsters for this series have been selected by the patrons of the Monster Update Project that was launched by Purple Duck Games as our premier product of August 2010. All patrons of the Monster Update Project will receive all the Monsters Unleashed releases for free. If you are a patron and you have not received your copy, please check your email preferences at this site and contact me at

The first Monsters Unleashed features updated statistics for the barrow wight, crystalline horror, devil dog, dragonnel, kech. All have been updated to the Pathfinder Roleplaying Game ruleset by Stefen Styrsky and Mark Gedak and illustrated by Michael Scotta. Multiple counters for each creature are also included.

Pathfinder and associated marks and logos are trademarks of Paizo Publishing, LLC, and are used under license. See for more information on the Pathfinder Roleplaying Game.

Available at Rpgnow

Friday, 27 May 2011

Time Lapse

One of the big bummers about the XBLIG platform is that trial games can't join network sessions.

The real selling point of Battle for Venga Islands is its online map, and you don't really get a taste of that when you download the demo.

I don't have a good way to doing time lapses, unfortunately, but I set up my camera on a tripod and took a picture every couple of minutes, to give some sense of what happens in the game.  It's totally budged, but I hope the idea gets across.

Tech feature: Scripting upgrade

For a couple of months now I have, on and off, worked on some basic tech aspects for the engine. Everytime I was done with one of these I thought it was among the hardest things I would do for the new engine, yet the next feature as always proved more challenging. Terrain geometry was harder to implement than sun shadows, terrain texturing harder than geometry, and so on.

Implementing the script system is no different. It is easily the hardest thing I have done so far for our new engine - HPL 3. It has had this "perfect"sort of challenge: Difficult problems to solve, much basic knowledge to wrap your head around and awfully boring and monotonous parts. I really hope this marks the end of this trend of increasing difficulty, as another proportionally large step might make my brain to melt and my fingers to crack. At least it can wait for a lil while...

Enough complaining. Now that the scripting is pretty much implemented (some engine stuff still needs to be added and some more problems remain to be solved, but it is really minor), I am extremely happy with it. I think it will help us build better games, and to finish them faster. Now let's move on to how a boring scripting system accomplishes this.

Before moving on the the actual scripting I need to explain what brought on the creation of the current system. It all started with our first commercial games, The Penumbra series.

When creating the Penumbra games our tools were primitive to say the least. All maps were made in a 3D modeling program, Maya, and then exported to Collada. The game engine loaded the Collada file and built the map from it. As a 3D modeling program is meant to create 3D models, it is not really meant to make levels in. With no ways of placing entities we had to use special naming conventions to tell the game where any non-static objects in the game were located. To be able to do this properly we had to make special "instance" versions of each model meant for the game, since without this you would not be able to see how an object was placed before the game started.

Lighting was equally annoying since Maya has no support for radius on lights. This mean that you could not visually see how far a light reached, but simply entered a numerical value and hoped for the best. As this was not enough, you also needed to place portals and group meshes in order for the engine to provide occlusion culling. This could be quite tricky at times, and often you could sit a day or two simply tweaking portal setup. Added to this was also the problem that Maya often failed to show any textures, and most editing was done on grayish levels. For more info, you can just check the wiki.

The problems do not stop here though. Everytime you meant a change to the game, you had to do a complete reload. So setting up lighting in the game could be quite the effort: change light position for two seconds, load map for 2 minutes, notice it is not good, repeat. As you might figure, we got quite good at batches tasks and the phrase "it will have to do" was uttered more often than not.

For scripting it was just a grueling. Every change in the script required a full restart of the game, creating the same sort of frustration present when modeling maps. And to make scripting even more frustrating, there was no syntax checking until the entire map was loaded! This meant you could wait two minutes of loading only to find out you had forgotten a semicolon or something else trivial.

As I write this, I actually have a hard time understanding how we could have gotten anything done at all. And unsurprisingly, even though we released mod tools and documentation, not a single user map for Penumbra was ever released.

For Amnesia we knew we wanted to fix this somehow. The first step we took was to simply make our own editor where all the maps are built. Since it rendered with the same engine as the game, it made is much easier and faster to tweak entity and light placement. We instantly saw that productivity rise with this change. For scripting it was pretty much the same, but we added the extremely simple fix of compiling the script before loading the game. This removed some of the time previously spent on, in vain, looking at loading screen.

Although we had new tools all was not good. You still had to reload all level data every time you made a change to the map or script. We did not think much of this though as we were so used to doing it this way, and happy that we had all the other improvements. However, a year and a half into the development we discussed if we really needed to reload the level. I cannot recall what sparked this idea, but anyhow we figured that we did not and I added a menu with a Quick Reload button. This cached all textures, models, etc and reloaded map very quickly (usually taking but a few seconds). This increased productivity and creativity tremendously and was one of the better decisions we made during the development of Amnesia. Another sign of how much these changes improved work flow are the over a hundred of user maps created as of today.

What is so strange about the reload-feature is that is something that we could have added during the development of the first Penumbra, but for some reason we did not. It is quite frightening how often you convinces yourself that there is no better way of doing a task, and never try to improve it. We did not want to make this mistake again and started thinking of what more we could do.

Taking script to the next level
In Amnesia and Penumbra, scripting is only used to control logic flow in the levels. How enemies spawn, how puzzles work and so on. All other gameplay is hard-coded into the exe file and written in C++. Normally when I write this kind of code, rendering for instance, I can do large chunks at a time and then simply see if it works as intended. This often in small projects that are fast to reload. However, when writing gameplay and UI code this is almost never the case. Instead you constantly need to fine tune algorithms and variables until you get the expected behavior and work in large projects. Not only does this mean a level restart (with full resource reload), but the exe itself also needs to be built from code, a process that can easily take half a minute, even if the changes are minor. This means that coding gameplay can be quite a hassle at times, on par with how map building was in the Penumbra days. With the lessons learned from Amnesia fresh in mind, this felt like the obvious area of improvement.

In order to make this happen we had to move as much gameplay code as possible into the scripting. What this meant was that we needed to do some large upgrades to our current script implementations. For example, right now we only supported the most basic types (bool, int and float) together with strings in script. This already caused some issues when exposing game/engine functions and when writing scripts, for example instead having a single argument for color, you had to have four floats (one for each color and one of alpha), making code ugly and writing it more cumbersome. So just this upgrade was worth doing.

We also needed expose all engine classes, so that the script could be used pretty much as if it was normal C++ code, and achieve pretty much the same things. I was not sure exactly how much to expose but knew that the more the better.

Finally, the most important feature was to be able to reload script at any point, so it would be easy to just change a line, click a reload button and then a few seconds (or less) later see the change in-game. To get this working was the by far the most important goal with the entire upgrade. This would not be as easy as the level script was in Amnesia though, since the script system would not only take care of the code, but of part of the data as well. This meant I needed to save the state somehow, a feat I was not sure yet how to accomplish.

Implementing Classes
Before tackling the problem of script reload, I first had to make sure to add engine types to the engine. And even before doing that I needed to be sure our current scripting middleware was up to the task.

The scripting system that we were using, and have been for a long time, is a library called Angel Script. It is actually the middleware that we have used the longest, ever since end of 2004 and the Energetic project. Even though we have used it for such a long time we never really used to anywhere near its full extent and now was finally the time to make up for that. I took a day to look through the documentation and found that AngelScript could support everything that we needed, and what was even better was that it was not that difficult to add.

AngelScript is a bit different from other popular script languages (like Lua) in that it is strongly typed and very closely connected to the underlying C++ code. For one thing this makes the script quite fast (although not faster, see end of post for more info). It also meant that AngelScript could link to the classes almost directly and I only had to declare the class and link to its different parts (whatever member variables and methods that I wanted to be exposed). It also supports pointers quite easily, but makes them more secure with a script specific handle type. This requires you to keep track of some memory management for the data, but you do not need to do it, and I could very easily and quickly add support for a vast number of engine resources (textures, meshes, lights, etc).

The only thing that was a little bit trickier was supporting inheritance (when a class can build upon another class). Basically you have to redeclare methods every time you add new class that inherits from something. You also need to specify to what other classes this class can be cast to. This might sound a bit of a hassle, but the result is that you can control so the script always has a very close mapping to the code it exposes, something that I was extremely thankful for when implementing the state saving (more on that below). Also, through some use of macros, adding the implemented classes become quite easy.

Basic script layout
The next thing to figure out was the basic structure of the script code. In Penumbra and Amnesia we simply added the functions directly in a script file and then allowed that script file to represent an object. I first thought that this would be a valid design this time again, until I started thinking about how to store the data (meaning any data that should be kept between executions of the script).

In Amnesia and Penumbra the only data that is saved is simple variables like an integer for the number of times the player had stepped on button or similar. This is done through using special functions for all these variables, for example:

SetLocalVarInt("ButtonPushNum", 1);

This function saves the data to the game, and when the script is reloaded (meaning destroyed and recreated) the script can easily reference the data again by doing:

int lX = GetLocalVarInt("ButtonPushNum");

However, this time the game had to save a lot more complex data, like pointers to resources, matrices and whatnot. At first I actually considered using system with functions like this, but I figured that it would just mean a lot of extra work, and just make things more difficult. Again I thought about the lessons from Amnesia's reload feature, and thought it was worth trying to find a better solution. What I ended up doing was to force each object to be contained in class, and then let all data to be members of that class. This allowed AngelScript to make copies (needed for enemies and whatever there will be more than one instance of) and also made it was easy to keep track of the members (you simply create an object in the C++ code and can then iterate all its data).

A problem that I realized now was that I needed to have C++ functions that only worked in certain types of classes and only on data for a certain copy. For instance, an enemy class might want a function like IsInLineOfSight(...) to see if it has visual contact with something. However, there were not any functionality in AngelScript for doing this. I could give the script class a template class that forces it to implement certain functions, but I could not let the C++ code act as a base and expose specific functions from it. To solve this I had do some hacking. I ended up using global functions, and to keep track of the currently active object. (Again with macros to the rescue.) The resulting solution was not perfect though, as the global function can be used in any class and not just the one it was meant for. I am still looking into some fix for this.

Saving the state
It was now time to save the state of the script. To start this off I took the naive approach and simply saved the script data directly by copying it. This works very well for stuff like vectors, matrices, etc where it is just a matter to make a copy of the data. But it does not work that well with resources like meshes, texture or even objects like physics bodies, billboards and lights. There is way too much data in those to copy. And if I simply save the pointer I need to make sure that no data has changed when the state is loaded again, or else the saved state will not work.

At the time I was only building the system to work with a script reload only, so these issues did not pose a problem. But a major obstacle popped up when I wanted to save classes defined in scripts code. These where not possible to simply save by copying, because when you rewrite a script they can change entirely. For instance, if the class when saved consisted of two integers, and when reloaded has one string and a matrix instead the data you saved is invalid. It gets even worse if a script class has another script class as member and even more so if script classes are saved in arrays.

I figured I needed to do some kind of drastic change if this was to work. I was sketching on a few systems that could save variables in a separate structure, when it hit me. The system I was working on could not only be used to save the state, but if I implemented it correctly I could also use it for saving. For Amnesia and Penumbra I use a special serialize system that can save classes to file if initialized correctly. It is quite cumbersome, but way better than writing load / save for every single variable. However, as I was to do most gameplay code through script (the code that pretty much contain everything that needs saving), I could actually get rid of rewriting the save code for every single gameplay update. Another huge benefit of using scripting: automatic saving. This is bound to save tons of work. (It did mean a lot more work though...)

Up to that point I had looked at the scripting as separate part of in the engine. A module that all other modules could work without if removed, exactly like how most other modules work. Thinking like this had colored a lot of the design decisions I had made. Now, I instead decided that since scripting will be basically what controls the engine, I started of thinking as something that was part of all other modules. This led me to do a major rewrite of the state saving.

There is quite a lot to say about this system (and serializing in general), but I do not really have the space right now, so I will just do a quick overview. First of all, the system defines a few basic types that all other structures are built up from. These are bool, int, float, vector, matrix, color, etc and I implement very specific create/save/load methods for each of these. In AngelScript all of these are also implemented as primitives (built-in types) or data objects (which is a type where AngelScript handle all memory management). When saved the actual binary data is saved.

All other classes are implemented as references, meaning AngelScript only manages their pointers. When saving the state of these classes, each class must implement a a special method that adds all of the member variables (either basic types or other reference classes) to a list. (Basically the explicit method described here). This list is then used when transferring data to a special save buffer that contains the data of all the basic types and/or sub buffers containing data for other classes.

For certain classes, its pointer is backed up in the C++ code. So when the save data for it is loaded, the pointer to the class is first searched for and if found it is updated with the saved member data. This makes it possible to reload the script code without having to recreate all the data.

Of course, all sorts of complications arise during this, and again it would take too long to go through them all. But as I hinted before one thing that saved me is that script objects are so closely connected to the engine data. When writing code that deals with serialization one of the biggest annoyances is that that class pointers with multiple inheritance can change their address when cast. Because the script language only returns void pointers (memory address with no type specified), you must be sure of the type it returns, something AngelScript allowed me to be.

Another fun thing with serialization are all the strange macros that you have to make. For example, this one was pretty fun:

#define ClassMemberClassOffset(aClass,aMember)

( size_t(static_cast(&(( (aClass*)1)->aMember)) ) -1 )

This one is used to make sure that class member offset address points correctly. It is one of the many things that make sure multiple inheritance problems, as explained above, does not screw things up. I got an entire header file just filled with fun stuff like this!

Closing notes
Once I had the system working it was quite an effort to add all the classes. There are countless classes that all need to be set up in specific way and everything to be saved needs to be initialized. Sitting several days in a row just coding stuff like this can really tear on the psyche. Fortunately, almost everything is added now, so the worst part should be over.

Another nice addition to the new script system is that it can auto generate the API function file for NotePad++. This allows NP++ to autocomplete any text that you write and you no longer need to keep function names or arguments list in your head (and skip the manual look-ups). What is annoying though is that it only works with global functions and NP++ cannot recognice what class a certain variable is in and show all its members (like visual assist can for C++). Does anybody know an editor that can manage this?

One thing that I was really eager to get working was threading. In Amnesia we use tons of special timer callbacks to set up events, and it would have been so nice to do something like this instead:


AngelScript does support this sort of thing, but there is currently no way of saving the state. So if the player where to save during a sleep, the game would be different when loaded. This is unfortunate, but I am looking into some other solutions instead. If anyone has ideas on this please share!

Right now I have only tried this system in some tests, but it still feels really good and works exactly as I want. It is just so great to be able to reload any code changes in a fraction of second. It allows for rapid iteration, makes one more productive and generally just makes it so much more enjoyable to code. It is also so gratifying to have an idea and then successfully implement it to the sort of quality you hoped for.


I earlier wrote that AngelScript was faster than Lua, which is not the case when it comes to code solely executed in the script (see here). So obviously my initial statement was not correct. However, I still think AngelScript must be faster in calling implemented c++ functions/types as there is pretty much no overlay involved. I do not have any data to back this up though, so do not take my word for it :)

Found this irresistibly interesting? We are hiring!

Battle for Venga Islands 1.1

Working on the 1.1 update.

  • Difficulty ratings are decreased.  Surrounded regions behind enemy lines will still be very difficult, but border regions should be easier.
  • Ocean regions act as friendly neighbors.  This is a pretty big change, and means that there should be a lot more opportunity to start new attacks behind enemy lines.
  • Data files are now tamper-resistant (I hesitate to say "proof").  Hopefully this should make it harder to hack the leaderboard.
  • Health balls will drop slightly more frequently.
  • Players can now change teams (one time only!)
I think the first two will make a big improvement to the game.  It was really difficult to imagine how the game world would play out, and I didn't foresee it getting as locked up as it has.  So I'm anxious to get these changes out asap.

Thursday, 26 May 2011


Well, it was only a matter of time.

I really have no idea about the file system on the Xbox 360.  However, I do know that you can save files to a USB drive, and then take that USB drive and plug it into a PC.  So it's probably reasonable to think that someone would have access to saved game data.  When creating the game, I never really cared about protecting the data.  I figured that if the game actually was popular enough that someone wanted to hack it, I'd consider that a success in its own right.

I save a file called "MyCapturedRegionCount.sav".  It's four bytes (one integer) long.  I'll give you a million dollars if you can figure out what data is stored in that file.

Someone apparently already figured it out and edited the file, and now we have a new surprise leader on the Hall of Champions!  Previous high score was 550 or something.  New high score?  OVER 19,000!  So much for subtlety.

Since discovering this, I've gone through all kind of emotions.

I'm angry, because one person is ruining the integrity of the game, and potentially costing me bad reviews, lost sales, and lost income.

I'm disappointed that someone would want to take a good thing and ruin it, just because they can.

I'm immensely proud that I've actually created a game that someone cares enough to hack.

I'm intellectually challenged, and want to fight back with encryption and checksums and so forth.

I'm defeated, knowing that whatever safeguards I put in place, there will always be a way around it.

I don't really know how to proceed, so I think I'm just going to wait and watch and see what develops.  When faced with conflicting options, I've found that "do nothing and see" isn't a bad one.

Wednesday, 25 May 2011

The XBLIG marketplace is broken

 Here’s what’s supposed to happen:

1)  Developer makes game, and publishes to the Marketplace.
2)  Game shows up on “New Releases” list, and is highly visible to consumers.
3)  People buy the game, and the Game shows up on the “Top Downloads” list.
4)  If people like the game, it gets rated highly, and goes on the “Top Rated” list.
5)  As new games are published, the “New Releases” queue moves, and old games fall off the end.

The problem is that #3 is broken.  The “Top Downloads” list hasn’t changed in over two weeks.  This is great news for people who happen to be on it at the time it was frozen.  This is terrible news for people like me who just released a game.  We’re missing out on prime visibility.  With Bad Golf, 95% of all sales were made in the first few weeks while the game was on the lists.  Once it fell off the New Releases list, that was pretty much the end.  So these first few weeks are critical.

I was so excited to release this game, I didn’t even think to check on if the Marketplace was working.  You just kind of assume that it would, ya know?

There are worse things that could happen, but still, it’s a little disheartening.

The Gathering

On the morning of May 10, we all gathered for the very first time. Unlike what many had prophesied, this did not bring about the end of the world. No, this Tuesday morning turned out to be quite benevolent. The six of us met at Malmö train station right next to the statue of the knotted gun, which incidentally did no longer exist.
“Good,” said Thomas, “would have been too easy to find if we were able to follow our directions.”

Thomas and Jens are the founders of Frictional Games. They make an interesting and effective pair. Thomas is a force of nature hauling us off to adventure, while Jens is the more reserved type who dryly states that we’re going the wrong way. Together they manage to keep us moving on the right track.
I had already met them both before and along with Marcus and Luis, who I had met on the trip to Seattle, there was only one man left.
Marc turned out to be a cheerful man with subtle gestures. His eyebrows bounced as a silent hello.
“I guess we are all here.”

The Gang

That innocuous Tuesday might seem arbitrary, but there was a reason for us to meet in Malmö that day. The city hosted the Nordic Game Conference and we were to attend and hopefully receive some love from the press and our fellow game developers.
“This is going to be fun. And the award ceremony is going to be exiting!”
“Right, about that. We were not nominated for anything,” informed Jens.
“Not a single nomination? From the very people who even helped to fund Amnesia.”
“We got a free booth to display our game.”
“Better than nothing?”
“Not really, now we have booth to attend to.”

We were there to attend the conference, to hang out, and get to know each other. We really didn’t have anything new to show, which kind of explains why our booth was grossly understaffed and consisted of one computer running Amnesia with a t-shirt strung up above it.

The conference took a slow and smooth start as we really didn’t have anything to attend except a minor exposé of games including some casual drinking. That is why we first headed off in a completely different direction and ended up visiting the “House of Science and Maritime History”, a museum filled with old machines and oddities. Having filled our heads with interesting factoids, it was about time we burned a few braincells with a bit of reckless driving at the go-cart circuit. Marcus stumped us all with his motor skills, leaving us convinced he must have had a lot of practice. Being from the northern wastes, it only seems reasonable he would have to drive fast to get away from polar bears and Santa.

Road Rage!

Wednesday was the day that the conference really got going. Ed Fries, a game making legend from Microsoft, launched the day with a great keynote speech about creativity and constraints. Afterwards we all split up and to attend the lectures we found most interesting, only to meet up by the Street Fighter arcade machine during the breaks, to kick ass, chew pastries, and drink coffee.


During the evening the main gala was held to announce the winners of all the awards. Knowing well we hadn’t been nominated, we chowed down on the delicious food we were served. That’s when we suddenly noticed that they were playing a Amnesia-trailer on the big screen.
“We won... something!”
“Wait, what? Did we?
No, we didn’t, at least I don’t think we did, but we were called on stage to take a bow in a nice lifetime-achievement sort of way.

The next day when all the hoopla had settled, we were greeted, by strangers and friends.
“Congratulations on the award!”
“Thanks, we didn’t get one.”
“Sure you did, you were on the stage and everything. Must have been some kind of award.”
To this day we don’t really know what that was, but it was interesting mixed with a hint of awkward.

Thursday passed with even more lectures and Street Fighting. As a final farewell, all the participants gathered in the large hall to play a game. Not the digital kind, well almost, indirectly if you will. The moderator pulled up two game titles and a statement. Then two people from the audience got to argue which game fitted the statement. The first bout? Amnesia v.s. Bioshock – Which one is more disturbing.
The first thing that ran through my head was; what if I was picked to defend Amnesia, that would be embarrassing. Then it struck me. What if I decided to defend Bioshock! It was not like anyone really recognized me as the writer. That would be hilarious, to talk smack about our own game, what if I won that argument? I was laughing inside already.
Even though I now and then get some clever ideas, I tend to be slow. When I went to raise my hand, it was already too late. Two contestants had begun to argue what was more disturbing already. Pride and shame mixed as they argued their sides, but it turned to a heartwarming experience as the crowd favored Amnesia. Hell yeah, we made a disturbing game.

If you want to slow down, just crash into something.

On Friday there was no conference, it had ended on Thursday. However, there was more to be done. Luis and Marcus, the two people who actually had to fly in to be able to attend, had one more day to spend. Jens and Thomas invited us to come to Helsingborg, where they and Frictional Games officially reside.
Since there was no office to visit, we headed out into the city. To do so in style, we jumped on Segways and rode around. It was tremendous fun and we got to see the surrounding nature in a pleasant way. Some even got to see the dirt road, up close, as they came crashing down. That’s right, no less than Jens, Marcus, and Luis managed to crash their Segways. In increasingly dramatic ways too.

After the death defying speed racing with Segways, we slowed down with some care free sightseeing in the city and a visit to the local tropical zoo.

The evening and the week ended with some fine dining and then some beer at the pub. It is difficult to sum up the experience and let you in on all the details. Let’s just say, a bunch of anonymous internet people came together in real life... and the world didn’t end this weekend, that’s strange, isn’t it?

You’re welcome.

Marcus in his natural habitat.

Tuesday, 24 May 2011

Day 1 Thoughts...

The game has been up for over 24 hours, and it appears to be working as designed.  I'm very excited.

I didn't anticipate two things.

The first thing is how difficult it would be to press into enemy territory, once battle lines are established.  I knew I wanted to have a range of difficulty levels, and make it easier to attack regions where you own some of the neighbors.  But I didn't realize that the difficulty level would still be Challenging, Difficult, or even Heroic/Legendary.  I also didn't realize how difficult it would be to try to re-capture an island if it's entirely owned by the other team.

The other thing I didn't realize was how addictive the game would be for some people.  I was astounded to see some players capturing hundreds of regions on the first day.  The high score list shows players up over 200 and 300 captures.  Pretty impressive.

I'm not allowed to submit a patch to the game for a week, but I'm considering the following:

1)  Reduce difficulty levels by one level across the board.
2)  Make ocean regions behave as friendly regions when attacking a coastline.

The idea is that the FUN part of the game is attacking and gaining regions.  I don't want to make it TOO easy, but I think it's too difficult at the moment.  I also would like to make it harder to dominate an entire island, and I like the idea of a sneak attack behind enemy territory... hence the ocean change.

I'm going to think hard about these changes over the next week, and monitor the map to see how it goes.  I don't want to make any rash decisions. 

I'd appreciate any user input, if anyone is reading this.

Monday, 23 May 2011


The map is filling up fast!

I'm a little concerned about how things will work once all the regions are taken.  Obviously I knew that was going to happen, but I just hope there are enough regions that aren't all Heroic and Legendary to fight over.  I was able to singlehandedly take some Heroic regions, so it's possible, and with a teammate, it should be even easier.

It's been a crazy day.

The Battle for Venga Islands has begun!

When I checked on the status of my Peer Review this morning, it said it was ready to publish!

All thoughts of timing the market, waiting for summer vacation, and so forth went right out the window.  I decided to try the ol' "Monday morning 8am release."  I published at around 8am, and the game was available to play by about 10am or 10:30am.

I sent out a slew of emails to some reviewers saying "try my game!", and then sat back and watched.

I have a little "Online" indicator that is a debug tool to tell when data is being transferred to another client.  I was able to watch that light up, and look around the map and see that some new regions were captured.  I also have a "most regions captured" high score list, and I started seeing names pop up on that.  IT'S WORKING!

After an hour or so, some people have gotten online, captured a region or two, and left.  But one or two players are systematically capturing strategic regions, trying to surround the starting lands of the other team.  Another player noticed this, and they are in kind of a slow-moving chess match trying to surround each other.  It's thrilling to watch.

There are currently 11 people on the high score list (including me).

I can't wait to see how this all shapes up!

With Bad Golf, I had no sense of when people were playing the game, or how much.  I just needed to wait a couple days to actually see results show up in the reports.  With this game, I get a very real sense that people are actually playing it RIGHT NOW, and can track their progress.

So cool.

Sunday, 22 May 2011

Inspiration should be obvious on this one...

One of the my complaints about summoning spells is the rigidity of the summon monster and summon nature’s ally lists. I understand the argument that if you open it up to all the monsters the spells become far too versatile. So I’m proposing a solution where we selectively open up the lists via an imprint  sphere.

Aura faint divination; CL 5th
Slot none; Price 250 gp; Weight – lbs.
This fragile sphere is colored red and black (for arcane casters) and green and brown (for divine casters). The wielder throws the imprint sphere at its intended target with a ranged touch attack. If the sphere hits, it breaks and knowledge of how to summon that creature is imparted to the wielder if it meets the proper requirements.
  Arcane casters can only imprint animals, magical beasts and outsiders.  
  Divine casters can only imprint animals, magical beasts, outsiders [elemental] and  plants.
  The wielder can only imprint creatures that have the same challenge rating or lower than creatures that they can already summon with the summon monster or summon nature’s ally suite of spells. Once imprinted, the creature is permanently added to your list.
Requirements Craft Wondrous Item, creature loresight*; Cost 125 gp.

* From the Book of Eldritch Might II

Friday, 20 May 2011

Venga Island Predictions...

BfVI is making its way through Peer Review.  It has 5 or 6 passes (out of 8 needed, I think?), which has gotten me thinking about release day.

The Powers That Be added a new feature to the XBLIG system, which is that developers can now choose their own release date.  In the previous system, games that passed Peer Review would automatically go to the Marketplace.  Now, they go to a holding area until the developer actually clicks the "Release" button, and they appear on the Marketplace within 24 hours or so of that.

This allows for you do build up some buzz before the game is released, and perhaps also time your release to a coveted Friday release day.  It's a double edged sword, though, because if everyone did a Friday release, you'd get shoved down the "New Releases" list pretty quickly.  So it's a big meta-game.

I don't know when I'll release it.  I'm thinking on a Monday or Tuesday in an attempt to maximize time on the New Release list, but who the hell knows.

I was just daydreaming about what it will be like when the game actually goes live.  I will buy the game myself, and start it up.  I will be presented with a blank map, with only a few initial regions claimed by either Queen Allison or King Burr the Little.  In a best-case scenario, the regions will start to be populated before my very eyes.  Every minute or two, the map will update as other players buy the game and start conquering regions.  Since it's easier to capture adjacent regions, hopefully the Red and Blue areas of the map slowly expand outward, and battle fronts form.  The high score list will get populated with the Top 100 players, and people will vie for the top spot.

The worst case scenario? I can think of a couple.  The game crashes for an unknown reason at random times.  The entire map turns instantly to a single color (indicating that someone hacked or cheated and claimed every region).  Or the map simple doesn't change at all because no one has bought or played the game.

Who knows?  But I'm dying to find out!

Khurasan releases the Mekanoids!

Here is a little something that snuck on by me while I was grinding away on the 15mm Crusader.

Jon over at Khurasan released the 15mm scale Mekanoids. I had the pleasure to design the Dictator and Hatchet gunship. You can see details of the release posted on TMP and purchase them here.

These kits have been a long time coming and I am very happy to see them in production.

Wednesday, 18 May 2011

Battle for Venga Islands

After Bad Golf, I took a month or so off of game programming, but then I got a bit of an inspiration.

I read about Spyn Doctor's high score sharing component. This is a bit of code that replicates the idea of a central, shared scoreboard for a game. So, pretend you have a Space Invaders game. It's a single player game, and you play to see how high a score you can get. Wouldn't it be fun to see other people's scores? This component allows for that.

What it does it open network connections while you're playing the game, and it looks for other people playing your game that that exact same time. When it finds someone, it takes your high score table, and their high score table, and merges the two together. So now your high score table has aggregated scores from two people. This process repeats, always looking for other players, and keeps sharing and sharing and sharing as much as possible. And when you share, not only do you share your own high scores, but all the high scores in your list (that might have come from somewhere else). So scores propagate around the system. It's very unlikely that everyone's high score tables will be in sync, but you get the idea.

Now, the glorious thing about the code is that it's generalized. It doesn't HAVE to be used to share high scores. It could be used to share any kind of data. He just provides sample implementation of sharing high scores.

So I got to thinking. What kind of game could I make that shared some other kind of data?

The immediate issue is synchronization, or lack thereof. You have to make a game where it's ok for things to be out of sync as you share data with someone else.

My first thought was something like this: What if you have some huge amount of "work" that needed to be done. Each player begins playing, and requests pieces of work that haven't been done yet. When they finish a piece of work, they mark it as complete, and repeat the process. The data that is shared, of course, are the pieces of work that I've completed.

The idea is very much like the SETI@Home system. It doesn't matter if multiple people work on the same piece of work, as long as SOMEONE does it.

So, what kind of "work" could I provide to players that would be fun? My first thought was a giant maze. Like, a 2D maze that you'd make on graph paper. Each cell of the maze is a room (like, in Zelda). Players would play some little game in the room (like, killing all the monsters), in order to mark it as complete. When a room is marked as complete, that data is shared with all other players. If multiple players mark a room as complete, it's ok. Nothing breaks.

As more and more players fill in the maze, everyone can build off each others work, and finally complete the entire world. What then? Who knows.

Early Maze Game

That idea morphed a bit into having a country, with multiple regions in it. Players would be assigned to one of two teams, and try to capture regions, again by playing a little mini-game in each region. Region ownership data, then, would be the data that is passed around to peers.

I started out with an SVG map of the United States, divided up by counties. Dealing with SVG proved beyond me. But I found some fabulous information about making polygonal maps, including a tool to create your own and export it as XML. Soon enough, I had my own big map going.

Early Map

The game started to take shape. Players are assigned to either the Red or Blue team. They look at the map, and who owns what regions. They choose a region to try to capture, and play a little twin-stick shooter mini game to try to capture the region. If they capture the region, then that goes into their "high score list", and marked as data to be traded with other peers.

During development, Magicka came out. So I tried my hand at special effect programming to make some cool spell effects, and that did a lot to set the tone of the game.

Early Gameplay

The key to the entire system is that the time that each region is captured is stored in a synchronized timestamp. When region data is compared, that timestamp is used to determine who owns the region.

An example is in order:

Player R is on the Red team.
Player B is on the Blue team.
Player C is on the Red team.

Player R captures region #123 on his own local Xbox.
Soon after, Player B captures the same region on her local Xbox.
Player C doesn't do anything.

At this point in time, all three maps are out of sync. Region 123 is claimed by red for R, blue for B, and unclaimed for C. (Do you see why?)

As the games detect each other on the network, these differences are worked out. If R and B connect, then B's map won't change, but R's map will show the region now owned by the Blue team (because B captured it later). When either R or B connect to C, C will be updated to show the region owned by Blue.

When taken all together, this provides a shifting, changing, evolving battlefield. IT DOESN'T MATTER that everyone's map may be wildly out of sync. What only matters is that each individual player will see their own map changing.  Until I'm proven wrong, I think this is pretty clever, and I don't think anything like it has been done on the XBLIG platform.

After some time, the map and gameplay were all pretty much set. I added a Difficulty rating to each region that is dependent on the surrounding regions. That is, a region that is surrounded by regions owned by your team should be much easier to capture than regions that are surrounded by (or owned by) your opponent. This should (I hope) have the effect of creating natural "battle fronts".  It should be pretty impossible to capture a region that is "behind enemy lines", but much easier to capture regions on the border between yours and theirs.

I also added a "Regions Captured" high score list, that is shared in the traditional way.  This is a globally shared list that shows the top 100 conquerors. This should provide some motivation for players to capture more and more regions for their team.

I'm a PS3 and PC gamer. Multiplayer gaming has always been free for me. To do network gaming (even data sharing in the background!) for the Xbox, however, requires a paid membership. This meant that only a subset of actual players would get the full experience of taking part in the dynamic world. Everyone else will just have a blank map that will never get updated. Pretty boring. I added a "Quickplay" option, where they can just play the fighting part of the game (and choose their own difficulty), but I admit I'm not sure that's worth the price of the game.  Luckily everyone gets to try it before they buy it.

After a few months of development, I got things all up and tested. I enlisted my friend Eryn to do a pretty cool loading screen, and was put in touch with a student musician to do custom music for me.

I threw together a little video and some screenshots, and submitted for review!

And some screenshots...

The whole thing is a pretty big experiment, but I've gone over it every which way in my head and don't see any reason why it shouldn't work.  It's halfway through peer review, and should come out very soon, so nothing to do now but wait and see!  I plan on leaving my Xbox on, at least for a while, to see how the world evolves.  Should be pretty exciting!

We are hiring: Programmer wanted!

Frictional Games is now looking for a talented programmer to join the company!

You will be working for a small team with a big focus on finding new and innovating solutions. We want you who are not afraid to explore uncharted territory and constantly learn new things. Self-discipline and independence are also important traits as all work will be done from home.

Some the things you will work with include:
  • 3D math, rendering, shaders and everything else related.
  • Console development (most likely Xbox 360).
  • Hardware implementations (support for motion controls, etc).
All coding is in C++, so great skills in that is imperative. You should also be living in Sweden or a time-zone nearby. If you are fit in other areas we are of course prepared to be flexible.

If interested send CV to: jobs [at] frictionalgames [dot] com

What we are most interested in seeing is evidence, in form of things you have done, that you are qualified. Having interesting works to show off can make up for any gaps in knowledge.

Monday, 16 May 2011

Bad Golf

In September of 2010, I started working on "Bad Golf".

I'd been playing a lot of "Stick Golf" for the iPad, and figured I'd more or less rip off the concept. The idea of a 2D physics golf game isn't anything new, harkening all the way back to gorilla.bas and Scorched Earth, so I didn't feel too bad about it.

Bad Golf was intended to be a multiplayer golf/fighting game. The players would play golf on a 2D side-view course, but between shots, they could fight each other and slow down the other players from reaching their ball.

Once I got the main golf game going, I saw that I was going to have a problem. I wanted to have courses that had "islands in the sky", or other kinds of landscapes and layouts that wouldn't necessarily be readily accessible by a player running around. Would they have jetpacks? Or grappling hooks? Or could they climb vertical walls? Pretty quickly, I nixed the whole fighting aspect, and just went with a straight golf game (but the title stuck).

After working on so many projects where I lost steam, or painted myself into a corner, I knew that I needed to rely on as much external help as I could. For example, I was absolutely willing to change my vision of the game depending on what free tools and libraries were available. Many people wouldn't settle for a third party particle system library, for example, because it didn't have all the features they might want. I knew that if I took the time to write my own, I might run out of gas before I got to the end.

Bad Golf makes heavy use of the Farseer Physics Engine, and it's great. It took some time and effort to figure it all out, but soon I had a ball bouncing around the screen. Farseer has "texture to physics" functionality, which basically meant all my course design could be done in a paint program. One less tool to worry about.

Particle effects were done with the Mercury Particle Engine, another fantastic tool for making pretty flexible and substantial particle effects. Why on earth would I even start creating my own particle engine when I have options like these?

Coding was pretty easy. The game is straightforward enough that I didn't need to struggle with any design decisions or tuning problems. Course creation was a big pain in the ass, but I eventually got to the point where I said "screw it, it's good enough" and pushed forward.

I wasn't going to plunk down the $99 for the Creators Club fee until I was damn sure I was actually going to release the game. When I finally got to the point, getting it up on the Xbox was pretty much a breeze. I did have one big issue, in that it took about 40 seconds to load a level on the Xbox, compared to maybe one second on the PC. This was a problem, and introduced me into the wonderful world of the Content Pipeline.

You see, every time a level (hole) was loaded, I was reading in multiple graphics files. One was the background, and one was the foreground, but another one defined the physics of the hole, and another one had the special features (water hazards, sand traps, tee location and hole). Those last two textures had to be analyzed, and the texture-to-physics process run. What I realized was that I could do all that analyzing at compile time, and spit out raw level data. Then, in my game, I didn't need to recalculate everything, I just read in raw data and draw my level. Load times went from 40 seconds to sub-second. Classic Content Pipeline problem.

I was surprised at how much plumbing needed to be done, once the final gameplay was all working. Menus, fonts, screen changes, high scores, blah blah blah blah. That was kind of tedious. I used the Game State Management sample as a base, but customized it. Spending time learning the GSM is well worth the effort. It's a great starting point to any game.

I enlisted my friend Eryn to work on art for me. He did a fantastic job, but I quickly realized that it would take a lot of time and effort on his part to make 36 pictures.

So I found some textures and did some Photoshop magic to create a kind of flat-paper theme. Good enough. I threw together an official preview video, and I was good to go.

Bad Golf had a relatively uneventful playtest, and went into peer review in early December. On December 24th, it was released to the Xbox Marketplace. A day I will never forget. My game was actually published. For professional game devs out there, this maybe isn't a big deal, but as a hobbyist, this was huge.

I had no idea what to expect. Honestly, all I wanted to do was make my $99 back. Spending all that time and energy and losing money on the deal would have sucked. I told myself that I wasn't doing it for the money (and that was true), but it still would have sucked.

I had to wait a few days for the first sales reports to come up. I asked a friend of mine at work to guess how many copies were tried and purchased? He guess eight trials and one purchase. The real answer was something like 700 trials and 200 purchases. I made my $99 back on the first day!

While Bad Golf stayed on the New Releases list, it continued to get dozens of downloads per day. Then it pretty sharply dropped off, and for the last four or five months has been getting about 2-3 purchases per day.

Here are the statistics, as of today:
Trials: 7251
Purchases: 1760
Purchase/Trial Ratio: 24.27 %

That 24% conversion rate is something I'm pretty proud of.

The first week of sales (the last week of December, 2010), netted me about $500. The next quarter (Q1 2011) netted about $600. $1100 over the course of a few months isn't life-changing money, but it's satisfying to know that people are out there playing my game.

What I didn't expect were the reviews. It was thrilling to read reviews of MY GAME out there on the Internet. Some reviews were prompted my emails from me saying "Please review my game!" Others were just on their own. One guy made his own YouTube video of him playing the game. These were all awesome.

This was pretty much the icing on the cake:

Bad Golf is a crummy little golf game, but it's MY crummy little golf game, and I'm proud of it.

In the Beginning

I've been a gamer for about as long as I can remember.

My family got an Apple ][+ when I was around 6 years old. I still remember that the two games that came with it were "Castle Wolfenstein" and "RobotWar". The former got me into gaming, and the latter probably kicked me off as a programmer.

As an adult, I still play games, but also tend to swing back and forth between that and actually trying to make games. I've started dozens of projects, but I usually get to the point where I say to myself "Who is actually going to play this? Maybe my friends will humor me, but is it really worth all this effort?"

The along came XNA and the Creators Club.

I'm a professional C# programmer by day, so XNA wasn't too difficult to learn. And after so many failed projects, I'd already learned a lot of lessons on my own.

I've said it before on the forums, but I'm still totally shocked that Microsoft gives us access to all the tools needed, as well as a publishing platform to MILLIONS of Xbox Live players, for an annual fee of $99. This really is a dream come true, and was sufficient motivation for me to actually finish one of those projects I'd been working on. Not having any audience or publishing platform was a sufficient deterrent, but the final piece of the puzzle was now in place.

printf("Hello, world");

So, I figured with my second game coming out, I might as well start an official game development blog. More soon.

Finding videogame's true voice

The main gist of this post is that we are not using the full narrative capability of video games. I believe we fail to take into account certain aspects that lie at the core of making artistic creations powerful and thus miss out on crucial strengths of the video game medium. To get to the core of these strengths, I will first have a look at other media (specifically film and literature), and then explore what lessons that can be applied to video games. What I end up with is a way of thinking that use basic elements of the film and literature experience, yet is quite different from these.

It is very easy to look at other form of media, see what they do well, and then try and copy this. I think this is a big problem for video games. Whenever a game focusing on a narrative-oriented experience is made, it is instantly compared to other media and judged according to their strengths. For instance it is very common praise to call video games cinematic, or to concentrate critique on their plot structure. Obviously, I do not think this is the right approach. Instead I think we need to take a step back, and consider what it is really in these other media that makes them work. We must then explore in what ways these concepts can (and if they can!) be applied to video games.

My suggestion for this "magical essence", which I will outline in this article, are empty spaces. The bits that require the audience's participation and imagination. Basically, the part of art that require us to be human.

The power of imagination

First of all let us take a look at literature. For this "The fall of the house of Usher" by Edgar Allen Poe will be used as an example:

"I know not how it was—but, with the first glimpse of the building, a sense of insufferable gloom pervaded my spirit. I say insufferable; for the feeling was unrelieved by any of that half-pleasurable, because poetic, sentiment, with which the mind usually receives even the sternest natural images of the desolate or terrible. I looked upon the scene before me—upon the mere house, and the simple landscape features of the domain—upon the bleak walls—upon the vacant eye-like windows—upon a few rank sedges—and upon a few white trunks of decayed trees—with an utter depression of soul which I can compare to no earthly sensation more properly than to the after-dream of the reveller upon opium—the bitter lapse into everyday life—the hideous dropping off of the veil. There was an iciness, a sinking, a sickening of the heart—an unredeemed dreariness of thought which no goading of the imagination could torture into aught of the sublime. "

This is an excerpt of a quite lengthy passage where the narrator describes the House of Usher as he approaches it. Even though it says a lot, it gives us very scarce information of how the house actually looked like. The focus is instead on the feelings and actions of the protagonist. The text tells us the response that the imagery evokes in the narrator and based on that it urges us to make up our own mental image of the scene. This is typical for literature. Descriptions are usually sparse and instead emotions and events are used as to paint a scene for the reader. A lot of responsibility is shouldered on the audience, certain knowledge is assumed and this (which I think is especially important to highlight) without the author losing any artistic control.

Next, let us consider movies. Normally one would think of movies as being very exact in their portrayal of a story, almost like a window to an alternate reality. However upon a bit of analysis it is clear that this is not the case. Film requires us to make non-trivial connections between sequences and invites us to read the minds of the actors. The Kuleshov Effect makes a clear case for this. Just watch the following video yourself and consider how your interpretation of the face changes depending on the context in which it is shown:

As we see a character on screen, we are meant to start imagining what that person might be feeling. Whenever a cut is made, it forces us to make up a casual relationship between the juxtaposed events. This can easily become quite complex as this short clip from the famous Odessa stairs sequence show:

Somehow we are able to make sense of this cacophony of imagery, constantly making connections between clips, weaving our own coherent narrative inside our minds. Just as books require readers to fill in the sensory details of a scene, a film forces the viewer to imagine the emotions and casual relationships portrayed. Both literature and film heavily depend upon the audience's imaginative interpretation and will lose its impact without it. I would even say that the greater this gap of imagination is, the more room for interpretation, the more powerful and artful the work becomes. By this I do not mean that the more obscure art is, the better it becomes. Rather, the ability to leave plenty of gaps for the audience to fill, without making the work incomprehensible and meaningless, is what makes great artists and great works of art.

Filling a gap
Even though this audience participation required in books and movies might not be obvious at first, it does not feel that strange once you realize it. It is quite easy to see that we make up worlds in our head when reading or that we construct a fluent narrative from edited imagery when watching movies. But viewed from the perspective of somebody who encounters this for the first time, I would say that is far from evident. It is really quite weird that we can count on the audience to build up whole scenes in their heads. This based on almost purely emotionally descriptive content. Dialog in literature is a great example of this, where the spoken words are alone at conveying the look, actions and sometimes even emotions of the characters involved. There are tons of background knowledge required to makes sense of this, and it would be extremely hard to teach computers the same tricks.

I bring this up mainly because I want to show that, even though all of this is now part of our everyday life, it is far from self-evident truths. For instance, film editing took a while before it was properly figured out, and its complex usages even longer. This should hint us that whatever there is left to figure out about the videogame media, we should not expect it to be self-evident or even seem like it would work when first encountered.

Another important reason for bringing this up is to show that all of these gap-filling has a retroactive aspect. For instance when connecting clips in a film, the whole meaning (ie the action that the clips portray) come together afterwards. Yet to us it seems like a continuous experience and in a way we actually inject false memories of an imagined event. This is basically how animation work, where we first see an object in one position, then in another, not until both event are experienced making our brain interpret the entirety as if motion occurred. However, we never experience it like that; we simple see it as a motion of an object from one point to another and do not notice the mental effort required.

This is even more evident in literature where descriptions of objects can come far after they were first introduced. Even though this may seem like a jarring discrepancy, it pose no problem to us and we can meld these new facts with the earlier event portrayed. For example, if we remember a tale the early happenings exist in our mental images with the detailed characters shaped during the full read-through. They are no longer the unknown entities they were when we read the passage for the first tine.

What this tells us is that we should not be afraid of giving the audience incomplete information or experiences. Not only does this "removal of facts" not pose a problem, but it actually seem essential in creating a powerful experience. It is actually as if something "magical" happens when we are forced to complete the work ourselves.

Side note:
Split-brain persons show a very extreme example of our human urge to, often unconsciously, fill these sort of gaps. For example, outlined here are some experiments where the subject effortlessly made up details from incomplete information without conscious knowledge about it. I think it clearly shows how the brain is hard-wired for this kind of behavior and that it is essential to what makes us human. This visual illusion found here also show how eager we are to create casual relationships, and how the context makes us change how these are made.

In search of the void
It is now time to take a deeper look into games and to search for an equivalent of the "gap filling" concepts found in literature and films. Instead of meeting this head on, I think it is important to discuss what it is that is especially distinct and descriptive (and thus not requiring the audience's interpretation) in games. I would say these things are:
  • Details of the world. Not only are games extremely clear on what a scene looks like, they often allow it to be exploration and makes it possible to very closely examine the various parts of the world. This is something that is especially true for 3D games, where players can view objects from almost any angle they please.

  • The fluidity and coherence of actions. As players are in direct control of the protagonist, there is never any doubt of what events are taking place. Because of the interactive nature of video games, a constant feedback loop of actions and consequences are required, forcing the events taking place to be exact. Video games are all about right here and right now.
Side note: I am aware that the above might not be strictly true for all game types and is more fitting for real-time 3D games. Although this should not disqualify any further conclusions, it might be preferable to think of the following discussion as focus on 3d video games in particular.

The above points mean that if we want to leave room for imagination in games, it cannot be the scene building from literature nor the connecting of events in film. With the level of detail of the world provided, little is left to the imagination. And the fluent events demanded leave very little room for players to fill in their minds. So what other gaps are there to be filled? To find this out, we need to take a look at a core feature of video games: interactivity.

So what exactly does interactivity encompass? I like Chris Crawford's definition (from this book):

"A cyclic process between two or more active agents in which each agent alternately listen, thinks and speaks."

What I like about this wording is that it makes it clear that interaction is not all about a user providing input. It is also about considering and then reacting to this input, and that the same applies for both sides (meaning both the human and computer). When it comes to finding opportunities for adding gaps of imagination, these are all of course on the humans side. Also note that the gaps might take place at any of steps: listening, thinking or speaking. With this in mind, I will make an attempt at some gap finding.

So where in this interactive cycle does there exist room for the imagination? The most obvious place is of course the "listening" (meaning any input). Even though we get a clear view of how the world looks like, there are still things left for our us to craft in our minds. This is something that is already present in some games and comes in the form of "environmental storytelling". Through exploration players can pull information from the world, gather details on past events and imagine emotional states of the world. Bioshock is a good example of this, where much of the attitudes and history of the sunken city can be found out purely by, the interactive process, of exploring the environment.

However, environments are lifeless entities, and while they can portray the aftermath of actions, they do not give us any feeling of agency. This greatly lessens the impact and diversity of imaginative gap-filling players can make. To take this to the next level, it is quite obvious that we need to included simulations of conscious beings. This allows us to construct mental "theories of mind", something that greatly increases the possibilities of expression. The problem is that we simply cannot do this with current technology, except at a very rudimentary level. While our techniques for facial expression is constantly getting better and better (L.A. Noir is a good example), this is only meant for prerecorded usage. When it comes to real-time procedural generation of expressive characters, we are at an extremely primitive stage. Because of this I believe that this can be very interesting to explore in the future, but not something that can be used right now.

So what else can be done? With expressive characters in real-time not an option, we must turn focus onto the actions themselves instead. As stated above, the events in video games do not leave any room for interpretation. But there still room for the imagination here though. What actions to make and why the are made.

Constrained role-playing
Imagination of the what and why of actions probably sounds a bit strange and needs some explanation. When players take control of an avatar in a video game, they are free to do what they please as long as it is accordance to the rules of the game world. This freedom might seem as the kind of gap that can be used to mimic the "magic" from literature and film. However not in the way actions are normally implemented: very specific and unambiguous. I reason so because there are two major problem with this approach.

The first is a technical one, namely is that it is pretty much impossible to give the player access the space of possible actions for any given situation. This means that there will always be events that the player can think of, but will be unable to carry then out. This limits the ability to role-play and might also leave, according to the player, the most intuitive and plausible action unavailable, breaking up flow and presence. The second problem is that the more events are added to aid role-playing, the harder it is to have artistic control, making the experience into an open-world simulation instead. As both of these problems work against one another, I think we have gotten pretty much as far as we can using this kind of design.

My suggestion for solving this problem is to have a limited number of actions available, but to lure players into imagining that the actual action performed was exactly the one they wanted to do. A very simple example of this can be found in games Samarost and Windowsill where the player can never in advance know what a mouse click will result in, yet when the action occurs it feels very intentional. This imagined motivation does not have to occur on a such low level though, and can include larger segments of the game. An example of this is The Path, where players are thrown into strange environment and forced to make up their own reasons for being there. Often this is something that is built up over a long time, yet greatly shapes how you view your entire session. I am not saying that these games are doing it the right way, only that they incorporate rudimentary versions of the ideas I am talking about, and hence can give one a basic hint of where to start from.

I bet that many will think of this concept as cheating. How can tricking the player be a proper design choice? If the whole interactive experience is an illusion, how can it carry any meaning? I argue that the same is true for other media. The events that you think happen on in film are in fact illusory too. Not only in the way that they merely consist of acting, set pieces and post production effects, but that many of the actions perceived was never filmed at all. They were instead conjured in the mind, by interpreting visual and auditory stimuli. The same is true for literature, were most of the mental images are never found in the text. Despite of this we do not describe the experiences these media give us as meaningless tricks.

Why "motivational imagination" sounds so strange has to do with the nature of interaction. When we watch a movie or read a book, this is passive experience where data only flow as input. But in the cycle of interaction, we are also part of creating output data. So when we create gaps of imagination for this kind of art work, we are unable to see it as a one-way stream of information, but have to include ourselves into it as well. The upside of it all, besides the solving the problem of role-playing, is that it fits neatly into same kind of concept that gaps in literature and film build upon. First of all, it contains a retroactive aspect to it, as players will need to digest a certain amount of data before settling on a certain motivation. It also forces us to make up a theory of mind, not for a fictional character, but for ourselves, inversely figuring out how we could come to a certain conclusion.

With this hypothesis I am not urging people to create games that are extremely linear and only require a single input. I still believe that we can have a wide palette of interaction choices, but that we might not want to be too specific about the exact actions that ought to occur. This is actually very closely related to the concept of player-avatar-symbiosis that have been discussed in an earlier post on this blog. I also do not believe that this takes away anything from the experience, but only adds to it, just like the same line of thinking does to other media.

End notes
This is far from a full theory at this point, and "environmental storytelling" and "imagined motivation" are most likely not the only imaginative gaps that can be used in games. Because of this I would be very interested in getting feedback and to hear your response on this work.

I would also like to point out that all of this awfully untested. It would be really interesting to see some Kuleshov-like experiments on the concept and see what kind of results can be made. It might be the case that this hypothesis does not work at all, or it might that it lead to wonderful and totally unexpected insights.

I also want to add that not all kind of experiences can be created like this. The same goes for literature and movies too, where leaving too much up to the audience simply does not work. Non-fictional books is one thing that comes to mind. Still, that is not a reason to not try this out. Before we try out all options that the video game medium provide, we will have no idea what can be accomplished with it.

Additional Notes: In Scott McCloud's book "Understanding comics" two similar "imaginary gaps" are explored in the medium of comics. One is the literal gaps between panels, that forces the audience to complete the missing information implied to be between. This is very much like what is found in books and movies, as it forces the reader to use external knowledge and also comes with a retrospective aspect. The second gap is one of cartoon symbolism, where simply drawn characters often can be more expressive than detailed ones. Again this requires quite a bit of interpretation from the audience.
I think this shows that the features discussed in film and book, apply to other media as well, making me more confident that they ought to play a big role in video games too.

Acknowledgments: This essay has been greatly inspired this post by Michael of Tale of Tales. If not for him I would probably have never started thinking in this direction and none of the above would have been written.