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.

This includes the UI, Scoring and Online Scoreboards.

I find procrastination tends to set in at the end of my projects because of these boring bits and because I don’t have any work left to look forwards to on the other side of them. Being able to implement some awesome stuff is a great motivator for implementing the boring but essential bits.

So with this in mind I am trying my hardest to get as much of this out of the way now so that when I come back to it again in future it’s just to tweak and bugfix it which is infinitely less dull.

However this doesn’t mean I’ve not done anything on the game itself. It’s just that most of what I’ve done are small tweaks that annoyed me and were easy to fix. Things like making the game work at resolutions other than 1280×720 or fudging the camera so you can see more of the arena when you are near the walls. That kind of thing.

I’ll be back soon with an update after I get the boring bits out of the way.

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.

So to update: I decided to ditch my efforts to make a physics based puzzle game for two reasons:

1. The cap on angular velocity.
2. I wanted to make a game where you get to blow things up.

If I’m honest it was mostly the blowing things up bit that turned me.

So using what I had already built as a base I started experimenting with making enemies that I could later shoot at. There was much messing around with navigation meshes and pathfinding before I eventually decided to ditch anything remotely complex and keep everything as simple as I could.

This resulted in an “Enemy” that looked exactly like the player and whose only behaviour was to roll towards them as fast as they could. Heck entire games have been sold that only have this behaviour.

With my simple enemy type I set about coding up a simple weapon class and targeting system. Bullets get shot towards the mouse. I used the basic Projectile class that is built into Unreal for my bullets and wrote a simple state machine for my gun that just spawned a bullet on a timer.

Behold!

This however was about from a week ago. This weekend I decided that it was time to give the game a full visual overhaul and get some sound up and running. You can see what the result of all that effort was beneath the cut:

I think it’s quite spiffy myself. The balls are still there but just hidden so the physics remains the same (although I’ve gone back to using impulses and not torque to avoid the angular velocity issue).

As well as giving the game a complete new look there were innumerable tweaks, bug fixes and indulgences that went on. Just getting the explosions to change hue over time was a couple of hours work alone and there was about 3 hours of completely failing to understand the math behind line-circle intersections in order to fix an issue with one of the enemy spawners (the friendly people in #Unrealscript will recall me appearing briefly just to rant about it last night).

Right now however I have a huge list of things to add, I have lots of different enemy types to add as well as more feedback and effects to implement and one game mechanic in particular that I think will be very interesting.

It’s been tentatively titled “Zero Point” by the way. It’s not a great name but I was tired of calling it “TestGame” feel free to leave suggestions in the comments thread.

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.

An interesting problem that crops up occassionally in Second Life is the question of Whether or not a Viewer bug that affects rendering should be fixed.

In most MMO’s the idea of fixing a bug is a very simple thing. Bugs are bad and there to be squashed. However as soon as you have an economy that pushes roughly $450m a year around the world you start to get into all sorts of problems.

The most recent issue is a fix to the order of Alpha rendering on Avatar Skins. Ever since I can remember The Eyebrows and Lips were rendered below the texture and this has been used by Skin makers to allow users to modify their skins without destroying them by making the lips a little darker or adjusting the overall skintone.

As you can se ein the picture above though changing the render order to draw these elements above the texture can have some very nasty side-effects that could threaten to ruin the Skin industry.

Fortunately this fix is being reverted by Linden Labs as they aren’t so stupid as to incur the wrath of their entire customer base and destroy a lucrative industry with a few lines of code.

The original bug report (and hysterical comments) can be found here.

You can find my musings on the impact of Second Lifes economy on it’s technical progression beneath the cut.

Over the last ten years we have witnessed significant changes in Videogames rendering technology that have made games look more realistic than ever before. However these changes have always come at the cost of increasing the amount of art and amount of skill required to make that art.

Take the mode scene for Unreal Tournament or Half Life. These two games have a HUGE amount of fan-made content of a good quality. Fast-forward to today and there are less mods and maps being made for Half Life 2 and UT3 than previously despite the communities actually getting larger (well at least in the case of Half Life).

The problem lies in the difficulty of creating content for these games compared to their older more simplistic versions. Mods require bigger teams with more talent and skill. It’s harder to make a fun Deathmatch map for UT3 than it used to be not because of any gameplay reasons but because nobody will download your map if it doesn’t look any good. You may be a great Level Designer but if you aren’t also a good artist nobody will care.

This problem is even worse for a Virtual World like Second Life. For years now it’s residents have been creatively working around the Viewers limitations and even using bugs to their advantage (the entire Jewelry industry is based on twisting Primitives into sizes that they technically shouldn’t be capable of).

Second Life is stuck in a position where embracing technological advances can destroy existing industries and as a result the livlihood of countless entrepeneurs.

That’s alot of pressure to be under.

Take Shaders for example. Second Life can’t afford to increase it’s minimum requirements to support more advanced shaders for several reasons.

1. A huge number of Residents are using very old hardware that won’t support it.
2. A Two-Tier economy is created between those who can’t take advantage of this new technology and those who can.

The first point is fairly self-explanatory. Linden Labs don’t want Residents to leave the world and take their money with them.

The second point is slightly tricky though.

Taking the Skins industry as an example I would love to see a viewer that supported advanced shaders so I could see even mor erealistic Avatars with better lighting and shadows etc etc. However anybody that decides to create content that takes advantage of this new technology will find themselves in a situation of creating content twice. The High-definition versions for those with the Hardware to render it and a Fallback for those that cannot. After all even if you can render and see your spiffy Normal Mapped Avatar somebody stood next to you in-world may not. However they still need to see something and you don’t want to show up as the default avatar after spending all that money on your new look.

Could the economy in Second Life support this route of premium content for players with modern hardware? I don’t know. That’s really for an economist to answer. I do however know that it will put alot of pressure on Skin makers to support this market in addition to the existing one and only reduce competition driving out those who aren’t able to adapt to the demands required by the new technologies.

So for the time being the rendering in the viewer remains largely untouched in an effort to retain the status-quo and a stable economy.

What does this mean for Second Life in the long-term with lots of new Virtual Worlds coming along claiming super-realistic graphics as a feature? I believe these newer worlds will struggle to generate enough worthwhile content to draw people away from Second Life until it is as easy to make content as it is in Second Life.

Second Lifes biggest advantage in the battle of the Virtual Worlds is in it’s low barrier to entry by using older more stable technology.

Now if they would just let me rate Places with a star rating so their in-game search engine no longer sucked that would be abug worth fixing!

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.

Day of Darkness II from Dire Lauthris on Vimeo.

It is a real shame however that the actual fleet combat in the game isn’t anywhere near as fast-paced or close-in as the combat in this video.

To CCP: If you want an experienced Designer to head up a project to create a single player narrative driven space combat game based on the history of Eve with a direct control combat model then I am volunteering for the job!

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.