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.

However there is more recent footage on the interwebs than my youtubes contains thanks to Epics UDK trailer they made for GDC2010.

The good bit is around 2:37 the rest of the video is clearly rubbish.

So things that are new in this version:

Pickups!

These will home in on you once you get close and form the basis for just about all pickups and rewards that will be in the full game.

Slowmo!

Collect Pickups to recharge your Slowmo-o-meter and then hit the right mouse button to slow down time. Very useful when you get yourself surrounded.

New Spawning Code!

OK so this isn’t noticable or will affect gameplay but it was some much needed rework of the code that was really holding back further development until it was done. This also gave me an opportunity to do a quick revamp of the Wave structure. It’s still dead simple but now no longer dependent on you killing one wave before the next starts. Depending on how well you are doing you may get ambushed.

The Future!

The biggest thing to change so far is going to be the way the waves are structured and managed. I have an idea for a system that is semi-scripted so certain things can happen at certain points in gameplay but largely procedural based on how well you are playing. Hopefully this will mean that better players won’t get bored trudging through easier stuff. Unlike most “Dynamic Difficulty” systems though this will mostly worry about making the game harder rather than making it easier. The later tends to rely on things like the player dying over and over and getting frustrated until the game is finally easy enough for them to progress which sucks.

There are also plans for an early alpha release as a kind of demo but I’ll blog about that closer to the time.

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!