I’ve been working in the games industry for nearly ten years now which I think makes me something of an old man in games industry terms at the ripe old age of 28 (seriously if you go to just about any developer you will mostly find an office full of spotty twenty-something graduates). In all my time I’ve been a proponent of Intelligent Design when it comes to making a videogame. By that I mean writing lots of documents, having lots of meetings and cogitating long and hard on every single aspect of the project.

“No plan survives contact with the enemy.” - Helmuth von Moltke the Elder

In ten years of games development I have never worked on a game where the resulting product paid more than a passing resemblance to what was originally designed. Such is the way with an inherently creative process like videogame design. Once you start to implement features and interact with them then juices start flowing and you start to have new ideas or realise that something would work a bit better if you changed it. Part of this is because the only people who read Design Documents are other Designers.

Design documents will get nailed down into what is termed a “Functional Spec” which is often written either by the assigned programmer or a Designer who happens to be a Programmer in disguise (like me). A Functional Spec will take the ideas generated by the Design team and try to boil them down into the rules, systems and variables that are actually needed to implement it. These tend to be the most useful documents and where the majority of documentation time should really be spent. It’s these documents that work out what content is required to make the feature work and how it’s all going to plug together. They are absolutely essential to the first implementation of a feature.

They are then useless after that point.

Once you have the first implementation of a feature in your hands to play with documentation is largely useless and tends to get thrown to the side of the road. Everybody has ideas and tweaks they want to make and often a feature will end up being scrapped completely or turn into some other feature nobody ever thought the game needed but turned out to be essential (Vehicle Melee in Wheelman was such a feature. It was never “Designed” it just kinda happened one day). From this point on Evolution takes over.

What happens next is called “Creativity” and it’s something that likes to run around without any pants on and if you cage it in bureaucracy it will fade and eventually die. Without it though you won’t end up with a fun game. You’ll end up with something that might look like a fun game but here is a tip: If the people you’re paying to make the game don’t enjoy making it then the people who are going to pay you for it probably aren’t going to either.

Alot of Producers hate this bit in games development because it doesn’t fit neatly onto a schedule but it is absolutely necessary and vital to having something worthwhile when you ship. Unfortunately this part of development (usually called “Prototype” in my experience) tends to be the bit of the schedule that gets cut the fastest when it turns out that you have content requirements to meet. You promised the Publisher 150 levels over 10 different environments. What you didn’t promise the Publisher was that the game would be fun. The term “Deliverable” will be thrown around and the time required to actually turn a feature from a Functional Spec into something amazing will shrink to almost nothing.

The reality is that you really can’t design a videogame up front and expect it to be amazing and awesome without first playing it and then making revisions to it. I doubt there are many composers out there who won’t spend ages fiddling around with the music before they consider it ready. The problem the games industry generally has though is that with teams of 300 people and budgets up the wazoo individuals can no longer move fast enough or with enough freedom to be truly Creative bound as they are by Bureaucracy. If you wondered why Indie games tend to be more Creative it’s because they are created in atmospheres that foster Creativity and allow swift revision, iteration and evolution before exposing themselves to the world.

Creativity in the Games Industry struggles purely because of the “Industry” part. The same way it struggles in the Music and Film “Industries”. To me this is the best evidence I’ve seen that games are an artform. They’ve suffered the exact same fate as all the others.

The argument put forward is that when faced with too much choice people will often choose nothing at all rather than go to the effort of objectively weighing up the options and trying to come to a decision. I find this tends to stand up to my daily observations the most recent of which was a trip to the supermarket where my girlfriend asked me to choose some crisps and; faced with an entire aisle of choice, my brain completely shut down and refused to even try.

The book splits the world into two groups: Satisficers and Maximisers. Maximisers want to be sure that their decisions are the best they can possibly make even to the point of comparing them to imagined possbilities that don’t or can’t exist in reality. Satisficers have standards but don’t worry about whether or not they got the best deal just that their most important criteria have been met.

Satisficers tend to live a happier more fulfilled life because they spend less time worrying about things they can’t control while Maximisers tend to be more depressed and filled with buyers remorse.

This is similar to Perfectionism. Perfectionists strive for an unattainable ideal often at the expense of everything else. Perfectionism is in fact very bad for you unless you have some outside force that is willing to intervene when you get carried away.

Duke Nukem Forever suffered immensely from this. In an effort to create a “Perfect” videogame 3D Realms ditched a perfectly good game they believed wasn’t good enough and started over. Ultimately they never released anything. Perfectionists are doomed to be depressed and to hate the very things they help create because they will only ever focus on what is wrong with things. It is in fact a very pessimistic outlook on life and yet for some reason a trait that many claim to desire in the people they hire.

Well I guess that might be true so long as the person doing the hiring and cracking the whip isn’t themselves a perfectionist and has the guts to stand in front of a room full of perfectionists and tell them that what they have made is “Good Enough”  (There is no bigger insult to a perfectionist than being told what you have created is only “good enough”).

I’m a recovering perfectionist. I’m trying to get comfortable with the idea of letting things go in cases where changing them any more isn’t going to result in any significant gain or benefit. This doesn’t mean I won’t make something as good as I can possibly make it but it does mean that I’m more likely to recognise when further work is futile and instead take pride in what I have done rather than dwell on what I haven’t.

This is also by way of apologising for not posting any updates on my game. I had a perfectionist moment and decided to rewrite the entire code base so that it did everything it used to do but in a nicer way that nobody but me will ever care about.

Sorry. That would be the curse of perfectionism right there.

Lets start with the video:

The most notable addition this week is a new enemy called a “Bumble”. Bumbles are so named because they bumble around the arena in a pseudo random fashion bumping into each other and occasionally the player. I wanted an enemy that would be unpredictable and serve to reduce the amount of empty space in the arena which would make it more difficult to just kite the “Grunt” enemies.

The wandering behaviour is based on this article although since I don’t have an infinite playing field to work with I added in some code that pushes the steering force back towards the middle of the arena the closer to the edge they get (although it’s not so strong that they don’t sometimes just bounce off the arena wall).

I’m learning some things about shoot-em-ups that I never realised before but which tie in with Deathmatch style level design.

For example – Power-ups exist not to make the player more powerful but as a way to get the player to move somewhere specific rather than just moving into the space with the least enemies. As enemies often spawn a Power-Up when they die; and this is often in the middle of other enemies, this forces the player to make a risk-reward decision. This is exactly the same as placing Power-up in a Deathmatch level where the best weapons get put in the most exposed and least defensible places.

Finally if you want to read about the more technical work that went on this week (most of my time was spent refactoring code rather than adding new features) then check out this post on the UDK forums where I talk about Actor pools, memory fragmentation and Pawns being overweight.

They all then rushed to the forums to ask how you make a game.

Fortunately I’m an old hand with Unreal, starting back in 2000 modding Deus Ex and then progressing pretty much hand in hand with the engine through each version to the current one often being paid for the pleasure. I’m one of the few people in the world who can say they have worked with every version of Unreal that doesn’t work for Epic.

So rather than rush to forums asking how to make games I just made a game.

BEHOLD! One short weekend of fiddling with UDK later and I have something that can be very loosely called a game…

Ok so it’s a ball that rolls around a simple level collecting glowy yellow things.

More beneath the cut…

If I’m honest I spent more time fiddling with particle effects and lighting than I did actually writing code. Some people liken it to Pacman, other mention Marble Madness. At this point I didn’t really have any plans of what I was going to make and was really just poking the code to get something to happen with a minimum of effort.

However as more people encountered my little endeavour I was encouraged to maybe make something a bit more interesting.

Here is my list of restrictions that I’m bound by:

• Project can only use content that I can create myself.
• Project must support online multiplayer.
• Project should epitomise Systemic Game Design.

With this in mind I decided to expand on the physics theme and spent a few hours on monday and tuesday implementing support for buoyancy (which PhysX doesn’t support out of the box) and fiddling around with Fluid Surfaces.

It’s during this phase that I relise how lucky I am to be an Unreal Developer by day as I stumble across one of the more annoying features: The C++ Black Box.

UDK doesn’t give you the C++ source code. This means that there are times when the engine is doing something that doesn’t make sense and has disappeared into the Black Box of Native code. In this case it was the calculation of a physics objects mass.

This means that some constants and formulas are locked up beyond the prying eyes of the UDK programmer.

To cut a long story short however it turns out that Mass in Unreal is calculated as:

(Volume x Density)^0.75  x MassScale

The argument being that it reduces the difference between small and large objects because PhysX behaves funny when you have wildly different Masses involved.

Whatever the formula though so long as you know what it is you can at least be sure your simulation is internally consistent even if it isn’t a 100% accurate recreation of the real world.

With this version I change the Balls physics to apply Torque rather than an impulse which gives a more satisfying and “Physicsy” feel and even allows the ball to climb walls a little (hurrah for friction!).

So far however I’m still just playing around with tech and not really concentrating on the “Game” part. I have vague ideas involving fire, wind and fracture meshes. I also have an idea for making enemy cubes that stomp around the map but it’s early days yet.

Watch this space.

I promised to post a review of this a very long time ago now. In truth I finished reading it a long time ago I’ve just been far too busy to blog anything until now.

I bought this book as a follow-up to Blink as I wanted to know more about subconcious decision making and instinct. On that front I am not at all disappointed.

Gut Feelings demonstrates alot of the ways that we make decisions subconciously and presents data resulting from many case studies around the world pitting logic and reason against intuition. The Conclusions are very convincing and I finished the book happier in the knowledge that I could apply what I had just learnt not just to my work (more on that in a moment) but to my everyday life.

One of the key principles demonstrated in the book that really stuck with me is the “One Good Reason” heuristic.

The theory is that the majority of decisions are made by focussing on the most important elements one at a time. Once you find a solution or product that matches that element you stop looking. If there is a conflict between 2 or more products you move on to the next most important element until you end up with just one.

On analysing my life I did relise that I do make most of my decisions using this heuristic. Logic and reason would suggest that I weigh all the variables equally and use some highly complex formula to come up with the correct result.

Fact is though that system only works for hindsight when all of the relevent variables are available. With limited knowledge in a highly unpredictable world the simpler “One Reason” heuristic has been proven to operate at much better than chance (Even when predicting the stock market).

This has made me less worried about writing lists and comparing them in order to make my decisions. I’m much happier with decisions I’ve made on instinct than ones I’ve poured over for days. I trust my subconcious alot more than I used to.

As far as how this can be applied to Games Design though I think this is a must-read for anybody working with Artificial Inteligence.

While designing Wheelmans OnFoot enemy AI we developed lots of very complex formulas to weight cover locations and targets. These formulas would get more and more complex as more and more exceptions and edge cases were found. In the end they were largely useless and the AI still behaved erratically.

Looking back at it I think applying a decision tree that only looks at one element at a time would produce much more predictable and sensible results. An added bonus is that such a heuristic is far faster and inherently more optimised than a complex formula that tries to account for all possible variables at the same time.

For more general Games Design I think understanding the different heuristics we use often can help you understand how your players will try to solve a problem and generally play your game. 80% of people playing your game will be operating entirely subconciously and be unaware of any complex decision making process (Heck I manage to play Civilization 4 that way – I suck at it but that isn’t the point).

Recognising how the subconcious is evaluating your game, world and the systems that make it up will help you evaluate the player experience and play to the strengths of the subconcious.

In conclusion: Buy this book. If you’ve read Blink then you can probably skip alot of the early parts as they mostly just give you a grounding in the topics that book covers. I would also say that there is no reason to buy Blink in order to read this book as it is incredibly easy to read and is written in a very entertaining and conversational tone.

I rate this book: Yes out of ten.

However Damnation are apparently going a different way and basing their Level Designs on Concept art. 

I’m interested in seeing how this process works out in terms of actual gameplay as a good concept artist can throw out sketches faster than you can block out a level in sketchup and tend to get hired on the strength of their imagination. In contrast Level Designers are often hired for their technical skill more than their artistic ability.

Being able to use a game Editor and script in LUA will push your Resume closer to the top of the pile compared to somebody who can make their own textures (ProTip: If you spend longer making your level look awesome than play awesome apply for Environment art jobs).

So with that in mind inspiration can be tricky when coming up with your designs. Having a Concept artist onboard early in the process will at least introduce a sounding board for ideas and a second perspective from somebody who can visualise a 3D scene and then communicate it quickly. So long as it’s a two-way process with the artist and designers inspiring each other I can’t see how it could fail.

So here’s hoping Damnation is actually fun.

It’s a belief that often causes debate amongst Designers because the phrase is usually reinterpreted to mean “The player must never fail.” and this couldn’t be more wrong. Failure does not equal Punishment and in fact Failure is an intrinsic feature of all games and forms of play.

One of the biggest problems is that failure is thought of as being a negative thing. If you fail the mission then it’s Game Over. This is only a correlative relationship however in that Punishment (which is almost always negative) often follows Failure (which can be positive). “Cum hoc ergo propter hoc” as somebody who understands Latin might say (I don’t I just stole it from Wikipedia to look clever).

Failure is a Positive experience when it is possible for us to learn from it. This may sound a bit like a line from a self-help book but it’s something that is worth emphasising.

When most gamers buy a new game the first thing they do not do is read the manual. Instead they will load the game up and immediately jump in and start trying things out to see what happens. When something works they add it to their mental model of how the game works and start applying that knowledge to future interactions. The same is true when something doesn’t work. With every interaction the Player is refining their mental model and making it more accurate.

Valve found that Play-testers for Team Fortress 2 weren’t as upset when they died if they were shown who killed them (and the surrounding context) and told how they had improved. By providing Players with this feedback on why they just died they were helping the Players learn from their mistakes and reinforcing their own progress. They had managed to turn dying from something that was relatively punishing into something that was beneficial. By dying you were learning.

Take a racing game for example. You step into a car you’ve never driven before and you start out by driving it in a similar way to the last car you drove. Using this base experience you start to develop a mental model of how to drive this new car (and I should point out that it is very rare that the player is actually aware of this information). Both success and failure help you refine this model. You start to take corners faster and faster and with each success confidence in your model grows and similarly if you spin out or hit a wall the failure helps establish the limits of that model. Failure because of over-confidence in your own mental model is a positive gain. The failure is your own and fits within your model. Both Successes and Failures that contradict your mental model result in dissonance and confusion.

Key to this learning process is that once you have failed you are able to test out your new model quickly. If you cannot affirm what you have just learnt then it is very likely that the experience will be forgotten and the failure repeated later.  Respawning in TF2 is often very swift and you can nail that corner on the next lap.

This somewhat matches something Clint Hocking said at GDC

In contrast, the consequences for getting kicked out of the execution phase in Chaos Theory has a huge impact — the game is so reliant on the player executing his careful plan, and the game is so slow-paced, that it makes more sense simply to reload a saved game. But in Far Cry 2, that disruption ends up being part of the game, and there is such a level of chaos to begin with that players did not end up feeling the need to reload every time something went wrong; rather, they would adapt to the new factors.

The fact that failure didn’t mean the game ended or that you had lost a lot of time preparing and were now unable to continue meant that Players are much happier with trying something new and potentially failing. The short turn-around on being able to integrate changes into their model meant that failure was a Positive force which helped the player learn.

System’s like Far Cry 2‘s malaria and weapon jamming, which introduce randomness, ended up having much more influence over the final experience of the game than was expected with the initial design. What happened was then that they were the triggers that kick the player out of the execution phase back into the composition phase, leading to the rapid back-and-forth of those two phases.

Failure or a sudden change in circumstance is often a trigger for improvisation. When your plan fails you have to call on that mental model of the game again and respond.  Part of the feedback loop that makes games so entertaining. A perfectly executed plan has it’s own rewards but success in the face of failure can be even more rewarding. Being able to adapt quickly and effectively requires many more skills than just solving a static puzzle.

Take Reset by roBurky.

A game that lasts about 3 minutes and never punishes the player for Failure. A game that is very challenging despite not actually having any formal win or lose conditions. You will always reach the end of the game but along the way you will have been subject to both success and failure. At no point does this make the game any less enjoyable as either an experience or a game.

It’s worth noting that I ended up playing the game 5 times just now before remembering to take a screenshot.

Here every time you hit an asteroid or a missile it is a failure. The ships controls alter as you take damage with it favouring either the left or the right which forces you to adapt your model as you play. Each new element is introduced carefully allowing you to experiment with them in relative safety letting you build a model of how the element works and how best to deal with it. Then as all of the elements combine together you are forced to improvise and adapt using what you have learnt.

This game is a perfect example of how Failure isn’t always a negative experience.

• The game is consistent throughout allowing us to learn from each failure and adapt our mental model of the game.
• We are able to put our adapted model into practice quickly because in a few moments there is a new opportunity for us to try it out.
• Failure forces you to improvise and adapt to the situation calling on your full understanding of the game.

You don’t need to be able to lose for a game to be enjoyable or challenging. You just need to be able to fail.

This managed to pass me by when it first appeared but Andreas Zecher made a series of Flash Games called Understanding Games which try to explain the fundamentals of Game Design via Game Play. It is to Games as Understanding Comics is to Comics.

The games clearly take alot from Raph’s Theory of Fun and is a cool grounding for anybody unfamiliar with the medium (and could probably stand to re-iterate the basic principles veteran games designers might forget in the white hot forges of crunch).

For a fun Friday morning exercise try and identify some Design Principles he’s used but not explained. That’ll be that unconscious mind at work again I suspect.

So in the interests of trying to aggregate the genuinely useful links I find I shall be trying to keep this post up to date with what I find.

Single-Player

• Level Design Pre-Production - Dating back to 2003 this article goes over the practical aspects of actually designing a level layout before you start building it.
• Using Loop Layouts - From the Valve Community Wiki. This is a concise and to the point explanation of using looping layouts in single Player Levels with several case-studies from Valve Games.
• Bouncing or Back-Tracking – Also from the Valve Wiki another concise page detailing effective use of Back-Tracking or “Bounces” in Level Layouts. Again lots of excellent case-studies.
• Color Theory – Another page from the Valve Wiki! This page ties-in with what I describe in Continuity Level Design about contrast and composition but also covers more general color theory.

Multiplayer

• Competitive Level Design – Dating all the way back to Quake 3 this page is an excellent grounding in the tactical and strategic considerations required by designing competitive maps.
• Level Design Patterns – (Warning PDF Alert!) Skip to Page 10 for the useful stuff. A Good grounding with Case Studies on common Patterns in Level Design. The Principles can be applied to other genres than FPS games quite easily.
• Making de_dust – Proof that it’s better to be lucky than smart the creator of the worlds most played Level takes you through the creation of de_dust.

I am currently reading Gut Feelings: Short Cuts to Better Decision Making by Gerd Gigerenzer. If you’ve ever Read Blink (or even if you haven’t) then I recommend this book as it deals with the concept of intuition, instinct and the unconscious in a much more detailed way. I’d argue that you can completely bypass Blink altogether and go straight for this  as it is a much more useful book and very easy to read.

However this post isn’t about the book (I’ll save that for when I’ve finished it and filled it full of post-its). It’s actually about what I’m doing on this site.

When I write a blog post I am not so much telling the world things or laying out facts. This is part of my learning process. By writing about the things I discover or have learnt I’m helping to improve my understanding of them. I actually use this blog as a mnemonic device. By the act of writing about a topic I am ushering that information into my unconscious and hopefully helping it to become intuitive.

In short I’m writing this for me and not you. If you find it helpful than I’m glad. But be aware that what you see on these pages is rarely ever backed up by anything resembling evidence or research. It’s either all cribbed from books I’ve read or lessons I’ve learnt so take it with a pinch of salt.

Like a lot of Designers I tend to operate on my gut instincts a lot. When generating a new design or mechanic I tend to operate on automatic, letting my instincts rule the creative process. I believe that in the early stages of Design when you are roughing out what you want this is the best way to operate. By Instinct. Our unconscious mind is powerful as anybody who does anything remotely Creative will attest. Companies pay a lot of money for people with good instincts.

There comes a point however when Instinct isn’t enough. When your design that you felt in your gut was perfect turns out to be exactly the opposite. For whatever reason nobody is having fun playing your game and you don’t know why.

This is why I feel that a good Designer never stops learning. A good Designer doesn’t copy what other games have done without first trying to understand why it’s worth copying.

There have been several movements within Games Design to try and create a lexicon or identify good mechanics and while I find this very honourable and interesting I often feel like a it is only focusing on “What or How” and not “Why”.

“Why” is a word that drills down to the core of a subject. It’s the basis of the Scientific Method and Philosophy. By continually asking “Why?” we might eventually get at the truth of things.

“Why?” is all about Critical Analysis.

I am reminded of my GCSE History lessons, I had a Teacher who was something of an inspiration to me (one of very few) who I believe taught me not just about dates and wars but taught me how to think about things critically. To try and seek the truth behind things. The importance of continuing to ask the question: “Why?”

It is in order to help me answer this question that I am teaching myself as much as I can about Cognitive Psychology. In this I am not alone. Just as I know Designers who are comfortable never understanding “Why” I know of those that strive to understand and have also inspired me along this path.

We have reached a point in the Games Industry where Play-testing and Usability studies have spawned an entire industry purely devoted to providing a Designer with feedback on their work long before their game ships. This information is incredibly useful in identifying what does and doesn’t work but rarely ever gives you the reasons. For this we must turn to Critical Analysis. This is where our instincts begin to fail us.

Faced with a problem in a Game Design and with no clear understanding as to what may cause it we typically resort to trial and error. A costly process which can take several failures before you hit upon a solution. Even if you do find a solution you still may be none the wiser as to why it worked when previous attempts failed. You may have added a technique or mechanic to your arsenal but you are no closer to a real understanding of the problem or the solution.

This is not inherently a bad thing. Clearly we’ve managed to make some amazing videogames this way. I wouldn’t be able to tell you which ones but I’d be willing to bet it’s a large number.

However speaking personally I find these victories to be hollow. I’m not satisfied having just solved the problem. I want to understand why it was a problem and why the solution worked. I believe that by understanding this I will add that knowledge to my unconscious and refine my instincts meaning I will intuitively avoid or identify those problems in the future. This is the point of Critical Analysis, to help make the concious unconcious.

The ability to think critically about your work though is hindered by your own knowledge. So I push myself to learn and understand more outside of videogames. I don’t believe that everything we can know about videogames can be taught by them. The realm of interactive entertainment didn’t pop into existence with the microchip. People have been playing and interacting with each other since… well since I don’t  know when. The medium may be new and unique but the principles are not, Philosophers and Psychologists have been striving at the nature of enjoyment, fun and imagination for centuries.

So I write this blog and try to understand what it is they can teach me. And I pray that I never understand everything because then I would have nothing left to learn.