I’m not a big fan of Malcolm Gladwell’s books, but one of the things I read about after seeing a review of his book Outliers got me thinking about my own students.

His book Outliers is based on the research of Anders Ericsson in which he studies the commonalities of “experts” and how they came to be that way. The upshot of which is that it is all about “practice”. Notionally, the book suggests that you become an expert at something by fulfilling a regimen of practice for “10,000 hours”. You can read the research yourself to see how far Gladwell has stretched that notion. The thing is, 10,000 hours works out to rougly 3.5 years of full time 8 hours-a-day work!

To give you a bit of background, I teach part-time at a University in the UK and one of my classes involves a module called Advanced Games Technology in which we ask students to produce a full game for themselves over a two semester period. We don’t really specify much in terms of constraints other than “it has to be 3D” and “it has to use some middleware”. Ultimately it is meant to be a portfolio peice for them, so they can throw all of what they’ve learnt into the game and produce something really polished.

Now I’ve been teaching this module for a few years now, so I’ve started seeing some patterns in terms of student response to this relatively simple and open brief. Can you guess what it is?

Yep, it’s paralysis. Literally, for some reason the sheer concept of starting a project from scratch on this scale seems to throw most of the students into a cartwheel of indecision. My thinking is that this is because up until that point, they have largely worked off fairly strict briefs and fairly regimented development schedules with specialized classes and teaching to support them. But then they are faced with “do whatever you really want to do” it seems what they really want to do is nothing!

Only, it’s not strictly that simple. Because this isn’t just common garden student laziness (anyone who has taught knows what that looks like). This is something else and I feel like it has some relationship to the experitise issue. Which is that they simply have never practiced actually thinking of making a project from scratch for themselves. Or rather, they haven’t practiced often enough for it to be second nature that you have a hundred ideas you want to create and never have enough time for them. Almost everyone I know in the games industry has both done more than 10,000 hours worth of work in their respective roles and has also gotten hundreds of ideas for games they would like to make.

Analysis paralysis

The other issue I think, is that many of them fail to start because they are stuck in the limbo of indecision trying to choose which technologies to build and which middleware to use. I’ve seen this issue happening with indie projects as well. Literally never starting on something because the perfect technology is not quite there, even if one is “close enough”. The main factor is that if you find that there is always a barrier to you starting a particular project (be it a new peice of technology, a new art peice, or a new feature for a game) then you should maybe start thinking that practice in terms of just producing something is a good idea. I used to get that kind of feeling a lot when I was doing my own indie games using Torque. I always found myself waiting for the garagegames.com guys to develop some new technology they’d been talking about so I could then work on using it for my game. That whole notion of waiting for someone else to develop core technology simply wasn’t something I ever had when I was working in commercial development, where we would rather work on our own solutions and not use someone else’s. But the end result was that I had an excuse not to simply practice and make progress even if ultimately I would end up using their solution further down the line.

How to fix the problem?

This is basically a mental blockage as much as anything else. But the ideal solution is to “practice” these things until they become almost like muscle memory. One great way I think to approach this, is to take part in a short term development competitions like Ludum Dare or any of the game jams. At the very least you will not feel like you are the only one to have the blockage. But if you practice throwing together project code and “getting things done” you will eventually get over that hump of not being able to figure out where to start.

Here area few other ideas for practice for programmers:

• Make yourself create small project files from scratch, including setting up all build settings. Create your own libraries from scratch and use them as both static and dynamic libraries.
• Make yourself a testbed project and integrate new technology middleware into it often, write code so that you can “wrap” each middleware so that you can implement new ones in an opaque manner
• Take on a new aspect of technology, in an area you are not familiar with (animation, graphics, networking, physics, engine design etc)
• Practice 2D and 3D, make prototypes that work with similar code across both (thinking in components is good here)
• Work on math skills, practice things like orientations and simple but useful tools like easing. Do plenty of work involving different coordinate frames and transformations.
• Work on interfaces and API designs. Time them and profile them. Look at how memory changes and how different sizes of allocations change the profiles.
• Find a new aspect of the language and implement something new with it. Look at delegates, smart pointers and any new C++ standards features. Study new features in boost and other open source frameworks (POCO for instance).
• Learn a new language, implement a completely unrelated type of project with it than you normally work with (i.e. a database, a tool of some sort etc).

I do think that many companies would actually be wise to give their devs time to practice starting smaller games from scratch too, although it seems fairly rare. But the idea of making quick prototypes and generally not sweating the details of choices or designs or architectures I think is a useful practice as it stretches you to not be concerned with details and instead by productive and experimental. Of course the details matter, but then you can practice those issues seperately. As the Ericsson research shows, the best experts actually use a well thought out practice regime. It isn’t that you simply practice for its own sake, but that you practice in order to learn something new, or to commit to memory some process or practice that you can build on incrementally. In a way you are trying to find flaws in your own process and then factoring in corrections into the overall practice regime.

I’ve recently been teaching myself 3D art skills and one of the things I’ve learnt is that simply practicing things like sculpting (for faces) helps to improve my eye for proportion and anatomy and helps me understand what makes a “good” image. So doing regular sculpting, even if I’m still fairly tragic at it all is good. As I learn the tools and the forms I slowly begin to appreciate the underlying structure and process.

I think we can see code in similar terms. So doing quick and dirty prototypes will begin to show you the underlying patterns we need to commonly use in more complex works. Or will show us some aspect of design we aren’t fully aware of until we actually try and develop in that area.

So my questions to you, the readers of this entry. Have you done your 10,000 hours? How do you approach practice and what do you do to work on your skills and to expand your working process? Have you tackled anything new recently? How did you learn the new area and how can you apply those learning processes to new areas next time?

Now the problem of content is a thorny one. Because many people would have you believe that so-called “AAA” development doesn’t really have a constraint on content. But the reality is that content is a huge part of any game budget and as such it can hit hard on any development budget, be it AAA or indie.

So what is the problem?

In a nutshell it takes too much effort to produce.

The overall quality of content has been rising ever since games first started being played. Moving from single colour blocks in “pong” to sprites in “mario” to fully realized 3D worlds in “Gears” the cost of producing all that content has been rising. Not to mention the skill and time to produce it has been growing also.

As an indie developer, I’ve often been very tightly constrained by my lack of ability to produce my own content. To the point where I’ve looked for alternatives. So I thought it might be useful to enumerate some of the alternatives in this post.

Now let me get this point across before we start. I am NOT advocating that we can ever totally replace artist created peices. What I am suggesting is that there has to be a smarter way to produce *some* types of content. Or at least streamlining the content production process so that we reduce the burden of both cost and effort.

Procedural methods, a potential solution?

As others have talked about before. Procedural methods are a very good way of producing content. Not least because they generally have some designer feedback mechanisms to allow the artistic shaping of content, whilst also allowing the content producer to be vastly more productive.

Procedural methods seems to work best at producing content where there is some systemic structure to it. By this I mean that there are patterns of composition in the content that can be processed to produce variation. So for a simple example, texture synthesis seems like a good choice, because textures have a mixture of varying frequencies and procedural methods are good at handling variations on a theme.

There is a list of texture synthesis tools here

Texture procedurally generated with Mapzone

A good example of a texture synthesis tool (Mapzone) can be had for free.

Whilst texture synthesis seems useful. It can also be augmented by use of procedural blending to allow for more variation. So for instance, a perfectly normal sythetic texture can be aged by adding a procedurally generated “scratch map” texture to it. This layered approach is another key aspect of procedural methods. Adding layers of control into the content allows for variations in the mixing of those layers, again leading to more variation.

The point of most procedural tools is not to replace the artist, but rather to amplify their output. Or to allow rapid iteration on a basic theme in a way that allows artistic choice while handling much of the donkey work involved in the work itself.

Now of course, there are issues with entirely procedural methods. Mostly revolving around the problem of aesthetic quality (procedural methods are great where patterns and rules are involved, but no necasarily where artistic intent is involved) and of the “vision” of an artist being hampered by the synthesis tool. In effect, when you choose a procedural approach, you do give up some artistic direction because you are constrained by the algorithms represented in the tool.

Sometimes though, it feels like that is a reasonable thing to give up to allow for more variety. At the very least, it is reasonable to allow for artistically inspired procedural content generation. A very good example of this approach is apparent in MMO’s where they have character creation screens.

Have a look at some of the examples from this youtube search.

You can have much hilarity with procedural methods too

Most of these character creators use relatively simple techniques. Adding artist created content in peices such that you can swap out individual elements and swap amongst a limited pallete of choices. The point is that if you think of the complexity of the approach versus the number of potential variations it is a very powerful value proposition. But of course, you trade off entirely individualized characters for a more “template” based approach. In essence for all the combinatorial variation allowed, you are constrained within some limitations to allow for it. In a way, the potential spectrum of artistically created works is infinite. But the procedural approach limits you to the number of variations allowed by the underlying algorithms involved in the generation.

So the common approach to character creation. Using the “template base character, plus variations on clothing and accessories/texture” based approach is reasonably common, but as you can see from the Spore crature creator, it isn’t the only method you can use.

Another approach to the generation of humanoid characters, is to allow morph based variation and to allow the blend-space of the morph shapes.

Makehuman example

You can have a look at this approach on the MakeHuman website, although this is not the only tool using this approach. Both FaceGen and Evolver also take this approach. It is a powerful technique because again, the core of the content is based on artist created input meshes (in the form of morph targets). So the quality of the result is based on the quality of the artists involved, rather than the underlying algorithms.

I once saw an internal tool at a certain game company here in the UK that was working on a footaball game. They had made a 3dsmax based toolset for morph based generation of football players using morph meshes and morphed textures. The results were unbelievably impressive even compared to the commercial tools linked above. The approach is capable of making high end and high quality content, if it is fed with high quality input meshes.

The most obvious area for procedural methods to be used, is in the generation of organic shapes/textures/deformations where nature has essentially played the part of the algorithms in shaping the natural world. So for instance grass only growing on relatively flat ground is a great rule that can then be duplicated as a procedural parameter in a generation step.

Here is a nice list of terrain texture generation applications. As you can see, there is quite a lot of choice in terms of terrain and vegetation generators.

One area I have been hoping would see more development is in the area of procedural animation. Specifically, things like automated rigging and procedural animation of walk and idle cycles would be very nice. I have noticed that 3dsMax now has a procedural walk cycle generation within its CAT rigging system. However that is still relatively rudimentary.

There are approaches to procedural animation that involve procedurally generating footsteps and then making a character move along with those footsteps using some kind of forward search and/or with ik based solvers to actually plant the feet. But I’m more interested in actually generating the motion in an artistic sense than actually procedurally generating it in the game right now.

If I get time soon, I’ll check out some of the procedural animation toolsets and post them here. But I think thats enough to be going on with for now!!

Thanks for reading.

The problem

In a nutshell, my problem is “side effects”. To be more specific, side effects of the implementation of code.

I’ll give you an example I’ve been facing to illustrate the point. We’re using an old code base (name redacted to protect the creators) as part of our client prototyping for our latest project. I’m trying to get some animations to play. So I look at the code and within literally hundreds of classes is the “player” class that I need to use. Well, actually, its an “AIPlayer”, which is derived from player, which in turn is derived from:

ShapeBase->GameBase->NetObject->SceneObject->SimObject->ConsoleObject

As you can probably tell, this code base is quite old school in its architecture.

Anyway, back to the problem. I’m trying to get animations to play on a character when they receive an update in state from the server (its an online game). So I find the function “setAnimationThread” which seems to do what I want. Only, it doesn’t do what I want. On an API level it *is* the correct method to call. But in terms of functionality, it has issues. As I debug, it finally dawns on me what is happening. The side effect of parts of the “Player” functionality, is that the player class controls animation state based on movement. But it does it an opaque manner within an “updateMove” method. Effectively the side effect of using the “player” class, is that actually playing animations is fraught with problems.

Let me give you another example, which of these methods do you think is responsible for selecting which animation is currently playing?


updateAnimationTree();
updateMove();
updateTransitions();
animateSubtrees();


The problem is that when you look at an interface, a method or a class, you should have a reasonable chance of knowing what it is actually going to do. In effect, what is happening when you write a piece of code, is that you are forming a contract with the user of that code that you will fulfill a specific purpose. From the example, you really can’t isolate where specific animation clips should be selected. So would it be possible to have a clearer interface?

So how do things go wrong and what can we do to fix the problems?

The main reason I see for side effects to happen in code, is where you have legacy code that has been worked on over time, with other purposes in mind. This is a reasonably common case when you have say a “core tech” team in a larger company, but can happen pretty much anywhere. Most developers do not have the luxury of starting from scratch when they start a project. But the side effects of using a legacy code base, is that often the functionality was not as planned as it should have been and ultimately you often have the case where special edge cases are dealt with in order to ship a specific title. Unpicking the side effects of those last minute bug-fix special cases can be a nightmare.

Another reason for side effects, is that sometimes you simply don’t know what the API requirements for an implementation will be until you’ve tried implementing it. I often have the situation where I will prototype a system up to learn what kind of interface I ultimately will need and just accept that refactoring is a part of improving the product. But sometimes the product ships with the prototype code.

The major reason for side effects though, is when you are trying to create an all encompassing class that deals with all sorts of functionality in a monolithic manner. A sure sign of this kind of thing, is when you cannot actually simply instantiate a class without having it require a lot of setup from other classes.

Now let’s be clear here. I’m not saying that you can always avoid side effects. Or that all interfaces should be instantiable without requiring other classes to setup. But in the most common case, you should aim for simpler class structures and favour composition over inheritance. The reason I say this, is because the main aim here is “separation of concerns”. You are trying to make sure that whatever class you write, only deals with one specific issue. So for instance, the class I should be looking at for animation, should not require any form of movement code, or any form of network code etc. Sure, you can provide it with interfaces to communicate with those systems, but functionality wise, an animation class should concern itself with animation. I should know that if ever I want to debug animation happening in the engine, that is the place to look.

So how do you fix these kind of issues?

The first approach is to design interfaces that express this notion of separation of concerns. All that means, is that when you write code, you write it to fulfill a specific purpose and ensure that you protect the interface from being co-opted to perform other functionality. So for example, you would write accessor methods that return classes that are contained within an interface to perform a specific task. So instead of having a number of animation methods on an interface, you have it contain an animation interface and provide a method to get that interface for external use. Personally I’ve taken to using a component based architecture to more effectively state this notion of composition rather than inheritance and to try and enforce the narrowing of focus, which is definitely more natural in a component architecture.

The second approach, is to use test driven development to help enforce the design. If you consider each class as a mock object, you should think about what you would expect that class to do as a mock. The reason I suggest this, is that if you can design code to work with mocks and still have it make logical sense, then chances are that the real interface has a narrowly focused purpose and is more likely to be separable in a clean way. Separable code tends to be better at not having unexpected side effects.

The main thing here is to understand that side effects tend to come about because code that “says” it will serve one purpose, is actually used to perform functions for an unrelated purpose. It seems reasonable to assume that comes about because either the purpose is unclear, or because the implementation details that are required to clearly serve that purpose are unclear. One way or another you need to address those issues.

This is an ongoing struggle for me personally, I tend to try and work on games that conceptually have quite a lot of unknowns for me, so I often tend to create interfaces that I later understand to be incorrect. Using a component based architecture for the last few years has taught me that components are a great way of narrowing concerns, but that comes at the cost of constantly looking up or cacheing interfaces.

What methods do you guys use to ensure you don’t have side effects in your own code?

I’d really love to hear what everyone else does to try and protect themselves from code with side effects. I’m sure there are plenty of ways I’m not aware of.

In this part, I’m going to cover the concept of squash and stretch and what it can mean for AI developers.

Squash and stretch is very well described in Mike’s post, so I wont go over the artistic principle (that and I don’t want to steal his bouncing ball picture). But the theory is pretty simple, because the original animators were working in a fixed time interval medium, they had to draw elements in a way that suggested deformation and momentum. These images used squash (to suggest momentum being converted to elastic energy) and stretch (to suggest that energy being converted back into kinetic energy). What they were doing was draing the various inbetween states as a rubber ball rebounds off a solid object. The deformations an impact produces gives a particular look as you can see if you study any high framerate photography of rubber balls.

high speed video of bouncing rubber ball on youtube

As you can see from the above video the deformation results in a squashing motion as the volume of the ball is preserved during an impact. This deformation is mimicked in hand animation by simply elongating or truncating the shape of the object in the direction of motion.

A relatively simple visual trick can add substantially to the feeling of stiffness and solidity of an object (or vice versa). Stiff objects tend to not deform as much as softer objects. So you get an inherent sense of the material of an object as it squashes and stretches.

squash and stretch video on youtube

You might find the concept of squash and stretch pretty alien as an AI programmer. Why would we want to deform something that way? But don’t think of it literally. Think about the principles that the animators were trying to apply. They wanted to show that different materials deform differently. They also wanted to show that there was weight and momentum to the motions they were animating. So how can we think of these same kind of principles in terms of AI? Well, one area that seems reasonable to apply this principle to is that of group movements. You could consider that moving a group of units would require a fair degree of deformation of the group structure, but overall maintaining coherence. The group of units could “stretch” out as it moves, then “squash” back together again before finally settling on the overall structure.

But I’m thinking at a more abstract level, we can consider squash and stretch to be demonstrating the constraint of force and momentum within a particular value. By tracking say the amount of help a squad gives to a player in a squad shooter, you might apply the principles of squash and stretch to allow the player to run ahead of the squad (not literally, but figuratively in terms of help) and stretch themselves against enemies, but squash back together to help them out if their forward progress is halted for some reason. You could apply this principle in an AI director to maintain a non-constant helper system, so what would actually change would be that your squad would maybe be less accurate with shots as you progressed quickly, but then became more accurate as your progress slowed.

The main question is to consider how much momentum we want to portray as part of the movement. Another example of a potential application of squash and stretch in AI is the “rubber banding” you might apply to racing games. Clearly this is a very obvious application of the squash and stretch principle applied to the progress of a players race. Good progress is rewarded with the player pulling away from the field and “stretching” them out, but if the player slows down, then the field “squashes” back into place. Its easy enough to see how that actually works in a real race and might be useful to apply in similar areas where one agent is racing against another to accomplish a task.

Squash and stretch perhaps isnt immediately obviously applicable, but hopefully these examples will start getting you thinking about the value of showing the player different types of squash and stretch beyond simply the visuals.

Next time, we’ll have a look at one of the more directly applicable animation techniques and how important it is that we start to consider it as part of building really compelling AI characters and scenes.

Now that we’re officially out of stealth mode, I can talk a bit about some of the things I’m working on at Namaste.

I’m currently building the AI architecture for the project and one aspect of this is the need for an AI server. Building servers isn’t particularly new to me, although it has been a while since I worked on network code. But I thought I’d blog about the various frameworks and tools I’m using to build out the server and more importantly to help me debug it.

Debugging AI is hard enough when you can throw debug data around within a single exe. But adding the fact that this has to be a server, it adds an interesting issue for debugging entity behavior.

The server itself is built using C++ and uses the POCO framework as a method of enabling it to run on both Linux as a daemon and on windows as a service. One of the benefits of using POCO is that it comes with a set of libraries that allow you to run an embedded web server, which is really useful for debugging. But we’ll get to that in a second.

Now poco comes with some pretty well specified logging functionality, which I’m using to create debug logs for the AI. Debug logging is the staple of most AI debugging techniques and can really help, especially when coupled with useful inspection tools. You can see a brilliant example of such a tool in an interview with Mika Vehkala over at aigamedev.com, Mika shows a brilliant tool set that they built for IO interactive that has a sort of timeline approach to reviewing logs.

I think debug logs are perhaps the most powerful approach, but I tend to think a bit more visually. What I prefer to do, is actually show in-game what the AI is doing, in terms of movement selection, path generation, focus of interest etc. Unfortunately that simply isn’t available to me right now because I don’t have a direct connection to the client side as all AI communication is done with a game server.

What I needed, was some method of displaying debug information, such as a dump of the current behavior tree of a character, plus a representation of the world it is aware of, along with positional and other information.

The great thing about networked code, is that you start thinking in terms of distributed systems a lot more. What I needed was a protocol and a client that could attach to the server and pull the information I needed and display it. I already had the embedded web server, so I thought why not try that?

Using a web client as debug viewer

I’d played around with jQuery and JavaScript about a year ago, when I was looking at using webkit as a UI for my indie games. At the time I rejected it because of its lack of animation speed, but the techniques of using JavaScript to create a nice user interface have stuck with me. I decided to try and use a JavaScript based browser client that somehow would pull data from the web server and display the debug information I needed.

So the first thing I needed to do was pull the data from the server. Luckily, that’s actually quite a simple process. All you really need to do, is have a factory method derived from HTTPRequestHandlerFactory that you pass to the web server framework. When you call a specific URL, it goes to the factory method, which then creates a request handler object to handle the request based on the parameters you passed in the URL.

I created a number of methods on the server to respond to the calls I needed. The root “/” call simply presented an interface to the other methods, such as list entities for a world, view the current running world etc. Having a few test handlers in place, I had to get the data back to the client in a manner that would work for the JavaScript end. The easiest method was to simply return HTML content that displayed the appropriate href links. This worked ok, but wasn’t very pretty and I still needed some method of having JavaScript actually understand some of the object data in a more structured way.

Choosing a protocol

I could have used XML data as my protocol, as libraries for that are available both in the POCO framework and my own AI framework, but I chose instead to use JSON format. I used libjson to encode the data in json format (in this case a list of entities) and passed that out as response to a “/listentities” url hit. Unfortunately I hit a snag in that the browser simply wouldn’t let me receive the data. Essentially I was hitting a security feature in the browser that stops it from reading data from a different URL than it had originally loaded.

I had loaded the browser client UI by storing a local HTML file which then references local JavaScript files as I didn’t want to have to deal with sending those files via the web server embedded in the AI server. After talking with someone else at Namaste I learnt that you can use JSONP to get around this particular issue. In a nutshell JSONP is a way to “wrap” JSON data in a script call, which gets parsed on the client as though it is a local script call, thus if you have matching script function names on the wrapped data and on the client you can call the function and pass the data back to the client.

So the functionality is that on page loading in the browser, you attach a script call to a button that creates a new element in the browser dom and then attaches a script call to it. This script call uses a URL which pulls the jsonp data via the URL and calls a script function as callback. The script function runs and then removes the element from the dom. Once the json data is parsed from the receiving function, you can pretty much do whatever JavaScript you want to it. Originally I had some Raphael code I was using to display entities positions as dots on a grid along with debug lines etc. But I’m currently moving that over to using Three.js and webgl to render the entities (which is nicer because then I can add different camera views and the rendering is far more responsive).

Here is how the Javascript code looks:

function parseData(data)
{
// remove the script element so we can recreate a new one
scriptElement.parentNode.removeChild(scriptElement);
var nItems = data.Gobs.length;
//alert(data); //uncomment this for debug
window.paper.clear();

//attach a jQuery live event to the button
$('#getdata-button').live('click', function()
{
// use a JSONP hack to get the json data in a viable format
scriptElement = document.createElement("SCRIPT");
scriptElement.type = "text/javascript";
scriptElement.src = "http://localhost:8080/jsonents";
document.getElementsByTagName("HEAD")[0].appendChild(scriptElement);
});
});

What is happening is that in the handler for the document “ready” event from jQuery, we first create the Raphael object to draw with, then setup a handler for a click event on a jQuery based link. That link calls a url on the server and that server responds with JSON formatted data wrapped in the method to respond as callback. So in this case it might return something like:

parseData( json formatted data here );

You simply ensure that the server wraps the data in the appropriate response method call name. Essentially the client runs the script as though it is native to the client.

What next?

My next big task is to add support for rendering the navmesh of the world in the browser and add support for rendering the paths and avoidance vectors of selected agents. But that is for another sprint. I think the technique of using a browser for debugging the AI will be especially useful as our designers play with the AI representations. There is of course a lot of interface to build up and as we’re still a small team, I’m having to balance working on debug functionality with actually delivering the AI behaviour.

In general I’d strongly suggest considering the use of embedded webservers and browser based code to enhance your toolset. I know that quite a few people are already doing this and it is a relatively easy using libraries like mongoose to support a web interface. I expect that as webgl matures it will mean that more people use this powerful approach. I really want to add some flash based UI to the mix as I think that Mika’s timeline based approach would work pretty well via flash. Plus I think that at some point we’ll need to actually add live updating to the server via this interface and maybe even live editing of the behaviour trees.

A bit of background

Up until recently I have been taking a break from commercial game development to work in education as a lecturer teaching game design and game programming at the University of Bolton in England. I got into this after shipping Worms 3D, the last of a number of worms games I’d worked on while at Team17. Education seemed like a reasonable choice when I had decided to leave Team17 because I wanted to try something completely new and didn’t feel particularly driven to work for another games company in the UK. Team17 had been a pretty good place to work and the guys there were great so I didn’t expect to find anywhere that was better. I had considered taking a job in developer relations, because I enjoyed travel, I enjoyed talking to other developers and I thought maybe there would be some variety to the role. As it happens, the first search I did on google hit the job I would end up taking at the University and it took all of a week to make the change.

I went into education wanting to give something to the new generation of game developers and over that time have had some highs and some lows and I wanted to explain a few of those here so that those of you thinking about working as educators, or those of you working in the industry considering education, or just the academically curious can gain at least one persons perspective.

I’ve been working as a Senior Lecturer teaching across two courses, namely games programming (we call that computer game software development for historical reasons) and games design. Normally I tend to work in the final year because I found it incredibly hard teaching at the first year level. One thing you imagine when you first start a job like this, is that everyone who comes into a university is self motivated, capable of working hard and is driven with a thirst for knowledge. You imagine a ninja army of super programmers and designers who you can mould into an unstoppable killing force of game development. Unfortunately on the whole, what you actually get is much more of a mixed bag of typical late teens/early twenties youth. It really shouldn’t be a surprise I suppose, but the reality is that people come into education for a variety of reasons and one of those reasons is because they simply don’t have the will to do something else. I’m not saying there aren’t ninja’s in the mix, because there are. But the reality is that in any single body of people, you will always find a mixture of motivations and some people have more passion and drive than others. Even within game companies you can see that some people are more passionate about the task than others.

So what is the role of education? Especially a specialized education like game development?

For myself, I wanted to teach people the reality of game development in its raw beauty and uglyness. I wanted to try and make them consider the ways in which game development was changing and to be able to be self critical about not just the development process, but about their thought processes. It’s surprisingly hard for people in the industry to take time and get a perspective on what it is they are doing, because deadlines always come sooner than you would like and work is always much too hectic to allow you to step back and really critique your own thinking. While at the University I’ve been working as a researcher and supervisor and one thing I’ve learnt is that there is value in actually thinking about the development process from different perspectives. Evaluating how we do things with a critical sense can help us identify our own biases and motivations and I think this is a very useful skill we should all learn.

In practical terms, especially in game design, there is value in being able to consider our work in terms of how we evaluate our success. We have pushed our design students towards being able to critique their own work and it is amazing how they change over the course of three years. In the first year, they come in simply as game players, so we teach the tools and techniques of production (level design etc). In the second year, they use that production and are taught more about what to consider when producing (aesthetics, pacing, space etc). In the final year they are taught the value of metrics, evaluation, psychology and criticism. We see a vast difference in the maturity of students within this relatively short space of time. Although I must admit to occasionally getting very angry with them (one particular second year class I was sitting in on some presentations for a colleague and it just incensed me that they had failed to see very obvious flaws in their designs, later those same students turned out to be far more skilled at self criticism as they had matured immensely).

The use of the scientific method for evaluation of game designs is something that we’ve been pushing hard. Things like metrics, psychophysiology and the creation of a core base of scientific research on the effect of games on players and on our understanding of the creation of games has been a pillar of our teaching. Honestly game design still feels like it is based far too much on intuition and far too little on understanding and objective evaluation. But that will slowly change (and thankfully has been changing) as more designers understand the real value of metrics and discover new methods of analysis and construction.

The highs and lows?

One of the low points for me in all of this work, is that the games industry still does not value education properly. Especially not the specialized games education I have been involved with. It is frustrating to hear that people would prefer “comp sci” rather than game programming, because fundamentally they are the same thing, just with a bias towards delivering the problem set in a manner that addresses thinking in terms of games instead of general software. How it can be more valid to teach in the context of say database design rather than in the context of games is beyond me. Luckily the reality is that good programmers are good programmers and people tend to be able to evaluate that no matter the context, so my graduates have been pretty consistantly finding jobs in the industry in spite of the many detractors.

Another low point has been the realization that not everyone who says they want to work in game development is cut out to work in game development. Either because they can’t take the pressure of the work, they can’t self-motivate themselves or because they simple aren’t capable of working at the level the industry requires. It’s sad to say, but the industry is demanding and it really isn’t for everyone so we have to be quite strict when faced with people who can’t achieve the required standard. Strangely enough, you can usually tell within the first week or two of a three year degree who will finish well and go into the industry and who will not.

The final low point is how far we have yet to go in establishing games as a credible subject area worthy of academic study in its own right. Frankly there are very few people in academia that really “get” games and so you have this surreal situation where academia has gone in completely the wrong direction and the games industry has simply not participated in forming that direction.

The highs have come from seeing my students succeed, both in terms of getting jobs in the industry as well as becoming mature thinkers who are capable of really getting to the heart of a problem. There is also my own research, which has changed my own viewpoints as I have taken more time to consider what really interests me. My research is about game characters (which I am calling “digital actors”) and artificial intelligence and actually the act of doing research has opened my eyes in terms of my understanding of my own work and the work we have done in games to date.

Conclusions?

If there is one thing that this work in education has shown me, is that there is considerable value in studying games. The games industry would do well to embrace games education and to become active in shaping its direction, rather than simply taking the best students as workforce. The industry should actively engage academics, many of which do not understand games, so that we all learn more about the things we create. Developers should take time to educate themselves not just in the production of games or game content methods, but in the critique of their own works and the works of the industry at large. There is a lot of work to do before we better understand how to consistantly make games that actually mean something to players, we have relied on licenses and franchises for many years but those will only sustain a very narrow audience, if we want to engage more people, we have to understand more than just production. Study in its broadest sense, involves thinking about what you do. We need to think about what (and why) we do what we do more.

As I transition back into the games industry, I feel happy to have had the experience of education because it has shown me that there is life outside of the trenches of development. As my research goes on and I apply it to the products I am involved with, I gain insight into the subject and I now have the skills to try and analyse that knowledge I have gained. I can start to really understand what it is I’m trying to achieve and evaluate more rigorously wether I am any nearer to achieving my goal.

For those of you not currently in the industry but considering going into education as a means to getting there. I would advise you to really think about why you want to get into the industry. Only begin on this path if you are truly motivated to create games rather than play them.

For those of you in the industry considering getting into education, I would say there is considerable value in the academic process to you as a developer, in thinking beyond your own situation and considering the greater picture. Education can help open your mind by virtue of you simply taking the time to think about the “why” of your own work.

I’m not saying you need a University necassarily to do any of this. Education doesn’t require an institution much like religion doesn’t require a church. You can educate yourself by simply opening yourself up to new ways of thinking and by being active in seeking new viewpoints. Conferences, books, blogs all have a place. Read beyond your own subject, read about psychology if you are a designer, read about patterns if you are a programmer. Begin the process and you will very quickly discover new insights into what you do that make subsequent efforts more meaningful.

Education is very valuable, if you embrace it as part of your life.

I’ve been thinking quite a long time about the relationship between animation and game AI. Most of the people who stay around long enough to let me bore them with it know that its a passion of mine. I thought that I would take the time in this post to start off with a look at where I think traditional animation can give us some pointers towards creating characters that are compelling and achieve the illusion of life.

In their book “The illuision of life” Frank Thomas and Ollie Johnson lay out a number of essential elements they think help to achieve the illusion of life and create compelling characters. So I thought it would be a good place to start. Rather than numerically listing them, I thought a discussion format would be more useful. I’m not trying to say my own personal interpretation of the elements laid out in the book is the sole interpretation, I’m certainly willing to be convinced of other viewpoints and I hope you will add comments if you feel I’ve missed something. So lets get on with it!

Appeal

The core of this notion of appeal, is that you choose characters that fit for a specific role. It doesn’t mean that everyhing is cute, or has specific attributes (although that is often the case), but more that you consider the character in its role. As is the case with traditional animation, you need think about the purpose of the character, how they move, how they think. I think in terms of game characters, we do actually have a pretty good handle on this. Although there are far too many generic space-marine style characters in games, I do think that we have some reasonably strong character designs too, like Mario and many of the other Nintendo characters. There is a lot to choosing characters for games and I urge you to read Katherine Isbister’s book for a better understanding of game character design.

Appeal is perhaps the earliest we get to understand a character, using concept art to draw out the basic outline of the proportions, maybe even thinking through the backstory of the character. Personally, I think that many game companies fail at this stage, often choosing to go with a simple puppet instead of a character. I can understand the thinking, because you will most likely be controlling the character on screen so giving it a personality might not allow you to project yourself into the game AS the character. The bigger question that springs to mind is how important the “character” you are controlling is, do you mentally model the character you are playing with as a seperate entity, or are you actually immersed enough that they are essentially a projection of you? I think we need some study in that area before we truly know that answer. One study we did a few years ago looked at the character design in an RPG (in this case Neverwinter Nights 2) and wether players are attracted to character narratively versus aesthetically amongst other influences. The group that did the study found that even relatively obvious aesthetic changes had quite a big influence on the players interactions with a character. In many ways this is what you would predict, because we often have to try and predict the nature of another person from a distance and we mostly use clothing (for instance uniforms) to give us an indication of how we will be recieved.

So in terms of game creation, I think we can agree that “appeal” is as important to us in the game industry as much as it is with traditional animation.

Staging

In traditional animation, staging is the layout of the scene, essentially its artistic composition, such that the viewer understands or “reads” the scene’s intent correctly. Staging because it is very important for storytelling probably feels like it has no place in games. But actually, when you think about it staging is one of the most important aspects we should address. Staging for games involves how and where we present information and characters to the player. If we present important information out of view, then we fail to achieve our design goals. If a player sees none of the brilliant content we developed, it can be a very expensive affair. A lot of games are moving towards a linear narrative in order to address this issue of high production costs and players simply not seeing it. I think that is a mistake but it has proven very popular with so many games using that approach.

Personally, I think staging can be very useful if we think of it dynamically. If you imagine a case where you have to have characters interact, it really doesnt take much to place constraints on them to only interact when they are being viewed by a player. I consider the AI director in left 4 dead a form of staging, because it controls the scene in such a way that the player is aware of the impending threat. There was an interesting presentation by the guys at Insomniac about the combat mechanics in their latest FPS. What is interesting is that they are almost entirely talking about staging. Considering how the player will view an element of the game and how best to guide them towards the right feeling or understanding is the key to staging.

I consider staging to be another key element of traditional animation that we can apply to game development.

Next post, I will cover more of the animation “principles” that perhaps don’t seem as though they apply to games, but with some thought we can potentially see our equivalent principle. Hopefully at some point we can consider some of our own unique principles, it certainly would be nice to think we have our own basis for creating great game character experiences at least.

Essentially I think what Dan was getting at (and I’ve long since felt this way myself), was that game critique has never developed beyond the sort of intuitive criticism you get from game reviews. Ultimately applying the methods of criticism from other media, in particular media studies, fails to capture the nature of games and the design challenges they face. It feels as though game design is essentially being under served by really directly applicable critique. The kind of critique that could serve to educate designers and spot potential design weaknesses at a structural level.

I teach game design part-time at the University of Bolton, one of the things we try and do on the course is to educate the students in methods of critique and analysis. Things like using scientific research methods, metrics, game theory etc allow us to challenge the notion that all design must be intuitive.

An interesting side effect of this education, is that we often get exposed to game design issues that are a little counter-intuitive. I’ll give you an example to explain what I mean.

Every year, we have a number of undergrad student research groups tackle a year long project to do with a fundamental game design problem. Often these problems are informed by the students themselves, or their perceptions. Other times, the problems they investigate are more foundational or are informed by previous studies. Very occasionally we get an experimental result that throws us into a whole new area of investigation.

One of the most interesting results of this current semester, is a side effect of a group failing to prove their hypothesis to any degree of reliability (in effect affirming a null hypothesis). Their hypothesis was that they could create a level of immersion using various techniques and to test it, they had produced a number of artifacts with various distraction methods deliberately placed to take the immersion of the player away. In effect, they made dynamic changes to the environment that grew more obvious and noted when players saw the discontinuities.

What is interesting isn’t the fact that they ended up with a null hypothesis. But that during the course of their tests, players simply never saw any of the changes they were making to the level. Essentially, the players were so engaged with the task at hand in the test environment, they simply didn’t see any changes that were happening. Now this has some pretty profound consequences for level design that bear some thinking about. What they saw was that players do not actually perceive changes in a level (and reasonably big changes, like colour changes, changing models, adding NPC’s that float outside windows etc).

This research has basically thrown up an entirely new design problem for us to investigate. Namely the degree to which the player is paying attention to their environment in a game, how the challenge/task in the environment shapes that perception and just how far we can push the changes employed before players become aware of them. Of course, we will need to do a follow on study that investigates these issues. I can see the new test being based on quantifying different changes in level between different artifacts. So for instance, will a player notice that they were in a house, but somehow ended up on a boat? Will they notice that what originally was a car, is now a truck?

Game design is full of psychological issues that I think would benefit from more critical reflection, organized study and research. I think that is essentially what Dan was asking for. Hopefully over time we can contribute to the knowledge of interaction design as it is distinct from other forms of design. We may also then see an improvement in the actual games we play, which is my prime goal when supervising these research groups.

Namaste "office"

Recently I started working with a company called Namaste. We’re a small privately funded company working on AI-based socially oriented online games technology. It feels very different working in a startup to my experiences working for Team17 and my own indie stuff. The fact that there are other people around and working on the product makes it feel different than working by myself on my indie projects. The fact that we’re basically living in a house in London and working remotely sometimes makes it feel different than working at a more established studio.

I often encounter people (and we’ve interviewed a few for Namaste recently) that have this strange image of working for some huge corporate like Blizzard, EA or Disney/Pixar. Somehow for many people the ideal work environment is to work on sequels for a corporate machine, rather than to pursue a new, although admittedly riskier venture.

I once had a discussion with a well know AAA studio owner about how he came to be boss of the company and he told me something like (to paraphrase) “I just couldn’t imagine allowing my potential future to be dictated by the whims of someone else”. What he said has stuck with me ever since, because it really speaks to the heart of why I think smaller studios often produce better results. Ultimately, the type of person who is interested in working for a start-up (or building one) at least has a vision to follow. Not a profit and loss statement on a balance sheet to fill with profit to account for shareholder dividends.

Of course indies constantly push the boundaries with new designs, but there is a limit on the amount of effort and reward with truly indie development. My own indie games were always too grand for my own ability to deliver them in a reasonable time frame. So working in a start-up with a few more people opens up many avenues to finally pursue the ideas I’ve long harbored for my own games.

There are downsides to working at a startup though. Primarily the age old funding issue. Luckily we have someone who is willing to help with funding (and finding more) which definitely eases things a touch. The other major issue is simply that nobody actually wants to take the risk of working for an unknown developer on a reasonably ambitious project. Ultimately the bigger effort has been simply gathering people who are ready to take that risk and finding a good mix of experience and enthusiasm.

Strangely enough, it feels like finding quality artists with a solid level of technical ability and the required enthusiasm for pursuing something aesthetically off the beaten track is actually far harder then finding programmers and designers. Maybe there is something about the way artists are taught that drives them towards wanting to reproduce existing work rather than forge a new style? Perhaps it is also an issue of maximizing the potential to be picked up by a bigger developer and only wanting to work for a well known entity? Frankly, I think there’s some value in working for a larger company for most people in that you learn wether you enjoy the corporate world and structure (and whether you enjoy modelling only noses for footballers for years). But ultimately, I still don’t quite understand why more artists aren’t a bit more self-directed and willing to explore.

Anyway, there’s undoubtedly more blogging to be done in the future about the trials and tribulations of this particular start-up. Hopefully at least some of it wont be about crunching on products that are massively over ambitious.

Til next time!

I recently started working with a bunch of guys on a startup called Namaste, which is focussing on the more fictional/social end of game AI and entertainment. One of the aspects of the product, is that we want players to understand the game worlds characters. This means that we have to focus a lot more on the behavioural realism of the character rather than the graphical realism. We are not trying to create “realistic” characters so much as believable. In the same way that bugs bunny isn’t “realistic” but he is still highly believable.

A big part of that believability comes from fairly subtle cue’s and its that I was experimenting with this morning.

After a few minutes walk (its a big park), I decided to try a simple little experiment for myself. I tried to predict all of the people who would respond to my greeting of “good morning” as I passed them by. The purpose being to see if I could intuitively understand and predict what their behaviour would be prior to eliciting communication.

I suggest you try this out for yourself, its a pretty easy experiment to undertake. Before I tell you the results, I will make it clear that there are a few things I can think of that will skew the results:

• I’m a big guy, which can intimidate some people
• I’m in britain, we are socially and culturally expected to be polite, but that might not actually be true for all cultures or even youth cultures anymore
• If I were more attractive, or of the opposite sex to the test subject, I might expect a different response

So what were the test results?

It turns out I’m about 95% accurate at predicting when people will respond. How can I be this accurate? What were the predictors to interaction? Let me summarize them here:

• The subjects who were more likely to respond positively were looking around their environment more often
• The subjects who made eye contact and sustained it for a short period were far more likely to respond positively
• The subjects who were in a group that were already involved in a social discourse responded more positively
• The gait of the subjects who responded positively were more often open and changeable

What were the predictors of non responses?

• A closed gait, basically very stiff movement and a “purposeful” stride
• Looking at the ground, focusing straight ahead, not scanning the area visually
• No eye contact apart from at a relatively large distance
• Visible minor deviation in path, often a stiffening of stride and posture

The point of this was just to while away a little bit of time while walking, but its got a serious element to it as well. Can you ever remember the time in a game, where you could predict the response of a character by such subtle issues? In games, we tend to colour characters in very obvious colours to denote their meaning. So a monster has to look like a monster, rather than actually looking like a very nice character but behaving monstrously (i.e. an attractive murderess). I simply cant remember a game where I could have reasonably predicted the outcome of a social interaction before attempting it, without the character having some obvious affiliation denoted by clothing or due to where it was in the game world.

Game designers will probably tell you that one of the most important things you need to do as a designer is make everything explicit and clear to the player. We use uniforms as a means to denote the function of a particular NPC far more often than we use behavioural character traits. I think its about time we challenged some of these notions, at least to be clear in our own minds where the obvious disjunctions are. How far can we push behavioural believability over simple expression of function? Of course there isn’t an easy answer there. I’m going to be spending a great deal of my time working on such problems, as we push forward with work on animation, characters, expression and emotion in our products.

Why have I brought up this simple experiment? Well, I wanted to put forward the radical notion that the really interesting meat of game AI has nothing to do with what particular flavour of logic structure you use and has far more to do with simple psychology. In fact, I’m proposing that if you are in the field of game AI and haven’t started studying psychology (even at a rudimentary level) then you aren’t doing game AI at all. You’re doing logic programming, which has very little to do with games and has far more to do with linguistics. If you think that state machines, or behaviour trees, or HTN planners are the point of game AI, then I suggest you need to rethink. Ultimately, the goal of most game AI is the creation of either characters for interaction, or systems that support gameplay. Either of those goals I would suggest, are behavioural rather than logical. You want the AI to support a specific set of mechanics, but the goal is the experience of those mechanics from the viewpoint of the player. Similar with characters, we arent necassarily bothered about creating a character so much as the experience the player has when interacting with the character.

In order to understand this experience, you have to at least start taking an interest in how the psychology of the player works and what allows them to understand and interact with your work. Ideally you would also think further and consider the notion that the player already has certain psychological strategies for understanding their world and that if you can tap into those strategies you can provide information in a manner that feels natural and “easy” to understand. Certainly game AI design to me is all about psychology.

If you are interested in getting started on learning more about psychology, I can heartily recommend the book “Understanding Emotions” by Oatley et al which is a good place to start, but trust me once you start down that rabbit hole there really isn’t any stopping.

Anyway, enough of the soapboxing. I’m still thinking about the 12 principles of animation and how they crossover (or not) to games. Will post that another day.

I started working with a group of guys at Namaste recently (http://www.namaste.vg/) and one of the things we’re really concentrating on is AI. Not only that, but we’re trying to push the boundaries of what games can be in that area. Its a great team and I’m really looking forward to dive into the work now, since I’ve been researching and doing academic work for so long.

One thing I came to realize when thinking about the work we’re trying to do, is how much we (and by we I mean game developers) dont know about characters. I spent a good few weeks looking at animation in other media and you can’t help but be impressed at the skills of quality animators of the likes of Pixar. The fact that they consistantly set the quality threshold so high is a testiment to their accumulated knowledge. That accumulation of knowledge is what I wanted to discuss in this post.

If any of you haven’t read Thomas and Johnsons “The illusion of life” I stronly urge you to do so. It essentially lays out the historical and theoretical underpinnings of the traditional hand drawn animation process, but more than that, it details the history of the development of that process and the people who shaped it. It literally takes you back to the first rudimentary line drawings and takes things forward from there. Reading about what is a multi-generational period of learning brings it home to me that this whole issue of characters in games is not going to be solved easily or necassarily in my lifetime. But what it inspires me to do, is to start trying to figure out the principles of the interactive medium when it comes to “believable” characters.

We need to start figuring out the basics of that illusion of life, when embedded in an interactive scene. Of course there are things we can learn from traditional animation, much as digital animation has learnt from hand-drawn animation. But the notion of player perspective changes quite a lot of the 12 principles that Thomas and Johnson describe.

So we’re at this interesting starting point, where there are very few companies really tackling the qualities of “believable” characters. Although many companies can do pretty nice stuff in cutscenes, when faced with interactivity most current games break down in their characterisations.

We’re almost back to first principles: What IS the most important part of a motion when it comes to interactivity? How do we frame it so that the player percieves its importance? How do we ensure the action is viewed? All of those really juicy design/technical problems about character animation and behaviour need to be reinvestigated and understood. Its a tall order for sure, but one that fascinates me.

Hopefully next post, I’ll have more time to go into the 12 principles and what I think we can take from them and where I think we need to rethink things for an interactive medium like games. But sadly that will have to wait.

I believe the reason for the apparent discrepancy has been the very high sales of a new type of game. I’m not entirely sure I’ve traced the origins of such games yet, but I think I can spot one now. It looks something like a game, in that it has characters and worlds and mechanics. But mostly it is actually an interactive movie, cutscenes drive the narrative and you occasionally get to take part if you’re lucky. Games like Call of Duty, Uncharted, Homefront are examples of this style. You can usually spot them, because you get a LOT of really well executed cutscenes. Not only in-engine cutscenes but external cutscenes and plenty of extra dialogue. In general the gameplay is very linear, with a high degree of polish in the experience as long as you play the game as designed. Often the scenes are massively scripted to give that “you are in a hollywood blockbuster” experience.

Clearly, in order to pursue this hollywood experience, the creators of such games have driven themselves forward by advancing visual elements and in general have just put a huge amount of effort into each title. As a game maker, I have to admit an admiration for the creators of such games, because these games are the pinnacle of sheer effort-based development and they really shine. However we are at the point where the industry itself is changing, the shifting sands of the market are moving and these huge developments are having a hard time. Clearly the blockbuster mentality works, but it is a war of attrition. Each title has to sell more than the next in order to justify the huge development costs involved. Because sales of these blockbusters are robust, publishers are prepared to throw money at production, but ultimately a franchise failure will spell the end of any company involved.

The flipside to these hand crafted masterworks are the exact opposite experiences. While they still contain cutscenes, they really are only doing that to appear AAA. These games are the “open world” type games, games where mechanical systems support gameplay and are subservient to the game experience. In these types of games, the mechanics come first, narrative takes more of a back seat and only really acts as an embellishment. For open world games the content is far less directed and linear, which opens up opportunity for the actual topic I want to discuss in this post.

Procedural content.

The first time I was really sold on the concept of using procedural content was while I was working on one of the best selling indie titles of all time. No, I’m not talking about minecraft (although that uses procedural content generation too). It was during my time on the worms franchise that I really bought into the notion of procedural content as a core techique for making games. For those of you who don’t know worms, it features a set of worms (pretty obvious choice there) that fight it out over a set of procedurally generated 2D landscapes. Of course like everyone else I’d been aware of procedural techniques for quite a while, I’d written the ubiquitous 3D terrain that every beginning programmer of the day wrote, I’d experimented with various forms of Perlin noise function, midpoint displacement, diamond squares and the like. But it was only when I saw the Worms landscape editor that I really truly understood the value of procedural content. This editor was basically a level generator, it generated a large bitmap image with 1 bit per pixel if I recall, as a mask for terrain pixels. These pixels were then processed into a byte-per-colour image which was then displayed as the terrain. The sheer power of the system wasn’t merely in the generation code, which I’ll discuss in a second. The thing that really convinced me was in the editor interface itself. In the editor, you could view the currently generated landscape. Around it were a number of variations on that landscape which could be used as a seed to generate more in a certain style. What we had right there was the ultimate power in procedural creation, we had a “preview” of choices which could be experimented with in near realtime.

Worms armageddon map editor

The key to this of course was very simple. At its core the terrain generation algorithm took a series of bits. Each bit in the series having a certain value to a part of the generation algorithm. But the clustering of bits such that the sequence of bits could be varied-but-similar is a key here.

Let me give you an example. If we start with a bit set which displays these bits:

0000 0000 0000 0000

and we break them up into four bit “fields”, then we can allow the user to change the bottom most bits in each field to affect a change to the generation. Lets say the last 4 bits form the “density of islands” value, by allowing changes in that area only, we can affect that specific part of the generation algorithm. If we then save the other bit fields and simply randomize the last 4 bits, we can randomly generate previews for multiple forms of terrain that have varying “density of islands” values.

0000 0000 0000 0001 – might produce small islands

0000 0000 0000 0100 – produces more dense islands, but with the same visual qualities

0100 0100 1001 0101 – produces a completely different type of scene altogether

This narrowing of concerns of the procedural generation is really useful. It means that we don’t get entirely random results every time, but instead, we get semi-random results along a certain style of generation. In effect, we have artistic control of the degree of randomness in the generation function. You may have seen similar interfaces in things like Kai’s power tools for texture generation.

Kai's power tools interface

The notion of designer led procedural generation is a really kep point here. In addition to the random generation, we also had a drawing interfaces where users simply painted into the bitmask part of the level. Then the generation algorithm would take over and fill in the coloured level using the procedural parameters currently set. Aside from a number of naughty words spelled out in lurid textures with christmas themed objects embedded, this gave a powerful interface that essentially allowed unlimited content. The cost of this unlimited content? 2 programmers (1 for the terrain, one for the editor) and various artists for textures and objects to embed in the landscape).

Of course this was more than ten years ago now. And it seems we are still doing lots of what should obviously be done procedurally by hand. My current bugbear being the creation of human characters for games, the cost of which is unbelievably high. Let me ask you this question, what does a human look like? If you consider the variations of human proportions in games, how many do you think we could classify within a reasonable bounds as “normal human proportions”? So if we are creating humans of normal human proportions, my second question is why are we not generating them?

DaVinci's vitruvian man

Davinci shows quite clearly that he understood proportion when he drew the Vitruvian man. Proportions for humans are generally understood artistically and yet people are still spending inordinate amounts of time and production cost actually hand crafting humans. I recently read that one worker on an EA Sports title had spent a good deal of the previous two years working on “noses” for the characters. Why are we not procedurally generating humans? Even more amazing is that we are not procedurally animating them either. Even though human gait hasn’t changed significantly since Muybridge, somehow we still have rig and animate characters by hand. Really? Luckily, people like Ken Perlin are trying to change that with ActorMachine, alongside technologies like NaturalMotion.

I’ll give you an example of the kind of products I think will become vastly more important as we come to face with the impending apocalypse that the cost of content is driving us towards. CityEngine is a great example. It generates cities. It doesn’t try and do absolutely everything, but what it does, it does really quite well. It generates cities using a thing called a “shape grammar”, which is essentially a functional language that declares the structure of a building. With this shape grammer and enough parameters, you can define cities that range from futuristic, to medieval, from rome to paris and points between. But this is only an example of the type of product I am talking about.

Procedural.com CityEngine

Ultimately it is with the indie developers where I am seeing the shoots of inspiration that I feel will inevitably overturn the current production mentality. Minecraft obviously has its roots in procedural terrain generation, but there are plenty of other examples, for instance Overgrowth by the Wolfire guys has some really interesting procedural animation technology.

My own game Damzel uses procedural methods for generating a living city, plus it relies on procedural generation of crowds and will incorporate elements of procedural animation alongside it. Introversion have been showcasing their city generation for a while.

Ultimately, if we look even further off into the distance, work at Michael Mateas’ lab is experimenting with actual procedural generation of game design itself. Not as an entire replacement for the ultimate vision of a designer, but as a means to generate experiments and to quickly iterate ideas. Much like the system I described for terrain generation in Worms, I think the future of games will revolve around technologies that employ procedural methods to amplify the quality and variety of content and allow actual humans to decide on the parameters that determine the end product. Tools such as Allegorithmic’s texture synthesis and presentations such as the GDC 2010 presentation by Epic give me hope that at least some people in the industry are thinking similarly.

The future is procedural because we can’t afford it not to be. So best brush of your copy of “Texturing and Modelling: A procedural approach”, break out your best perlin noise generator, your best random number generator and get with the in-crowd! Go procedural!

So lets agree to put that aside for now and lets talk about something more productive. The need for a scientific method of studying games design.

Now I’ll be clear, there are already people (myself included) who study game design academically. There are even conferences and journals and the like (although sadly they tend to be more of the “media studies” variety and often make me incandescent with rage). But the issue is that pro-rata with almost every other area of creative endeavour, games are underserved academically. Not only that, but the narrowness of the academic study that is going on is typically self-serving and not really pushing EVERYBODY’s understanding of games forward.

So let me ask you an easy starter question: How can you tell if someone is immersed with your game?

Easy to answer? Not really. What exactly defines immersion? How do you actually measure it? What if there are different types of immersion, how do you differentiate how far the player is immersed in the different types?

Currently, I’ve got a bunch of undergraduate students looking at various aspects of immersion, but this is only one tiny sample of the work that needs doing. There are so many aspects of the game design space (lets not even start on the programming/modelling/simulation science) that could be studied. And yet how many labs are actually being funded to do core research in this exciting and growing industry? The sad fact of the matter, is that the games industry doesn’t care for academia. It doesnt tend to fund much research, work to form many labs, offer much in the way of useful feedback or promote the use of academic material within games. It’s an understandable picture, given the shocking lack of awareness presented by many academics. I’ve seriously talked to academics about game AI where they thought we still all worked with state machines!!!

We should be studying players, games and game design

The core of the problem is of course a generational one. Frankly, the people in charge of research budgets do NOT get games. They don’t like them, don’t play them and honestly regard them as subversive and pointless. I’ve come across so many colleagues in academia that have this attitude, or a very thinly veiled version of it. So I can understand that there is animosity there. Likewise when I speak to game developers about academic work, its rare that they have delved very deeply into the well of academic literature on their chosen subject. Although to be fair, I think this isn’t the case with the more senior members of game development I’ve come across, who all seem to be highly academically qualified and/or similarly informed. So maybe its just the young blood who are still getting used to the concept of actually learning that you don’t know it all and that maybe you better go out and read about your chosen subject a bit more. I suppose you could view that as a reverse of the academic problem. Maybe where academics are too old, game developers are too young.

But I want to make the case right now, that we (and by we, I mean both academia and game developers) have a huge amount more to learn about games and interactivity. Real concrete game design issues, such as player perception of characters and wether the experience of playing on a screen alters the ability to percieve emotion from them abound. Every semester (twice a year) I have no problem in thinking of fundamental game design research to throw at our undergraduate groups. We have so much to study, in terms of the fundamentals, that it almost feels like an impossible mountain to climb. So why aren’t there more labs studying games? Why are there more people studying the effect of games on players than there are studying how that effect might be used to create deeper experiences? Why are there not more people studying what games could be?

I will stress that there ARE useful studies being done. A few people at a few labs really do great work. But for an industry that has huge potential both commercially and culturally it feels to me like the scientific study of game design is still languishing in the ghetto. Which is very strange, considering that other areas of academic study have informed games very well over the years. Graphics research for instance has been applied quite nicely in games for generations now. But for some reason it is always something that is not directly *games* that we learn from.

So my appeal is to you as fellow developers to go out and find some academics to befriend. After all, you guys are probably going to be in the driving seat as academics are encouraged to work with you. Give them guidance on what you want, be firm but fair in telling them when they are going down the wrong path. For sure there is a disconnect and some academics are merely working from self interest, but you can quickly get past those and find the people who really care about the medium. Form a strong relationship with academia, not just out of your own self interest (lets face it recruiting people who understand what you want is generally a good thing) but out of the interests of your craft. You will definitely learn something about your own understanding of something by trying to help someone form theirs.

Let us all work to become better informed about game creation, be that technical or design. Eventually we will gather our respective knowledge into a more coherent body of work and will form a method of critque that offers really useful, truthful and insightful thinking about our chosen medium. Ultimately we will make better games more often. Which has the added bonus of a more profitable industry.

My game Damzel is a game set in a city. The city itself is alive with AI-based  people. But I wanted the city to have a nice aesthetic to it too.  Luckily, there’s a good example in Mirrors Edge. I knew it was built  with the Unreal engine, so I decided to see if there was any way to fly  around it and see how they build the levels in it.

And there is!

So I thought it might be useful to fly around  and describe some of the tricks they used in creating such a beautiful  vista, whilst keeping the game running smoothly.

Here we go!!

First,  lets take a look at the basic view you’ll see while playing the game,  notice the blue-ish tones to the shadows? Those are lightmap based  shadows, baked with a lightmap creator called “Beast” by a company  called Illuminate Labs. Lightmaps in case you didn’t know, are textures  that are multiplied with a base colour texture, they are useful for  storing complex lighting and shadowing calculations. In this case Beast  does a global illumination and ambient occlusion solve and stores that  in the lightmap textures. It looks pretty nice I think we can all agree.

So lets take a look at the ground level (its where Damzel will take place, so I was interested in how it works in ME).

Interesting!  first, the lightmaps still look pretty nice at this level. Flying  around the level you notice that many of the buildings are actually  poking through the ground rather than set on it. It doesn’t matter to ME  because its set on the tops of the buildings, but it does look a tad  weird.

Next up are the ambient objects. In this case pedestrians and  cars. There is a central “highway” in this level, which has cars that  run occasionally down the road. Pedestrians also walk occasionally up  and down the paths. One thing to notice, is that pedestrians and cars  run along prescribed paths. They literally follow straight lines, which  while not realistic, makes moving them a lot easier. The pedestrians  themselves are very low poly, because they only contribute a few pixels  to the screen most of the time (viewed from the rooftops). An  interesting aside is the police car flashing light, which is just a  billboarded (facing flat to the camera) flashing sprite texture.

Fly out a bit further and we start to see things getting interesting  render-wise. Most noticable, is that geometry starts getting culled.  The back faces of buildings for instance start getting left out. As do  the paths and roads that arent in view. I’d hazard a guess here and say  it was done by hand, but it would be reasonably easy to do a PVS  (potentially visibile set) calculation and simply pre-process the level  to remove any non visible polygons (test each polygon for views of the  play area bounding box as a first pass I would say).

Above is a view of a building in the middle ground. Notice that  the building itself uses black and white textures? This is because the  distance fogging (see next shot) tends to push the colour of buildings  towards a pale blue as distance to them increases, so it has the effect  of looking like atmospheric scattering. I’m actually thinking of using a  rayleigh/mie scattering term, but maybe just pushing all colours  towards light blue based on distance from camera is enough.

Here’s a shot of the fog volume, its more noticable when you reach  the edge of the volume because you can see the contast between pixels in  the volume and those outside of it.

The interesting thing about  ME leveles is that they tend to have quite contrasting levels of detail  at different parts of the level. The inner “ring” meshes are all  reasonably high detail at the rooftop level near the play area. Then we  have medium detail meshes for the city blocks inside the inner area but  outside the play area. Then we have a sort of “no mans land” which  doesnt even draw the skybox (you can see that here, where it doesnt draw  the skybox/dome and you see overdraw of the inner mesh details). That  is then ringed by a lower poly outer mesh set, which entails a set of  randomly placed buildings and some low poly landscape heightfield  meshes.

Here’s a shot of the landscape and outer meshes, where you can still  see the inner mesh set. Notice the large gap between them? I think thats  likely there to give a sense of parallax with the outer blocks. Whats  interesting is that those outer buildings are literally just boxes with  simple textures on. Nothing particularly fancy about that, although  there is a single landmark building that has a low res environment map  on it (a sort of blue environment map).

And finally, on the outer edges, we have a set of billboard  “skyline” quads with an alpha edged texture of a bunch of buildings in  it. Those are laid out at the edges of the low res mesh area to make  sure you never see a flat edge from any viewpoint while youre running  around the rooftops. They are distant enough and fogged enough that you  hardly notice them, but they do break up the skyline quite nicely.

So it appears that the key to rendering a nice city scene from the  mirrors edge point of view, is the inner core meshes having reasonably  high poly buildings with nice global illumination based lightmaps, many  of them using a single environment map as reflection over a base texture  in the windows. Followed by a lower resolution set of outter buildings  for parallax. Ringed by an further set of flat quads to break up the  skyline, alongside a few heightfields to suggest mountains on one side  and reflected water near the other for added interest.

Damzel is going to use some of these ideas, mainly the LOD “rings”  and the global illumination lighting on the inner ring. I’m not sure the  billboards will be needed, but it will be tried anyway. The pedestrians  and ambient objects like cars will be far more important than ME, so  most of the polygon budget will go towards them rather than the  buildings. So in contrast to ME, most of the buildings will be quite  low-ish in polygons, but hopefully some useful texturing and environment  mapping will help there.

Hope this tour of Mirrors Edge environments has proved interesting,  it certainly was for me looking around the world. I highly recommend  buying the PC version and having a fly around it. Its a masterwork of  level design if nothing else.

.Z.