The devil’s advocate: Feedback in Narrative

I was just reading Raph Koster’s last blog post, and it made me think, which is not a bad thing. But it started me thinking about a counter argument to the premise that narrative is not a game mechanic. I must say that I agree with the sentiment and I am a strong advocate of the idea that gameplay and narrative are separate things. I also agree that narrative is a form of feedback in video games. What I have sometimes pondered, however, is whether game mechanics can exist inside narrative.

Now, I am sure a ton of people have thought about this and written about it and indeed if you have any good references to such thoughts, feel free to let me know. I did a little google search for “can game mechanics exist in narrative” and found, strangely enough, this post of Raph’s as the first result. Hmmm….

So, can game mechanics exist inside narrative? Well it is clear that in a computer game there is a medium, a machine, that plays out some kind of simulation which the game player can influence and is provided feedback on. Essentially, that’s the top level structure of a video game system, (the system being both the game and the player, with the rules of the simulation being designed by whoever crafted the game). In this way, we get an interactive experience. You do something and the game reacts. So it would seem pretty clear that a narrative is not interactive, because, well, a book does not accept input (with the exception, of course, of “Choose Your Own Adventure” type books as Raph covers in his post).

However, what if one considered the book as being more than just data? What if the narrative not only informs the reader of what happens in the plot, but also contains code that changes the reader’s mental model of the world described in the book? ‘Eh?’ you say?

Well clearly we use our imaginations when reading, and this process involves working with a model of the world and rules that govern the entities within it… rather like a game, only in the imagination of the player. The skilful author not only presents a story, but also can be thought of as programming that mental simulation as the reader absorbs the written work. Is that not really the same thing as a video game, only running in a ‘virtual machine’ in the reader’s mind? When I look at it that way I do not see a distinction.

So, at an abstract level, one can argue that literature can create an internal interactive experience with the reader trying out various ideas within their mental model of the story, and getting internally generated feedback which allows them to draw conclusions about what will happen next… a ‘video game in the brain’ if you will pardon the metaphor.

However, what makes writing a book and making a video game similar is that the author can play with that internal ‘machinery’ in the mind of the reader by, for example, planting ambiguous clues or using out and out misdirection. It could be argued that the most dramatic moments occur when such manipulations take place. The author is not limited to telling the story, but can also program the brain of the reader, who then plays with the resulting program while absorbing the story.

There is an important difference between telling dry facts and telling an entertaining  story, and perhaps the difference lies with this internal model in the mind of the reader. How could it be otherwise? If what I am suggesting were not true, then I am quite sure there would be no need to tell long stories at all. The bare facts would be enough, here’s the merchant of Venice in 140 seconds…

http://www.youtube.com/watch?v=rWmtEUq34h4

What do you think?

Summary of the problem of reusable AI?

I’ve tried to express this before, but with questionable success. In working with a student today I came up with this summary. I am also aware that I still have not completed the final part describing my Proc system (I kind of took a break from all this online community thing in June). I will get to it again in time for when I next teach my AI course. I have ported it to C# in Unity, by the way. That was an interesting  journey, which I hope to blog about too in the future. Anyway back to, once again, searching for a good way to explain my perspective on this whole problem of reusable behaviours and implementing complex behaviours in games.

Resuable AI (modular behaviour) is a desirable thing to have in game programming, which seems to present a greater challenge that it should. After all reusable code is what good programming is all about, and we don’t have to jump through hoops (if you will pardon the pun) to implement the reusability of a function in most programming languages.

It is indeed interesting that this issue does not exist in most modern programming languages, which are implemented on an FSM (albeit hierarchical) architecture. A point that is often missed is that these issues are reflected in the original problem of modularity in early computers. The solution to this was the invention of the subroutine, which became the first important abstraction in computer science (See “The Humble Programmer” by Dijkstra). This abstraction allowed for reusable code.

Often when programmers talk about Finite State Machines what they really mean is an implementation of a virtual (state) machine which suffers from the same kind of problems that would occur if computers did not have the necessary hardware to implement a subroutine. In fact, sometimes these virtual machines are so primitive that they even lack conditional branching (part of the basic minimal functionality required of any central processing unit).

So the problem is not in the concept of the Finite State Machine per se, but naive implementations of virtual machines implementing finite state mcahines which do not include the equivalent of a subroutine, and thus do not allow for modularity. A hierarchical finite state machine (HFSM) is what you get by default in all procedural programming languages, and this provides the ability to create modular code.

This therefore begs the question “Why do programmers create a virtual machine, and call it a (Hierarchical) Finite State Machine, instead of simply programming what they need directly in the HFSM of the native language?” The answer is simple: It is because of the need to support multitasking when working in a language that does not readily support it.

This causes me to ask “Why don’t we just build our computers and languages to support what we need in the first place?”.

 

 

How I ‘discovered’ my Normalised Tunable Sigmoid Function

I was (in my opinion irrationally) challenged recently on my claim that I ‘invented’ my normalised tunable sigmoid function. This challenge prompted the following post. It got me thinking. It is all very well and good saying I made or discovered a formula or a technique, but it’s a hard thing to prove. So far I have not found the formula anywhere else, but I’d be delighted to know if it anyone else has come across it before, and I invite anyone to help me locate another occurrence of it, if it indeed one exists (as is high probable). But since there is no reference I can provide, I thought it might be useful to document how I came about creating it. This might be useful in inspiring and helping others to search for and find mathematical solutions which don’t come as obviously and easily as Googling for them.

The starting point was quite simple: in around 2002 I was trying to solve a problem in tuning the playing characteristics of a game. It was a football game prototype which I spent a year developing with an Italian game developer. The problem was this: I needed to tune the amount that the player kicked the ball forward while dribbling to the rate of movement of the player so that it worked well for a wide range of speeds. Also I wanted to adjust the sensitivity of the analog sticks (this being a console game). I still tend to call analog sticks “joysticks” because that’s the term we used for them way back when I started making games.

Tuning a video game is mostly about changing the way variables relate to each other. For example, the left right position of an analog stick might get returned as a number between 0 and 255. We then must convert that into some other value, for example radians per second of rotation, in a range of, perhaps, -0.2 to 0.2. The most obvious way to do this is to do something like the following:

We have a problem now, however. This arrangement only has one useful tunable parameter: 0.2. This is not actually that useful. I can change it to adjust the sensitivity of the controls, but the result will also be a change in the maximum movement rate. For example, I can tune the above to give more control by changing 0.2 to 0.1. But then the maximum rotation rate will he halved.

I am not happy with this. I want both to be able to change the precision and also still have a full range. In fact being able to do so is extremely useful, not only for, ahem, “Joysticks”, but also for any situation where a linear relationship is insufficient. But I will stick with the joystick example because it is probably the easiest example to understand.

So, how might we achieve this? First of all we draw a graph for the kind of thing we want:

This is a non linear function, because it is not a straight line. An input of 0 gives 0 and an input of 1 gives 1. This is desirable because it is a lot easier to make a general purpose function when it is normalized. I can multiply any term in any expression by my function that has a scale of zero to one.

The other characteristic is that there is a smooth curve in between. A common way around this problem is to chop the area into sections and provide different slopes, but that is ugly and also suffers (in the case of analog sticks) from a sudden change in precision at the cross over point which can be annoying for the player. So instead we want a smooth curve. And ideally we want to be able to adjust the curve.

So we know what we are looking for, what next?

Well the first thing we can do is observe that the curve appears somewhat asymptotic. This means that it tends towards a value, in this case as the input value gets smaller. This means that the formula we are looking for is probably going to have a division in it, with the input term (x) on the bottom.

Let’s try something simple first:

Next we can shift it to the right:

Now remember that we are looking for zero at zero, so we can shift it down too (currently the result is 1 at 0):

This is looking good, but now we have to fix the value for an input of 1. So how can we change the function to give us that without changing zero giving zero? This is a little more difficult, but after considering it a little bit we can think that if we express the function as a division, we can obtain zero if the top part is zero and one if the top and bottom are equal (that will be the numerator and denominator in math speak). So, perhaps we should look for a formula which is a fraction and involves x and behaves in such a way. We could look at:

Most of the time the answer will be 1, except when x=0 when it will be undefined. What can we do to this to avoid that? Well we can try leaving the top part as it is (or multiplied by something) which will guarantee that zero gives zero. Then we need to find something for the bottom that equals the top when x=1. Hmm. Well we can try a few things out here. How about we try including some kind of scaling factor to the top? We can do that without changing zero giving zero:

How can we modify the denominator so that it is equal k when x = 1? Well, now when x = 1, the numerator is k. So we want the denominator to be k when x = 1. That’s not too hard to arrange:

This has the right characteristics.  Zero gives zero, one gives one and something happens in between that might well be curve like. Not sure until we try, by plotting. But I can see looking at the formula that large values of k tend to make the function linear, as the -1 term below become less significant. Let’s try with k=5:

Aha! A curve. How about with k=2?

These are going the wrong way to the way intended. We can flip it around pretty easily:

Plotted for k=2:

And you can follow the original post for the rest of it. Further investigation revealed that apart from a range between zero and minus 1 for k, it is possible to choose negative values of k to curve upwards and positive to curve downwards, thus providing a single simple formula to create any amount of curve in either direction between zero and one.

As you can see, it was not a particularly difficult or improbable journey. As for whether it is original, or someone came up with it before me, how would I know? It’s not really possible to search for a mathematical formula through the formula itself! You need the name, and the only name I have is the one I gave it. It probably does exist in some other form, or in some paper somewhere that I am not aware of. But since I am not able to give a reference for its origin, it is only appropriate for me to say, as I did in my article:

Many years ago I went searching for such a thing, and came up with the following function…

General Purpose Simple Moving Average

Letteroids will continue after some adjustments, not the least of which is catering for the majority of wimpy players out there. I deliberately made it very hard, to see what would happen. 10 players completed the game, which is an amazing feat on their behalf. But I was surprised at how wimpy most players are (50% failure rate on Level 2?)

Anyway, right now I am also developing another quicky game. This one is in 3D, with a custom vehicle physics model and networking. I’m using Unity (of course) and the Photon Network Engine, and even though it makes a lot of things easy, networking is never easy. It’s going well none-the-less.

One issue of course is interpolation and extrapolation of object transform (i.e. position and orientation) data. I’ve come up with a nice solution which is good enough and very simple, but I won’t go through that here. Instead I want to talk about a very useful general technique for creating a moving average, which has many uses.

The idea of a moving average is to average a certain number of previous data points, so that you smooth out that data and get an average which changed over time, but is less noisy. I use this technique in many contexts. Some examples are:

• Getting a smoothed rendering frame rate for profiling purposes
• Allowing AI to decide whether a target is actually moving anywhere, or just moving backwards and forwards at random
• Getting an average update rate for network packets

The most obvious way to do this is to remember the last, say, 10 data points and average them each frame. Wikipedia covers this and goes into more detail , but misses the technique I am about to describe.

First of all, any video game programmer should be familiar with the basic concept of an average. To average a set of data, you simply add the data together and divide the total by the number of data values. The very useful special case is the average of two values: in this case you divide the sum by two (which is very convenient in assembler programming where the divide is a simple bit-wise shift).

Anyway, if we want to average the last 10 data values, we can do that like this:

For the math-o-phobes out there, that just means the sum of the last 10 values divided by 10. When coding, you can use a for loop to generate the sum .

Of course what we want is a moving average, which means that we have to calculate the above each time we get a new data value. Well, here comes an optimisation: we could simply add a new value and remove an old each time to a running total:

The problem here is that we have to remember the last 10 values in order to be able to remove the appropriate one from the total. That can be seriously annoying. Maybe you don’t feel like organising storage for this and the additional code complexity. I certainly don’t.

So, instead I do this in a different way. Since I do not want to remember values of the past, I simply subtract the average each time. It does almost the same thing, and in fact is probably better because the moving average will not be affected by past jumps in value:

This can be simplified to:

Or more generally:

Where N is the number of samples you wish to create you moving average over. An extremely useful little expression to keep in your programming toolbox.

The game is on!

No, it’s not Kick Off or Player Manager, but an important step to getting there. The game is called Letteroids 3D and it’s a remake of my very first assembler game. The original was a lot simpler, but that’s because it had to run on a 1Mhz 6502 and 6 K of ram (on the Acorn Atom). It was black and white, but had 10 letters and up to two enemies attacking you and ran at 50 frames per second. It was my first “Professional” game, and its goes back to around 1981 or so when I was 16 or 17. The game was an important step to me becoming a professional video game developer; and now it’s an important step for my return.

The new game is written with Unity 3D (in C#), and in the spirit of my earliest games, everything is done by me. The graphics (yes it’s programmer art). The code. The Design. The sound effects (hand crafted using software synthesisers). The music. It feels good to have done it, to have started and finished a game, and to have people playing it.

Unity 3D, you may ask? C#? For years I have had this dream of a development environment that lets me focus on making games rather than building technology. A few times I tried to make it, and somehow always gave up. It’s not that I can’t build the technology; it’s just that technology is to me what paints, brushes and canvas are to a painter. At my core, I am an entertainer and game designer. It’s what I was made to do. I have finally found a development environment that gives me everything I need, and I will use it to advance the player manager remake in due course.

I lost my way in an industry that ceased to place value in the core art of game design and I had failed to make use of my early successes to give me the opportunity to continue my art.  Now, the technology has become so advanced that I can, all by myself, design and build a game that entertains and this is what gives me a second chance. It is quite fitting, I think, that I now start by going back to my earliest substantial professional game.

Another thing that I needed was someone who would help with the business and marketing side of things. An online friend of mine and old fan of GOAL! runs Devil’s MMO. He commissioned me to write some articles for his site, and I did a few. But then I thought, “Surely rather than writing articles, can’t I write games?” and an idea was born.

To my fans eagerly awaiting some kind of football game thing from me, I am sorry, I have to ask you for patience. Before I can rebuild the game, I have to rebuild the game maker.

Letteroids 3D is currently in Beta test, and it’s free to play. When it’s out of Beta, we’ll be running competitions with prizes for the highest scorers.

Brief update on the new football management project

A quick update. I am currently converting the original PM source from 68000 to C. To do this I am using a bit awk script. Currently I have translated BALL.ASM and CONTROL.ASM (the ball code and the game state machine). I am working on KEEPER.ASM right now… the goal keeper code.

Awk is parsing the original assembler code and performing assembler macro expansions as well. It outputs each of the opcodes as a C macro call, so that I can emulate the 68000 directly as c source. This way I am actually recompiling the original game in C. When I am done, it will allow porting to many platforms easily. This approach also allows me to replace any emulated 68000 with more readable C code at any time. It should also allow me to port Kick Off 2 and GOAL! later, and update them… so if this approach works it should be a big win.

This was not the approach I was taking when I announced the project last summer… a few months ago I changed plan when I located the original source code to the games. It will take a while to complete the conversion (quite a bit of debugging to do even when the conversion is completed!), and I can’t give an ETA. It will be done when it’s done.

Cheers,

-Dino

 

Moving On

I am very fond of saying that life is a journey, and every journey has significant stages at which the nature of the journey itself transitions. I have reached such a point.

As a context for the last 6 years I have tried to make the most of the new and exciting social media opportunities and combine it with my music. I have tried to conduct discussions on forums about the video game industry (fruitless activity, but useful for learning a few things about the way people behave in online communities). I have experimented with Wikis, Radio shows, Blogs, Twitter… I have performed live gigs on Second Life. In the real world, I started a band and we played every Monday down at Mr. Wolfs in Bristol. I ran an open mike night in Bristol. I once played at 12 open mikes in a week. I have been to jazz jam sessions, have learned to play the trumpet and violin. Yet, outside of my own personal development, nothing has grown, nothing has developed. I am nothing more than one of millions of people who blog, tweet, make videos, write songs and play instruments. Recently I even tried a music collaboration site, but the it just felt like more of the same, in a different form.

I started wondering why I keep exposing myself like this, and invented in my mind all kinds of justifications. There might be some grains of truth in them, but mostly it’s a delusion. I keep on with this almost masochistic display in the hope that it will result in something meaningful, but it never does. And that’s my problem. It’s just like busking, spending most of the day watching people walk by as if you are not even there.

There’s nothing really wrong with it, except that I have fallen foul of the biggest error that one can make in life, which is to seek validation outside of oneself. Such a road is a dead end, because the only true validation is the one that comes from within. And so, having realised this truth, the time has come to stop.

Until I have fixed the real problem (me), I am cutting way back on my online presence. My youtube channel is scaled right back with almost all the videos now private. I have hidden (with the exception of this post) all non games related posts from this blog. My Facebook page is now private, and the only thing I will use twitter for is notifying when I make a new blog post (maybe with the occasional lightweight comment or retweet). I will continue with this blog, but strictly on video game development topics only.

This has some advantages; it will free up more of my time, which I will use to continue development of a new soccer management game, and to work on prototyping new ‘quicky’ games. I will also continue working on my music, but just for me and without any purpose beyond that. I think I am going to be a lot happier, and who knows by working on my own personal bottleneck, it perhaps can only improve my options in the future.

Finally, thank you to any who have, over the years, offered words of encouragement. They have always been gratefully received. It’s simply that I should not need them. Ah, the paradox…

-Dino

The PROC system (AI in Games and Multi tasking, part 4)

So, to recap on what I have been saying so far in this series… the fundamental problem I have with the methods commonly used to implement behavior in games is that they all require, in some way or another, the creation of a virtual computer. And this reason they do this, is because we don’t have language solutions that handle multi tasking properly. It is for this reason that we hear terms such as Hierarchical Finite State Machine (HSFM), and somehow miss the point that your plain old computer system and the common languages used to program them are, in fact, Hierarchical Finite State Machines already. There is a supreme irony to this; we solve our behavior problems in games often using HFSMs, and talk about HFSMs as if they are something special. We also create rather fancy HFSM systems and then call them something else, such as “Behavior Trees”. But, I argue… we should all move along… there is nothing special to see here. All that is happening is that we are creating virtual computing units that are all HFSMs in one form or another. We make many of them in a single game, and figure out how they can influence each other. This is the grand picture of video game development. It’s all loops, switches and if statements, regardless of what fancy name you call them by. Each state is an operation that is no different from a line of code.  Every single line of code, every opcode of the CPU in fact, is just another state.

Because of this I want a programming language that simply allows what one might otherwise cleverly encode into a complex data structure as part of some virtual machine, to be represented directly as code. Alas such a language does not appear to exist; I could use scripting languages but they usually only go so far and anyway, I want to use one language for pretty much everything. If I choose C++ as my language in which to write a game, I want to be able to express the behavior in C++, using straightforward C++ code.  I shall now present my solution to this.

To help understand what I am trying to do here, it might be good to start with an example (I’ll explain what the various pseudo keywords such as _PROC_ and _END_ mean later).

void exec() {
   _PROC_ {
      _WalkToFridge_();
      _GrabSoda_();
      _DrinkSaidSoda_();
      _CrunchSodaCan_();
      _LookCool_();
      _RecycleSodaCan_();
      _DONE_;
   } _END_;
};

If you show this to a programmer, they will immediately think of it as a scripting language. However, this is only because of the names of the ‘functions’. Otherwise, it’s just a list of function calls. Look, let’s look at a different example:

void exec() {
   _PROC_ {
      _InitGraphics_();
      _InitAI_();
      _LoadLevel_();
      _StartGame_();
      _DONE_;
   } _END_;
};

See how in the second example the function calls look like simple calls, simply because of what they are, er… called (ignoring the odd naming convention). The point is that the first example is implying an object that needs to work in its own thread in parallel to other threads because the names of the functions suggest the actions of a game object.

Anyway, looking at the first example concerning a simple action of going to a fridge and getting something to drink, it would seem that we simply can’t write things out that way in C++. Since none of the actions execute instantly, but instead take many frames to complete, we can’t create nice simple function calls. Or can we?  Well… actually we can, if we add a bunch of boilerplate to each of the function calls, using macros. That is why the calls have a specific naming convention, so that it is clear that these are what I call ‘PROCs’. Originally this was simply short for ‘process’, but if you like you can think of them as “Procedural Routines Operating Concurrently”.

I still find this fascinating to think about. My entire codebase is an HFSM which has the current state held in the program counter of the CPU. But then, in order to implement multi-tasking, I need a second program counter. This second program counter is specific to the software thread, and each thread has one. If you think about it, this is precisely what multi-tasking operating systems do; they create separate execution contexts and switch between them rapidly. This requires playing around with the stack, and this playing around has some performance cost. However, the approach here is different. Here we never play with the processor stack at all, but instead create a virtual program counter that magically remembers the current execution state of the thread. Hopefully you can make a connection to the concepts of coroutines I introduced earlier.

This is all fine an dandy, but we need to have a way to cause this virtual program counter to execute a particular line of code, and this is where C++ starts to show its limitations. To understand the problem, we need to consider how, for example, the execution of ‘_WalkToFirdge_()’ works. First of all, the function exec() of the entire listed code block is called every game tick. But while we walk to the fridge, we need to stop calling it. Instead we need to call the exec() of the _WalkToFridge_() proc until it is completed. When _WalkToFridge_() has completed, the exec() of the parent proc starts being called again… but clearly we do not want to execute it from the beginning anymore. If we do, we will be stuck forever walking to the fridge. Instead we need to execute _GrabSoda_(). We need to remember, somehow, to continue execution from the next line… we need to have something like a coroutine.

The experienced programmer out there will by now have figured out that to achieve what we need, we need a way of switching which code is executed according to the state of a variable. If you can’t see why, don’t worry I’m sure it will all become clear as you continue reading. There are many possible solutions to consider here:

• We can use a switch statement
• This is the way I standardized on. See below for how it works.
• We can use function pointers
• Actually we can’t. You need to change the execution point within a block of code, and that cannot be done by calling a function which takes you out of that code block
• We can use a series of if statements
• This is possible as an alternative to the switch statement, but switch statements are heavily optimized for a large number of cases, whereas a series of if statements has to perform a long chain of tests. If statements also reduce optimisation performance generally.
• We can get the address of a goto label and store that
• This would be lovely to be able to do. You can on gnu compilers in fact. You can take the address of a goto label and then store it, and later jump to it. Again a really simple idea that could have been in the original C standard, but was not.
• Alas, this is not a standard C++ feature, for example it is not available on Microsoft compilers
• We could use setjmp/longjmp
• This could be used, but it is generally slow because its meant to be used for exception handling. Also, it suffers from the problem that it has to actually execute code at the jump point to get the address of the jump point. This becomes a problem when you want to cause a change in the execution state, for example on receipt of an event or message… you can’t jump to a point in the code you have not previously executed.
• We could create our own custom inline assembler macros
• I have played around with this, but clearly this is opening the door to major compatibility issues.

The switch statement is standard across all C++ platforms and compilers. It is the natural solution, but has some problems. The biggest problem is that every single state needs to be ‘named’ in some way and these names must be integers. The result:

switch(_state) {
 case eProcLine1: _state=eProcLine2;  _WalkToFridge_(); break;  
 case eProcLine2: _state=eProcLine3; _GrabSoda_(); break;
 case eProcLine3:
.... etc
}

We could get somewhere with this… but it would be great if we could get rid of the case labels. We don’t need them. Otherwise it feels like going back to something like programming in basic. Of course we can wrap the boiler plate in a macro… except that we then need to auto generate case labels. How on earth can we do that?

Well, on some compilers there is a macro that increments each time called __COUNTER__, but it is not standard. Originally available on Microsoft compilers, it is now also available on gnu compilers (gcc, etc) as of GCC 4.3.5. What this does is convert to an integer, and increment that integer by one each time it is called. Such a simple idea, but one that some people would ask “Why on earth would you need that”. Well… I can now create a simple macro to wrap all that boilerplate.

#define _WalkToFridge_() _state=__COUNTER__; \
/*--- stuff to add the substate----*/ ; break; \
case __COUNTER__-1:  // it increments even inside a macro call, need -1

switch(_state) {
 _WalkToFridge_(); 
 _GrabSoda_();
.... etc
}

Alas, some issues with this. First, it is not standard C++. Second, we really want a unique ID for the whole macro. It’s not nice that the above solution depends on the order in which __COUNTER__ is, erm… encountered.

The solution I use is one that no doubt make many a grown (and not so grown) programmer weep. But after you get over how cranky it feels, it actually becomes not so bad. Honest. What I do is use the __LINE__ macro instead of __COUNTER__.

__LINE__ returns an integer that is the line number of the source code line in which __LINE__ appears. It is standard, and it will stay the same during a single macro call. It’s actually quite weird to use it this way, but it works without any problems. The only snag, if you can consider it really a snag, is that you have to put each proc call on a separate line.

OK that’s it for this part. In the next part, I will explain the “stuff to add the substate”, that is how a proc calls another proc. It is, after all is said and done, not actually that complicated. It requires, of course, the creation of a virtual stack,

More is Less

Once, game design was very constrained. More was not an option. So instead of ‘more’, we delivered something else. That something else was fun, which had nothing to do with quantity: number of colours, number of pixels, number of levels, number of megabytes, frames per second, market awareness of a license. Fun was the focus, fun was everything. This was the first age of video games. It lasted from the late 70′s until around 1994.

The second age started with the arrival of the Playstation and DOOM, and the demise of non PC home computers such as the Amiga. As the industry became bigger and more ‘serious’, the focus shifted away from that hard to measure thing ‘Fun’, to concepts that accountants and marketing people could understand. Technology was the driving force behind this ‘more’: more cycles, more polygons, more colours, more memory, and also of course higher barriers to entry (who had a spare 20,000 dollars for a PS dev kit?) and editorial control (Dear Sony, please approve my football game even though you have a football game of your own and your certainly would not want me making something that is more fun with less marketing spend, lower development costs). Industry figures sky rocketed, and initially in this second age, many people and companies did well. Innovation and fun still happened, but gradually what we think of as Indie development went away. The old idea that someone could author a game by themselves and have their name on the box became just a memory. Instead largely anonymous teams would work on rehashes of licenses or milking a successful original title by adding ‘more’ until the brand was destroyed. Employees at companies were not credited for fear that they would be head hunted. In this second age, the rule became “Never mind the quality, feel the width”. It is in the first age that Lemmings were born; it was the second age that they become largely extinct. This second age lasted until around 2008.

We are now in the third age of video games. After 15 years of decadence, high barriers, large budgets, unsustainable production budgets, the ‘mainstream’ industry has started to falter. How else could it have turned out? If the creative heart of an industry is cut out, sidelined, silenced, marginalised and bullied out, then all the ‘more’ in the world will just become ‘more of the same’. If the costs of development were one hundred times higher but sales only marginally better for most games, how could the industry survive? Could we really expect to be pushing blindly for more without a thought for the actual art of video game development and get away with it? LA Noire may have really good facial capture, but can really good facial capture sustain our industry?

It was something I had been predicting for a long time. Of course, back then (around 2002) things like blogs and Twitter were, well, not there. I would search for people to talk to online about these things, and the only place I found was that infamous industry forum The Chaos Engine. Yes, exactly. It sounds ridiculous now, but back then there was nothing else. Oh the fights I had on that subject. “The industry can’t sustain itself” I’d say. “Oh go away with your stupid ideas, you’re a has been” the forum (well some people on it) would say. Well, things are different now. Somehow now we *do* have intelligent debate on the Internet. Not through forums, but through blogging and Twitter (micro-blogging). The very success of Twitter is that you can only send short messages. Which brings me back to the point.

More is often Less, because if you focus on ‘more’ indiscriminately that’s what you get. More of things that ere easy to measure. More development budget, more technology, more licenses, more marketing spends more titles more more more…. until in the end you forget why wanted ‘more’ in the first place. The industry forgot why it is here: it is here to create more fun. But no one has figured out how to put that in a spreadsheet, so instead we have been chasing other ‘mores’.

In this third age we see the return of the Indie developer, and as part of that we naturally return to less. But as Minecraft and Angry Birds demonstrated beautifully, less is more when that less allows the creative freedom to invent new ways of entertaining, and create more fun.

Sometimes veterans (including myself) wonder why some really simple games are so successful when we have seen them before. Angry Birds is just a crude version of Worms. Minecraft is simply NetHack (or Rogue) in 3D. There’s no major technological challenge to these games. Yet, they are hits. Perhaps the reason for this is simple: the second age of video games did such a great job of ignoring the true art of video game development that now when a game comes along that actually shows that art people are desperate for more. I have no idea if I am right, but I am going to believe in it anyway… because that way there may still be hope for my own comeback.

AI and multi tasking (part 3) – The Proc System

Way back when I started work on GOAL! (or Kick Off 3 as it was then) I realised that I needed something a little more robust than a flat state machine.

Picture a football player a moment. If you want to simulate a football player, it is quite logical to think of states. In fact if you have been following my train of thought in the previous post on this subject, you will know that thinking in states is actually something programmers do all the time, because each line of code is a state:

StandInLineUp();
WaitUntilAnthemsFinished();
if(isTeamCaptain()) {

WalkToCentreCircle();

WaitForRefereeCoinToss();

.....
}

You can also show the above as a state diagram, when suddenly people start thinking of it as a state machine, instead of just lines of code. But there’s no difference, really.

Code as a state diagram

The reason for this kind of split thinking has to do with the need to multitask, i.e. do many things at once. The above code, if written as straight C++ code, has high level concepts such as “Wait”. It is logically impossible for a piece of traditional C/C++ code to “Wait” without devoting the entire program to that single task. If it is running in its own thread, one of many processes, then it can ‘wait’, whatever that actually means in practice (loop? Stopped process waiting for a message?). However we do not usually use operating system threading, or multiple processor threading for this kind of simple stuff. It’s not portable. It’s usually pre-emptive (meaning that you cannot control when the CPU switches between threads, such a switch can happen at any time and that’s usually not desirable in game code). It can be costly if you have thousands of threads.

So… what we do as programmers is not encode the above state graph as straight code; instead we create a state machine that is effectively a virtual machine running inside our program that takes each of the boxes (aside from the decision represented by the diamond) and labels them as a state, represented by some code number.

Labeled states

We then have a variable associated with the player, called something like “state”, which holds the value of the current state, so that the player ‘knows’ what he is doing at all times. According to the state, the appropriate piece of code is executed. In this example, let’s start with state ’1′.  ”Stand up in line” sets the direction and speed of the player to move, one game loop at a time, to the correct position in the line up, for instance. When the player gets to the right position, it then changes state to ’2′.

“Wait until anthems finished” could simply be a test to see if the music of the anthems are complete. This could be a thread somewhere else… maybe when the anthems are finished, this thread communicates that by setting a flag. The  player would be looking at the flag every game loop until it shows that the anthems are finished. When this happens, it then checks to see if the player is the captain or not, and if yes sets the state to ’3′. And so on.

It’s a far cry from simple code. It’s messy, in fact it’s a bit like coding in assembler, only worse… as you shall see shortly.

Well with the original football games, I actually did program them in assembler, and in Kick Off, Kick Off 2 and Player Manger I used precisely this kind of system. There were 23 threads (22 players, and one game control thread) and each of these had a flat state machine. There were around 55 states for players and 45 states for the control thread, with different variations for player controlled players and the goalkeeper. The state variable was used as a lookup into a table of pointers to subroutines. Pause states were done by a general pause function that could be applied at any time and would return the player back to what he was doing when complete. This last point is interesting because it is a kind of ‘hardwired’ nesting of states: a crude hierarchy. Pausing was in effect a subtask, although this really did not make the system a HFSM (Hierarchical Finite State Machine). It was more of a hack addition for a general state applied everywhere.

All of these states transitioned between each other in much the same way as a goto statement can transition among lines of code. Funny that, isn’t it? When you type goto in C or C++, you hear this kind of booming voice overhead, accompanied with a crash of thunder “Thou Shalt Not Use The Goto!”. Yet a lot of programmers don’t think twice about the fact that when you make your typical state machine, say, using switch statements and jump between states, then you are in fact using a goto within your virtual state machine!

Have you heard of spaghetti code? Well I have a different anti-pattern, which is actually the same one really: spaghetti states!

But it gets worse: without the ability to nest states (i.e. have a sub state) then you are not only coding by use of your own goto statements, but you are coding without the aid of the humble subroutine. Yes, that’s right: imagine for a moment trying to code without functions. Ludicrous to attempt it? Well… that is in effect what you are doing when you work with a flat state machine, because it is like working with a microprocessor that has no stack. Think about that, and chew on it for a while….

Hierarchical Finite State Machines (or having a stack)

A long time ago, the creators of computers figured out that just being able to execute a stream of instructions and jump around, while useful, was a bit limiting because there was no way to create any form of modularity. If you had some code and wanted it usable by other bits of code, this was tricky to achieve, because although you could jump to it, there would need to be a way of returning to the calling code.

Subroutines: the first important abstraction of programming

Now you could solve this by storing the return address somewhere, of course. If you look at the above example, you will see a very basic behavior. The entity goes to a series of waypoints. After reaching it waypoint it pauses for a certain length of time, then scratches its nose, then pauses again and then moves to the next waypoint. Clearly breaking down the code into three subroutines (Pause, Scratch Nose, Goto Next Waypoint) is a great way to manage complexity (which is the main purpose of abstraction).  To achieve this, the code to call, let’s say ‘Pause’ could be stored some place where the Pause routine should return to when completed. In this way we get a useful modularity; we only need to write one Pause routine, and we can call it anywhere and then continue with the next instruction following that call.

“OK, OK, Dino” (say’s a group of programmers with a quizzical look) “We know all this”. Yes, quite. But I really want to hammer home an important point here. This revisiting of the most basic of programming principles is relevant because it seems to often get completely forgotten when it comes to implementing AI, to the extent that we have scripting languages at one end and encoding of the entire ‘code base’ in a data structures on the other (for example, in Behavior Trees). Let’s be clear why we jump through hoops: we are creating a virtual machine, to provide the same functionality that we take for granted when we write simple, straight forward code. When we create a finite state machine in C++ (or other language), if it is a flat state machine then make no mistake about it: we are creating a virtual execution environment (similar to what you find in a microprocessor) that does not have a stack, and cannot easily support sub-states (which are in fact subroutines).

The stack is a wonderful invention of course. The problem of where to store return addresses is non trivial. If we only have the memory to remember a single return address, then we cannot call a subroutine that calls another subroutine. That requires remembering two addresses. So this is why the invented stacks: so that you could call subroutines that themselves call subroutines. The stack is implemented often in hardware on microprocessors for the main purpose of remembering return addresses.

It is also important to note that if we encode the AI algorithms in a data driven virtual machine, then all we are doing is creating a virtual machine using complex data structures that replaces compiled code as we normally know it. Does that really make sense? I mean what happened to the idea of writing code in a language? Does it make sense to ditch that concept and replace it with some magnificent, complex system that basically does everything that a compiler does, except it stores the virtual ‘code’ in a tree? The only really valid direct advantage is the ability to modify the code while the code is running. That of course is valuable, but for most projects it is not *that* relevant. Most development still takes place with the good old compile and run approach.

What I am saying, in a nutshell, is:

1. Scripting languages; implemented state machines; data trees (e.g. behavior trees) and so on are solutions that replace simply writing the code in C++.
2. We do this mostly because C++ does not support multi tasking.
3. We engineer a virtual machine that allows us to multitask in C++.
4. We then implement much of the behavior at the virtual machine state level, instead of directly in C++.

Now I am not saying that this is wrong. What I am saying is that we should be clear about why we do it. However having said that, I do feel there are some major disadvantages to typically observed solutions to this problem:

• If you use a scripting language, you now have to work in two codebases and two languages instead of one
• If you use data trees, you have to develop a lot of tools just to be able to visualize what is going on, or use a domain specific language to populate the data tree.
• It adds a lot of complexity to your project
• It can have major performance costs (I do wonder sometimes about programmers who obsess about virtual function calls, but are quite happy to have the gameplay code running in Lua, Lisp or Python)
• You need to inevitably duplicate some code between the two languages
• Debugging can often be difficult if you do not spend time developing debugging tools
• If you do this without having an architecture to manage it, the code will quickly become a spaghetti.

What I want to do is simply write everything in C++… or to get as close to this as possible… and still have my codebase manageable. This is what my PROC system aims to do.

Coroutines: The Starting Point of PROC

Around 1992, I invented for myself a concept actually previously invented in the 1960′s called coroutines. I had no idea of this of course. The internet as we know it today did not exist, and it was actually quite hard to get information on programming other than with paper books. Research was difficult, and so many of us pioneers (you can forgive me labeling myself as such I hope) had to invent things for ourselves.

The assembler I used was that which came with the AZTEC C compiler. This was a macro assembler; this meant it had a macro capability similar to that of the C pre-processor. I used this to solve a problem. It was really bugging me that if I had a sequence of states that need to be executed one after the other (for example the loop in the previous diagram) I would have to encode this with a unique state number for each stage. It made for a lot of clumsy code.

Part of a flat state machine for handling animations

In the diagram above, you can see an example of what I mean. I am showing three states of the flat state machine for the AI of a game entity which are all concerned with playing an animation. It’s a fictitious example to demonstrate a point. Note that there are two levels of state here: the state of the CPU (it’s a flowchart and in effect where you are pointing with your finger as you trace it is where the program counter is). The second level of state is the state variable. To start playing the animation, some other code in the game will set that state to 5 to commence playing the animation.

Let’s work through it. State 5 is all well and good, but we must make sure to store the parameter (the ID of the animation to be played) somewhere. The next time that the AI tick is called, this will be forgotten otherwise. So that’s what happens first. Then we have to set the state to 6, because we do not want to do 5 again (it would corrupt the animation ID).

We then check to see if a non interruptible animation is playing. If yes, then we just return (i.e. that is the end of the AI for this entity for this game tick).

When we have the all-clear, we remember the current animation (if one is playing). We ask the animation system to start playing the new animation, and then set the state to 7, because we do not want to call 6 again (it would invalidate the save of the current animation and re-trigger the animation from the beginning again).

If the animation is not finished, we return… so we are waiting until the animation is completed. When it is completed, we restore the previous animation, and then go on to do something else (not indicated in the diagram).

Simple, eh? Well, not really. It’s a bit of a mess. If we could, we would want to to write this code something like this:

AI {
State: PlayAnimation(_anim) {
  anim = _anim;
  WaitUntilInterruptable();
  previousAnim = getCurrentAnim();
  StartAnim(anim);
  WaitUntilAnimFinished();
  retsoreAnim(previousAnim);
}

Let’s compare that with C code for the above flowchart:

AI() {
  switch(state) {
    case 5:
      anim = _anim;   // where are these stored?
      state = 6;
    case 6:
      if(isAnimInterruptable()) {
        previousAnim = getCurrentAnim();  // where is this stored?
        startAnim(anim);
        state = 7;
       } else {
        return;
       }
     case 7:
       if(isAnimFinished()) {
         restoreAnim(previousAnim);
       } else {
          return;
       }
      // etc
   }
}

This is quite a simple example, but as you can see it’s much messier and harder to work with in C++ than our ‘ideal’ language solution. Even in assembler, where I could make jump tables rather than use switch statements, it was not much better than the C solution. The particular thing that is really painful is how simple transitions between sequential states require a named state and code to set the that state after every stage. What a pain!

Then suddenly, I came up with an idea, and something that cannot be readily done in C++ (actually there are ways by using setjmp or inline assembler… but… they only take you so far as we will see later). I created a macro called “FromNowOn”. This macro simply took the program counter address of the first instruction following it, and stored that as a jump target. Instead of the switch, the address of the code to execute for the current state was stored in memory, so as soon as you executed FromNowOn, only the code following this macro would be called on the next tick. It is in effect a virtual program counter implementation. I found out a few years ago that this idea was known as a coroutine.

To conclude this part of the series, here is a version of the above in pseudo C++ that implements a FromNowOn instruction in a macro. It is definitely an improvement, as we no longer have to create labelled states for every stage of a sequence!

AI() {
  switch(state) {
    case 5:
      anim = _anim;   // where are these stored?
      FromNowOn;
      if(isAnimInterruptable()) {
        previousAnim = getCurrentAnim();  // where is this stored?
        startAnim(anim);
       } else {
        return;
       }
       FromNowOn;
       if(isAnimFinished()) {
         restoreAnim(previousAnim);
       } else {
          return;
       }
      // etc
   }
}