One of the more popular trends in AAA games right now, is the use of linear narrative to drive gameplay. This works well for AAA because with linear narrative, you can guarantee some great screenshots and movies to drive your marketing spend. The current pinnacle of that art I think is the Uncharted series, which tell the story of Nathan Drake exceptionally well.

The power of the Uncharted series is that the developers Naughty Dog pay particular attention to the characterisation of each main character in the game. Using examples from traditional media they cast the Drake character superbly as a Indiana-Jones style adventurer, which makes the game thematically interesting in the same way that the Indiana Jones movies are.

But of course all this lavish attention to the character is costly. Both in production cost and in design effort. So the last thing the developers want to have happen is for the player not to experience these great production efforts. For the most part, this ends up as a strange mix of camera-stealing, design directing the player and general cut-scene usage that delivers a compelling package, but one that feels incredibly restrictive.

The problem with the linear narrative style employed in the Uncharted games is that you are simply a passenger that occasionally gets to interact (often by pressing a single key to progress).

Unfortunately the linear narrative style has sold so well for multiple games that it has become the de-facto standard for “AAA” development. Lately games like the Call of Duty franchise and even traditionally multiplayer games like the battlefield series have fallen prey. It is understandable, given they have to justify huge production budgets and need to ensure that the production quality plays out in promotional materials. But this kind of narrative is not the only alternative when it comes to the player experience.

Player generated narrative

In creating EverSky, the intention is to employ a very light touch so that players can create their own narrative. The key to this is to never take control away from the player to highlight any particular aspect of the world. But that leaves open the question “how do we tell a story?”. The notion here is to convey an understanding of the world and its origin in a way that allows the player to figure it out themselves. In addition we accept that players like to share their knowledge of a world, so we use that to our advantage and enable this shared knowledge as a core gameplay element. This means that players not only create their own narrative, through their own experiences, but help create a group narrative via a shared knowledge space. Our role as designers then is actually to allow for interactions and to offer ways that players can learn and share this knowledge with others.

How does a player learn something without being told?

There are plenty of experience we can have that teach us something without someone actually having to explicitly tell us. As children we constantly experiment and explore the boundaries of our own limits and we seek to replicate this in the game. So things like trying out new artefacts to see if they have some effect on the world, sharing that with others and exploring the space of things like trade and crafting can help. Having a consistent design philosophy and set of themes that underpin the design choices is also useful, in EverSky themes such as “exploration” and “entropy” guide the choices that affect player experience and world design. Similarly the inhabitants of the world are crafted to allow them a level of autonomy that is unpopular in linear narrative games. This allows for some level of emergence, but also promotes the notion that the characters are actually self-aware and have their own purpose to be in the world. Taking this “world centric” rather than “player centric” view of design is definitely not in keeping with the linear narrative style.

As a boost to people who prefer linear narrative, we can also seed artefacts that may be activated by the player to impart knowledge or produce an effect. Similar to picking up a book and deciding to read it, we give the player choices that let them participate in the designed narrative, or simply ignore it and continue with their own narrative.

Sandbox play by it’s nature is about exploration of possibilities, so we embrace that concept with mechanics that allow players to explore the world and its nature. In essence the world itself becomes a big playpen with learning part of the core of the experience.

Does it work?

This is the big question and one that is as yet unanswered. As we get further along in production we might have a better feel for the outcome of this style of design. The feeling so far is that it will be a problem for a set of players very well versed in being told exactly how to experience a game, however there are players (such as those that prefer real “roleplaying”) that are more open to a more sandbox play style. The wider question of non-linear narrative still requires further experimentation within the game world before we can definitely say that it does work as intended.

You can follow development via youtube to learn more:

http://www.youtube.com/zoombapup

Or get in touch via twitter @zoombapup

Thanks for reading.

.Z.

Posted a video to youtube to describe the direction for EverSky (which is what Damzel is changing into).

Click here to view the embedded video.

If you ask anyone with a passing interest in AI and more specifically in AI in games what is the most important aspect, you will probably be answered with something relating to logic. Logic and decision making seems like the most important aspect because it drives behaviour after all.

But in this post, I want to put the case that actually logic is really not a problem for games.

Of course, we rely on some system of decision making to exist, but what specific flavour it is doesn’t much matter. A good number of games have been created using simple finite state machines, although these days you would expect those to be heirarchical. A lot of more action oriented games use Behaviour Trees, which is the system we have implemented for StoryBricks and you can learn more about them here. Other approaches use goal based systems such as Goal Oriented Action Planning and Heirarchical Task Networks.

But no matter what structural system you choose to represent the problem, it essentially boils down to a simple statement:

if <condition> then <action>

Of course, the number of conditions and actions available can be very high and the conditional tests and the execution of actions can be quite complex. But we have this fundamental architecture of the above statement.

Ultimately, the structure we choose doesn’t matter, we are simply executing a program which controls flow of control. With more or less efficiency and ease of authoring.

So if we accept (any not everyone reading this will, granted) that action selection is not the core problem, then what is?

My assertion is that what is key AI especially for “believable agents” work like StoryBricks is animation and movement.

Imagine, if you will, the following scenario. You are walking across a field and come across another fellow. He is looking intently at the ground. He does nothing except look at the ground. So the question is, what is he thinking? Why is he looking at the ground? Is it:

• He  is interested in the composition of the ground
• He is afraid of you and is looking at the ground to avoid your gaze
• He is somehow compelled to look at the ground

Which of those statements is true? Unfortunately given so little context, you simply cannot know why he is looking at the ground.

What if I said “he is the queens geologist and has been tasked with finding gold for a new crown”, would that allow you to choose from the list?

What if I said “he is your sworn enemy and has no means of defending himself”?

The point is, that without context, it is impossible to understand the intent of the action. For all the complexity we could put into the <condition> part of a if <condition> then <action> statement, we have to be able to understand the <action> part in context in order to understand the <condition> part.

Thinking about traditional media

Now if you think about cause and effect in other media like books and film, it is pretty easy to understand the cause, because it can be explicitly expressed. Consider the following narrative:

“The gunfighter put the empty whisky glass down on the bar and stepped out of the saloon. He walked down the creaky wooden steps and out onto the hard dirt. Dust kicked up with each step as he walked, his spurs chiming on the ground with each footfall. When he got within pistol range of his opponent he stopped. For long minutes he stood silent and still, his only movement a slow flex of his hand above the gun in its holster. A bead of sweat drifted down the side of his face, he was at a disadvantage he knew, because the sun was in his face. But the wide brim of his hat sheltered his face from the harsh blinding rays of the noon day sun. He waited and watched, coiled like a spring, a deadly serpent ready to pounce at the slightest movement”.

(apologies for any real authors btw).

So, given that narrative, you can picture a scene. You understand there is a gunfighter and he has an opponent. You can start to evoke a sense of the scene and what it might be like using your own knowledge of that context, which has been learnt over time from other examples of this behaviour. What you can’t get from this narrative is exactly why he is having this gunfight.

If we continue:

“He had thought of this moment for a long time. His had played the scene out many times in his mind, ever since he had heard about how his wife and children had been brutally murdered. He had spent many years tracking the band of outlaws that were involved in the killing. One by one he had silenced them, with only this last foe remaining. It wasn’t “justice” he was seeking, even though he wore a badge that legitemised his handiwork. This was pure sweet revenge, the brutal slaying of his innocents met with equally brutal punishment.”

Adding that context to the narrative makes you understand the motives behind the actions. It is one of the most powerful aspects of books, in that it can go into great detail and really involve the reader in understanding the psychology of the actions.

Films have a different vocabulary, with a more visual way of telling the same tale. Consider this set of storyboards:

protagonist puts down his drink

And steps from the bar into the street

He sees his foe waiting for him

his spurs chime as they hit the hard packed dirt

He stands facing his enemy

The sun beats down hard

A bead of sweat runs down the gunmans face

He stands motionless, his hand ready at his gun

his mind drifts back to the day they came

his wife begging them for mercy

begging for mercy in the face of their guns

and receiving none

The placement of camera, use of lighting to set the mood, adding music and all the many different aspects that cinematography bring to the table to express the same notional scene still allow the same story to be told.

Now consider this scene in a game. By this I mean in an actual interactive scene, not in a cutscene. Hard to imagine isn’t it? When the player can look anywhere, you can’t rely on them seeing anything. If you place the player as the protagonist, you will most likely have a hail of gunfire within a few seconds. If you place them as a bystander watching the scene, the player will most likely stand in front of the protagonist or just generally “get in the way” of the scene.

The fundamental problem, is that scenes like this are really evocative in the traditional linear narrative media like books or film, but fail entirely in games unless they are controlled as they are in cutscenes. Interactivity simply breaks down too many notions that are evoked in scenes like this.

The language of interactivity

So if we accept that some forms of dramatic content are simply not useful for interactive storytelling, what do we put in its place? That is where StoryBricks comes in. The conceptual issue that StoryBricks addresses is the interactivity relationships between NPC’s, players and objects.

In the interactive medium, you are not simply watching a narrative unfold, you are the narrative. Your actions and interactions are the fundamental control scheme for the narrative of the world as you experience it.

Consider this. If you were the lawman/gunfighter from the scene above and had been going around the land taking part in pistol duels with the people who killed your family, what would it look like to an observer who was casually watching your actions? What if you actually roleplayed the gunfighter? Would the observer understand the narrative of the world as it unfolded and what kind of experience would they have had?

Going back to the case of the man looking at the ground for a moment. What I am saying is that there is an issue with the players understanding of the intention of the actions of an agent. So my suggestion is that the important part of game AI, especially for believability, is that. The understanding of the intent is the key, not the actual formulation of the intent.

Let me give you an anecdotal example. In this video Wil Wright talks about one bug they had in “The Sims” where NPC’s would randomly set on fire. The players of the game made up different explainations about why it was happening. Was it spontaneous combustion? Was it something they had done?

We joke in the game AI community that the best initial approach is a random one. But this is actually true, in that we can often convince players that actions have considerably more behind them than is actually the case.

I once saw a fantastic presentation by Baylor Wetzel that highlighted this issue. He took a number of different algorithms for choosing patterns of attack behaviour in a wizard duelling prototype he had written and asked his students to identify them. It turned out that we are actually pretty poor at judging the cause of actions when any reasonably complex pattern is used. In this case, random is almost as good as complex pattern because if the pattern is complex enough, players will have trouble discening the pattern to the point where is essentially *is* random to them.

So when we are trying to make players understand the actions we give our NPC’s, we have to be doubly sure that they are capable of understanding the motivations for them.

How do players understand characters?

The player’s reading of any given action is coloured by many things. One of the strongest being the actual visual look of the NPC. We had a team at the University do some work a few years ago where they looked at the interactions between a group of test players with a number of differently designed NPC’s. The theory was that empathy could be induced by character design and behaviour. It turns out that a large part of the empathy players had for characters was based on their appearance.

In traditional animation, this is actually formalized as a concept called “appeal”. The psychology of this is quite well understood. Most appealing characters have open faces with large eyes and round heads. Often animation will use childish or “cute” proportions. But aspects such as clothing,posture and gender will also contribute to the appeal.

The second most obvious and important factor is movement. When I say movement, I am talking about things such as posture, gaze, gesture etc. The fact is, we communicate a vast amount of our character non verbally. We communicate with our facial expressions, with our gestures, our gaze and our posture far more than we communicate with actual words.

The psychologist Albert Mehrabian suggested that we communicate a huge amount of our emotional intent non verbally. He spoke of a 7%-38%-55% split between verbal, vocal and visual language respectively. The suggestion being that we use more than just words to understand the true intent of an interaction. Which is confusing, given that most games rely on textual or verbal dialogue to communicate intent.

Think about RPG’s and how dialogue heavy they are. Think also about how often you simply click away these dialogue items. Simply “hoovering” the options to set some flag for later progress.

If we accept the notion that players understand characters intention through movement, then how can we improve the players understanding of the man looking at the ground?

Let’s consider each case in turn:

He  is interested in the composition of the ground

This one is relatively easy. You could have him walk around, looking at different areas of ground. Occasionally stooping to pick up a sample of dirt. You can use a prop that he brings out to look more closely at a sample. You could have him lift up stones on the floor and look under them. You could have him holding a book and comparing the sample to a page in the book.

He is afraid of you and is looking at the ground to avoid your gaze

Again, this one is relatively easy. You would have him use occasional glances up at you and quickly back down again if you are looking in his direction. You could alter his posture to be more wary and frightened. Perhaps supplicating himself with gestures and hand wringing. He would seek to avoid eye contact, but would definitely look up often to make sure you weren’t about to attack.

He is somehow compelled to look at the ground

This is the easiest one of all. You would fix the bug that made him look at the ground.

Conclusion

There is a great deal we don’t know about this whole conceptual area of interactive storytelling and drama. We intuitively feel that traditional media approaches to narrative break down fairly quickly, but as yet we haven’t built up a good enough knowledge of the principles we need to apply to the new medium of interactivity. We can definitely learn a lot from psychology and the principles involved in other media, like film, books and animations. But there is still a lot to explore.

StoryBricks as a concept, is a step towards exploring this new space. Of course the bricks themselves are just a small part of that space. We must investigate new methods of understanding the animation, behaviour and psychology of interaction.

Hopefully some of you reading this will come along with us as we explore this space together. As we develop the toolset, we will learn a lot about our understanding of characters, our ability to create performances that are comprehensible to others and perhaps as importantly we will learn how to create deeper and more meaningful experiences because of what we learn.

While most of the guys at Namaste are reasonably highbrow (well, ok, I’m talking mainly about Stephane and Brian, who are both pen and paper roleplay geeks) I’m actually a bit of a low brow kind of guy. I’m not quite at the level of enjoying fart jokes, but I do enjoy a bit of comedy and deviant behaviour.

So I wanted to explore with this post, some issues I’ve been wrangling with myself about. Namely, how do we use the storybricks toolset we are working on, to create characters rich enough to be funny? Or to be interestingly flawed and/or deviant?

I started thinking about characters that were both funny and broken. One of the characters that popped into my mind was Talkie Toaster from the brit comedy Red Dwarf. Here’s a clip.

Click here to view the embedded video.

As you can see, he’s a chirpy breakfast companion that is delightfully broken and just a little bit hot bread product obsessed.

There’s something inherently interesting about a character with an obsession for something, but even more so for a character obsessed with something other people wouldn’t be. But how do we go about designing a system that a) actually allows a character like that to function and b) lets the user of the storybricks easily express that type of character?

Making obsessive characters

The (a) part is actually reasonably simple. We employ drives to give characters a purpose. Drives can be things like “do your job” or “protect character x” or “aquire x number of resource units of y”. Drives fight with each other for importance during action selection, which means that we compute how intense the drive is for each occurence and choose the highest value as the priority to pursue. Of course these drives change over time and as events occur, so that characters can react to the world and other characters. But fundamentally we are modelling the self-interest motivation that occurs in human behaviour. Of course there are many different drives, so for instance much like in the sims we might have drives to achieve normal bodily function, like eating, sleeping and going to the bathroom. But it is the more complex drives, like the need to attain social status, or the need to protect another character from harm, that allow for richer meanings to occur.

Getting back to the method of making drives work for this pupose, we can simply make the drive artificially high, indicating an obsession. This would simply select something that would occur naturally, but select it more often and with greater vehemence to keep moving towards achieving the resolution to that particular drive. This brings up an important part of the answer, which is that there is a notion of “expected reward” for fulfilling a drive. All this means is that when you choose to do something, you choose to do it with some future expectation of the gratification involved in that fulfillment. So for instance, I might take on a particularly arduous and complex task, with the expectation that the end result will be gratifying.

One of the interesting things about humans, is that we tend to function not simply from pure logic, but from logic that is altered with emotional experience before we make decisions. This means that instead of simply selecting an action via some logical step, we apply some emotional processing to the selection such that the emotion helps us choose. This is needed, because some choices are unknown and we need a method to still make a choice, so emotion gives us a push in a particular direction. But perhaps more importantly, emotions give us some warning that choices are actually not good for us. A classic example is told by Antonio Damasio in the book “Descartes Error” where he recounts the tale of Phineas Gage. Gage was a rail worker in the US who was helping build a railroad and one day had an accident that damaged his brain. The area of brain damage did not effect his logical function, memory or reason. But it did damage his emotional processing. What happened after the accident is a sad tale, but essentially it ended up that Gage was no longer able to apply emotion to his decision making and as such made poorer and poorer choices for his actions because he had no way to “feel” about the correctness of the choice and its consequences. He couldnt tell when a deal he was entering into was a good one. He had no feeling for the mood of other people or when he was being used.

I point this out, because it is important to understand how emotion colours action. Just as we have drives for our basic needs, we have drives for our pschological ones too. I’m not sure about the definition of clinical obsession, but it seems reasonable that we can express obsession within the system by applying both a hightened drive for the item being obsessed about, plus a more intense emotional reward for the attainment, interaction, or ownership of that obsessive item. Basically, we model in a simplistic way, the human behaviour of obsession.

How do you author obsession?

So getting to point (b) earlier. How do we create storybricks that allow us that level of control?

My first thought, is that we have modifiers on “wants” bricks. So instead of “x wants y” we might have “x wants y *how*” with the *how* being something like “obsessively”. The same could apply to “x likes y” and similar bricks too. Obsessive relationships that are one sided tend to be quite dramatic after all.

But I’m not entirely sure that’s how people express notions such as obsession when they think of authoring. “Jane is obsessed with reading the Harry Potter books” is a simple statement, but how would we express this in terms of bricks? Is she obsessed with reading, or is she obsessed with Harry Potter, or books, or only reading Harry Potter books? Clearly the latter is the intent of the statement. So the brick might be something like “jane wants to” whereis an action she can perform andmodifies the drive of that action.

So it suggests that actions are actually compound. “Read” might be an action, but it only makes sense when applied to one or more books. So maybe the “Read” action part of the “Wants to” brick has a compound that gives the things she wants to read. But also allows for the action to be modified.

There are a lot of things we need to figure out in this way. Both from an execution perspective, so that we can enable the characters to perform the action, but also at an author level, to allow the authors of the story to actually direct it in a way that makes sense. I’m sure that part of our ongoing feedback loop will help us refine the latter, which should help us improve on the former.

So what other types of characters would you find interesting? I’d love to hear the kinds of characters you find interesting so that we can start to form the tools to help build those characters.

Eric Heimberg did a great post about the state of the art for NPC’s that can get us started. But it would be great to hear about more characters you would find interesting. Also, how do you describe those characters and how do you think you would want to describe them in terms of bricks?

Comments welcome as always.

I was at the Paris Game AI Conference last week (www.gameaiconf.com) and had a great time yet again. Speaking to all types of AI programmers is always fun.

One thing that I kept getting asked was “what are you working on at Namaste” and everytime I had to stop and think how to describe what we are making. Not that it’s hard to tell what we’re making once you see it, it’s actually pretty easy to understand. But the terms we might use to describe what it is, have been co-opted to mean something else. We are working on a game that involves social interaction with AI characters. Every time I thought “social AI based games” it would just remind me that now “social” means “facebook”. We are NOT working on a game for facebook, even though I personally see nothing wrong with that and I’m sure we’ll make the game available via facebook in some form eventually.

I’m actually obsessed with the notion that I can help make characters come alive. Much like an animator would do for film, I think as a programmer I can help (along with our artists) make a character that is alive in an interactive way. The focus for me, is to create an online world where I can enjoy the company of other players, but where I can also feel part of a larger world. Where the characters that inhabit the world are not just dumb pawns to be used to sell items or to collect quests. Where each and every character has a tale to tell, has a life and a background, loves, hates, goals and drives.

There are already plenty of games that allow people to do the typical MMORPG thing. Plenty of combat and action oriented worlds, where grinding and item collection is a key part of the world. I’m just not that interested in creating one of those. Honestly, I prefer the action mechanics of a first person shooter to the typical item quest style action of an RPG. What I’m more interested in, is the ability to actually feel like the world is allowing me to play a role. That I’m part of a story and can explore the world while the story unfolds, where the drama of the world evolves over time and where the mechanics of play in the world are less about accruing items and more about social play. Which I guess is why I’m here working for Namaste.

You’re probably at this point thinking “second life”, but you shouldn’t be thinking that. Social play can mean a lot of things, we can have many interesting mechanics that work beyond just “hit X with Y” all the time. If anything, you should think of Minecraft and its simple mechanics and the amazing potential when you combine them, or the sims where you can interact with the characters in the world. The possibilities for making a deep and interesting world, full of rich characters that are capable of working towards their own motivations drives me. This is a big experiement for us, in that we really don’t know what the end result will be. We know the aesthetics we are aiming for and we know the technical aspects, but as a game design? Well, nobody has done any of the things we are working on before, so its all new and open to change. I can say that I will do my best to make sure that players in our world feel that sense of awe that many of us felt when we started playing our first MMO (mine was everquest).

Anyway, I’ll blog more about the guts of the AI system as the product takes shape. I’ll also maybe talk about some of the things we want to do in the longer term.

Phil.

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

If you ask any programmer what is the thing they least like to work on, its likely the one thing they really don’t like working on is user interface code. Luckily there are tools that can help.

The problem is that when you are a programmer, you are taught to seek function as your primary concern. If you ever look at most programmer’s efforts at designing user interfaces it generally ends up as huge banks of similar looking buttons all set in regular grids, columns or lists.

While working on Damzel, I’m aware that with this game every single part of the experience matters. Working out the design aspects of most of the gameplay I can do (I have enough analytical approaches to attack any given problem and if I’m unsure of myself I can always turn to friends for feedback) but user interface work is still something that eludes me. Luckily, Damzel’s user interface is based on LibRocket which is a great user interface middleware built using the same core techniques as HTML/CSS. So as I was searching for information on those, I noticed Ryan Burrell posting on twitter that he was looking to help some indie developers out, that he had HTML/CSS experience and UI design skills.

Our first port of call after I’d explained the game’s design to Ryan, was to get a few mockup’s sorted out. Normally, I’d approach this thing by creating something on paper, or by trying to mock it up in photoshop. Ryan used a firefox plugin called Pencil to design what the web-world knows as “wireframes”. That is, user interface mockups with rough positions and data in controls.

Here’s the wireframe for the agent setup screen as an example:

Squad/Agent setup screen wireframe

As you can probably see, the intention isn’t to create a fully working prototype, or to have any sort of detail. The idea is to quickly iterate over the rough positions, the data being displayed and to study the flow through the interface. Does it do what the player expects? Does the player know where they are in the menu and where the options take them? Does the most important part of the functionality show itself clearly, with options being clearly less important but still be obvious?

It is really hard for us as game developers to deliver what we think is a perfect design only to see users completely hate what we have produced. Either because they don’t understand it, or they can’t get it to function as they expect. That’s something that web UI developers seem to have a great handle on and something I’m hoping we can apply to the UI design of Damzel.

Damzel chapter select wireframe

I’ve been pretty impressed with this way of working. Pencil seems like a great tool to help prototype UI’s in that it can allow menu flow, give overall structure and layout hints without getting bogged down in specific details. Plus it can help with outputting data for when it comes time to code up the interface for real.

Heads up display mockup

The great thing about this approach, is that we can iterate really quickly. Damzel is a pretty information heavy game by modern game standards, being based on older games like Syndicate really means that we have the issue of taking the information and updating the interface to match modern UI design standards. Having the ability to experiment with different flows and layouts is a very valuable method to help us deliver on the experience. Of course the next part of this, is to get an implementation working once we are happy with the design and then do something that web developers do a lot of (yet isn’t really done a lot in game development for some reason) and that is to do a usability evaluation of the interface we’ve designed!

Until next time!
.

I read with great interest the recent leaks of details about EA’s “Project LMNO” over on Rock Paper Shotgun.

Although I’d heard of the game before, as a fellow AI Game Programmers Guild member (Borut Pfiefer, who is now an indie working on Skulls of the Shogun had worked on it). It was interesting because it seemed to bear many similarities to my game Damzel.

At the core of my initial concept for Damzel lay the idea that I wanted to explore the relationship between the player and an AI character. My motivation was to try and make the player feel in some way emotionally attached to the character. I described the game as ICO meets Syndicate to myself, because ICO was one of the few games I’d seen that actually tried to make the player empathize with another character. Also, it was interesting because I loved the aesthetics of Yorda, with her frailty and innocence. The reason why I view it as a melding between this emotionally charged character partnership and what is essentially a bleak futuristic view of a dystopian future ruled by corporates is because I felt that the characters needed a driver to make them interact. Plus I was thinking about the issue of how to engage the player in a risk/reward cycle that didn’t necessarily involve direct interactions with the AI girl.

LMNO is interesting, because it seems like it was exploring this very ground. Ground that is very dear to me, both academically and from a creative viewpoint. LMNO from what little information I had heard, stood in the ground that was laid out very well by the likes of academics like Michael Matteas and the team at Carnegie Melon University, when they were working on the “OZ Project”, the papers from which you can see here. For those interested, there is a very good position statement laying out the motivations by Michael here.

Fundamentally, LMNO spoke to my desire to create “believable agents”. That is AI based characters that feel “alive”. A subject that has gotten me animated for several years now. Frankly, the believable agents idea has never really been explored commercially in the same immersive environment I’m used to. I play FPS games a lot, because I feel that I often start to lose that sense of self. I am immersed so deeply in the game that I am not the me sat in front of the computer screen anymore. I always envisioned the types of environments that could work if they were actually populated by characters that reacted to me in a lifelike manner. How much more immersive if the game world actually had some inhabitants?

Clearly, I was not alone in that idea. Sadly, the academic version of this wish is somewhat less that compelling due to the sheer lack of production budget. Which is why LMNO honestly offered a clear chance to explore that notion with the same high production values that modern games can demonstrate.

So why did EA cut it?

That is definitely an interesting question. Could it be that ultimately trying to create a truly lifelike AI is simply not feasible yet? I don’t think this is the case, because I happen to have seen some pretty convincing non humanoid performances in game AI agents. An extrapolation of the techniques used in World of Zoo by Bruce Blumberg (MIT) would seem reasonably capable of at least a cursory illusion of life.

So it seems that something else may be at play. Which got me thinking about potentially the failure being a design issue. That somehow the developers were unable to craft a gameplay experience based around the notion of two characters interacting. Certainly, I understand from my own efforts that embedding that character interaction as a core design element of the game is challenging. Indeed it could be this that ultimately made the game get cut. Somehow, it needs the character interactions to be meaningful to the player in the game world, whilst not simply turning those interactions into the equivalent of button presses or tasks the player performs by rote in order to activate the behavior of the AI. If the character interaction essentially becomes a mute version of a dialogue trigger, then nothing has been gained with the production and animation effort involved.

So I have a reasonable amount of faith that the failure was not simply a design issue.

So what do I suggest ultimately spelt the demise of LMNO?

I speculate, that ultimately the project failed, because EA is at its core a “traditional” game publisher. It understands game development enough to be able to create products. It understands production processes and management of budgets. It does not understand experimentation, failure, iteration and ultimately it doesn’t understand creative risk. I can imagine a project so risky as a game involving emotional ties between a player and an AI character was simply too different to its normal way of doing business. The fact that EA actually undertook the project is testament to the power of someone like Speilberg to attract greater than normal acceptance of risk. But ultimately when push comes to shove, EA is a business founded on making money as its main goal. If the business side cannot understand a game after two years of development, it is quite likely they will consider the risk of trying to sell a game they don’t understand too high.

Not that I blame them. The overall concept is highly speculative. It requires a leap of faith, where big business is stoically atheist.

So where does that leave the concepts behind LMNO and how does it relate to Damzel?

My own feeling, is that the only way this kind of game is going to be proven, is when an indie does it. I feel that the risks are high, but the creative rewards will be potentially higher. The closure of LMNO has at least given the public at large a chance to consider the possibilities of an empathic AI experience. The feedback on RPS and other sites seem to indicate that players are receptive to some of the concepts shown. In a way LMNO has pre-validated my own choice to work towards creating a game that truly explores the possibility that empathic behavior might bring. Of course there’s no way I can possibly spend the same amount of budget as EA on an indie game, but I don’t think it truly matters. I think players are capable of seeing past potential constraints if the overall experience is compelling enough. I believe that Damzel will ultimately prove to me that either I’m right, or I’m completely barking mad. My life savings and much of my next few years will prove the concept one way or another. Although the experience wont be as well produced as LMNO, or likely as polished, it will at least explore that design possibility space.

So, maybe this is one clear cut case where a small indie developer, with all its myriad constraints, has an advantage over the behemoth publisher. In that we can explore complex and game-changing concepts without the shackles of tradition, business opportunity or egotism.

Hopefully sometime soon we will all know if I’m right.

This last month or so I’ve been working on squad control for Damzel. Squad control is perhaps the most important part of the game, because you spend most of your time doing it. It is important enough that it was worth spending those weeks trying out different control schemes and looking at the problem from different directions.

One aspect of the squad control is how to actually move the squad around the world in a coherent manner. Luckily this is an area that has been studied in quite some depth in the general case of multi-agent steering, so there were plenty of ideas to draw on. However there are fewer game specific cases described well enough to take anything away from them, with the exception of Chris Jurney’s article in AI Wisdom 4(?) on the squad movement he implemented in Company Of Heroes.

I dont want to get into too much technical detail here, but if you are interested, you should be looking at keywords like steering behaviors, reciprocal velocity obstacles and helbing’s social forces model. That should get you started down the rabbit hole that is crowd simulation and navigation.

The problem is that essentially, you want a squad of agents to be able to move freely around an arbitrary 3D world. A world which can have both static and dynamic obstacles, with various forms of representation. The whole area is a PhD in itself (well, actually several I’ve read so far, but I digress), but I prefer to think of things from a social moddelling perspective. There’s a paper by Helbing that described a “social forces” model for navigation.

For all intents and purposes this is what you get with Craig Reynolds steering behaviors, which is what I’ve been partially implementing. I implemented some of the steering behaviors partly because they are exceptionally simple and partly because I wanted to test some ideas out. I added a seperation force, which keeps agents apart while moving, essentially adding a force that repulses both agents inversely proportional to their distance, so the closer they come together the more they are repulsed away from each other.

Seperation isn’t enough to get agents actually moving in any sort of human like way though. In order to do that, you have to consider the issue of avoiding other agents. I implemented a reynolds-like avoidance method which you can see in this video.

Click here to view the embedded video.

As you can see from the video, there’s another problem at play here. In this case, I’m only ever avoiding the agent that is closest to me in terms of its time to collide with me. Ultimately this isn’t enough because when you are actually moving through a crowd, you are taking into account ALL of the crowd you are aware of, as well as considering things like the density of crowd in front of you, the social makeup of the crowd in terms of friendly, enemy or unknown, plus the usual navigation like how much you really want to go in that direction.

There’s a technique for handling many agents moving within a crowd that works quite well. This is called reciprocal velocity obstacles (RVO) and it uses some relatively easy to compute mathematics to create a known point in velocity space that you can achieve collision free movement. However RVO’s literally only deal with avoidance and don’t take into account social preferences or crowd density.

Ultimately, I’m heading towards an implementation which uses a sampled RVO approach, because using a number of samples in a pattern in front of the agent should be faster than actually calculating the ideal collision free velocity. In addition the sample approach can adapt quite well to a social forces modelling viewpoint by biasing the sample results with social information (scaling down the preference for a sample that moves us towards an enemy rather than away for instance).

Sounds like a complicated approach to take for moving agents around a world? Thats because it is a pretty complex problem. But I think the complexity is required for the game to be at all convincing.

Currently I’m trying to be pragmatic about it and get some more “game” done before I go back and finally implement the sampled RVO methods. I’m definitely pushing to get a number of weapon types implemented (when I say weapon, I include devices like the persuadertron in this). With the added weapons, the game will start to feel a lot more like a game you might want to play, with the options of weapons and subsequent behaviors opening up the design space for the game design and offering interesting avenues for the mission generator.

We’ll have to see how this next sprint goes.

Of all the things you will be doing in Damzel, the most important will be giving commands to your squad. Given the importance of that aspect of the gameplay, I have been looking at other games with a similar structure. Last week I was looking at Syndicate by Bullfrog, this week I’ve been looking at Brothers In Arms by Gearbox and Full Spectrum Warrior by Pandemic. Here I’ll talk about what I’ve learnt from Brothers In Arms specifically.

Brothers In Arms (BIA from now on) has you in control of squads of varying types throughout the three games in the series. For instance you may have a recon squad, an infantry squad and a machine gun squad. Or you might have a tank squad and a recon squad. You control the game from a first person perspective (as you do in Damzel) and can fight alongside the soldiers in the squad. This particular aspect is why I wanted to analyze BIA, because I knew from the beginning that I wanted to make Damzel a first person viewpoint game. To me, the first person viewpoint is so much more immersive. I suspect because you have no third party “character” in between you and the game world.

There are a number of great little design touches that I can see in BIA that I think are really useful. Here I’ll try and point them out with the help of a Youtube video. Have a quick watch of it now and I’ll refer to specific sections after you’ve seen it.

Click here to view the embedded video.

Squad Selection

So, the first thing when controlling a squad is actually selecting it. You can’t see on the video, but in order to select a squad on the PC you had to select it via its squad number key (keys 1..4 usually). I’ve added that method of selection to Damzel, but it feels a bit clunky to me. Squad selection happens often enough that I wanted a more natural interface for it. I experimented with loads of different schemes and the one I’m most happy with now is a combination of the BIA key-to-select method AND my own method which simply has you looking at a member of a squad and pressing the right mouse button down while looking at them (they get a highlight so you know youre looking at them properly).

You need the key-to-select method because you might be away from the squad you want to command. But it turns out that I’d rather you keep your squads fairly close for the most part. Interestingly in BIA as you can see in the video, you are basically dragging your squads along behind you. In Damzel it is far more likely you will send squads along in front of you as you try and secure areas. The intention being that the presence of a squad may well be enough to put off a potential threat.

Action Commands

So you’ve selected your squad, the next part is to actually give them something to do. In BIA you select the appropriate action command and you then see a cursor appear when you point at something that can allow the squad to use the command. So for instance a MOVE command you can see it at the start of the video will display a small circle on the ground to show where the squad would move. I’m a little hazy on the detail of how the action is selected, because I’ve played the various BIA games a while back, but I seem to recall it was a key-press of some sort.

Again, I’m liking the cursor idea, but I feel that having to actually select a command is a bit clunky. This is where things get a bit tricky design wise, because if you think about what you need a squad to do, there are often multiple contexts that could be done on any given object. Take the case where you are pointing at the ground with a squad selected. The most obvious case is that you want them to move to the location youre pointing at. But what if you wanted them to simply observe that area watching for threats? Clearly there’s going to have to be some method of going with a default and then allowing a keypress override.

Thats what I’m doing in Damzel. The most often used case for any given object will get the default action. So if you point at a known threat, then the squad will either move within firing range of them or will open fire if already in range. If you point at a citizen, you will default to going to investigate them, with the keypress override to allow you to open fire on them or perform other actions.

The other really interesting thing in terms of the action performance is the way that BIA actually shows you what action is going to be performed on the object you’re pointing at. If you look in the video at time 0:24 you’ll see the player give a squad an attack order. He does this by pointing at the enemy and you’ll see a cursor come up above the enemy in red showing that you will indeed command the selected squad to attack. But it gets more interesting than that, in that when you perform the command the icon grows and then shrinks back down based on the distance to the enemy.

I didn’t get this at first, but as I was looking at implementing the same kind of thing in Damzel I finally understood what that was for. The “shrink” phase is actually a great design idea, because it tells you how far away the enemy is! Its such a tiny thing, but I was struggling with my initial implementation in Damzel because I didn’t have a way of choosing the correct size for the action icon. The shrinking is really good player feedback because it gives you a solid read on the distance to the object you’re interacting with. Plus it doesn’t obscure you’re view like a fixed size icon might.

The attack cursor also has some other interesting properties, like a circle that shows how surpressed the enemy is and a section that shows the makeup of the enemy squad (I think, its either that or which squad you are attacking with, I cant recall).

While we’re on the subject of the command icons. Lets go back to the ground move cursor in BIA, did you notice that it changed the cursor depending on which squad was selected? Those little chevrons and tetris peice symbols on the cursor represent military symbols for the various squad types. This is a small thing, but a lovely little design touch, becuase it easily shows you which squad you are actually commanding.

Action Context

In Damzel you mostly have squads of agents, but you can command specialists like snipers for top cover and of course giving a ground move order for a sniper makes no sense at all. In this case, the move cursor will show you that you are actually giving a “watch this ground” order to a sniper squad, by showing the sniper symbol and changing the shape of the cursor to match the action. This context sensitive cursor arrangement will hopefully feel intuitive to players, but will no doubt need some serious tweeking. Luckily I’ll be able to test that out early next month as I’ll have access to a bunch of play testers.

The other thing you should note about the ground cursor is that it gives a little flash when you actually execute the command, plus it actually animates down in scale when you first select it. These little feedback items are really the sign of a high quality game with designers who know what they’re doing, its a lot of work to do these little touches, but it pays off in the overall feel of the game. I’m trying to be selective in what I implement because obviously I’m one guy and I’m sure BIA had a pretty hefty team of programmers, artists and designers, but I’m hoping that some of these little design touches will make it into Damzel and will add to the feeling of quality and attention to detail. Honestly it is the little detail touches that most indie games tend to lack, the better ones really do pay attention to these things and if nothing else I want to make a good showing on that front.

Ok, I’ve been rambling on long enough. I’ll post some thoughts on the design of FSW in a later post, for now I strongly urge you to get hold of the Brothers In Arms games which are available on Steam. They’re bloody good games and are the type of game that simply aren’t being made anymore because they are deemed too complicated for the console types.