IGAD hosted a GGJ event for the first time last weekend with other ninety participants and 17 teams. I had a great time overall (although I found it immensely challenging this year – perhaps it was the pressure of not wanting to fall on my face in front of my students… and of course my colleagues. It might be wiser for me to go to a different location next year).

Our team came third with this game, although apparently it is not a competition (even though there is judging). In second place was Sophie in the Sky, and first place went deservedly to The Small Bang Theory, a team of first year IGAD programmers who had no artists and yet produced a very polished and complete game! In any case, such a jam is not about proving something to each other, it  is about just saying “hey, who cares how it goes, lets try and make something”, and everyone who took part should be proud of themselves. It is clearly important, however, to have even a token judging in my opinion, because without this the event would have no bite. It would be like a curry with no spice.

One external judge seemed blown away by the comparison of the productivity between a bunch of what could be characterised as “amateurs” and  his own professional staff. And indeed, having also worked in the industry office environment, I know what he means. Sure the crunch of a game jam, if you are intent on delivering a recognizable working game in two days, is quite intense and very similar to the crunch time of a professional project – only shorter. The difference is that you know it is going to end, and so the motivation to be productive is high and the carrot of being able to relax soon is motivational. In the traditional crunch of the industry, it is a different story.

It got me thinking that once again what people typically do in the video game business (5 day working weeks with an expectation to work unpaid overtime ‘when needed’) is completely and utterly irrational and a fine example of the failure of human beings in groups to make good, wise decisions. It only goes that way in the industry (and of course not only the video game industry) because of some kind of ‘cost accounting’ mentality. It’s irrational, and it seems that few people have the courage to actually do things differently.

Surely, I reason, there is a better way. If people can be so productive in a 48 hour chunk of time, why not leverage this and have a two day working week? Ridiculous? I think not. Maybe if that is too radical, make it three twelve hour days, with 4 days off. I can’t help but think something special would happen.

With clear goals for each week set, the motivation to reach those goals will be high – no one likes to fail. But additionally, people will be looking forward to some actual time to enjoy living. After all, a weekend is often spent shopping and looking after the house and taking care of personal matters and family and so on. A four day weekend on the other hand.. well that leaves time to relax and think. Time to get into a good relaxed frame of mind. Time to solve design problems unconsciously. Time to look forward to going back to work.

I hope one day I get the chance to run my own development company. If I ever  do, I will be sorely tempted to try this idea out. I suspect the results will be astonishing, but I admit I could not do such a thing risking anyone else’s money, because despite how logical the idea is, and the evidence of it’s effectiveness, I doubt anyone would believe in it enough to risk it.

Still, one can dream… given enough space to do so

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?

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?”.

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…

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.

]]> http://dinodini.wordpress.com/2012/01/02/general-purpose-simple-moving-average/feed/ 0 Dino Dini http://dinodini.wordpress.com/2011/12/18/the-game-is-on/ http://dinodini.wordpress.com/2011/12/18/the-game-is-on/#comments Sun, 18 Dec 2011 22:05:44 +0000 Dino Dini http://dinodini.wordpress.com/?p=946 ]]> 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.

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

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

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.

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,

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.