-------------------------
Fost - Mr. Robot Art
-------------------------

Escape Velocity

Finally finished all the programs for ghost hack so rather than post pictures and spend time writing a load of waffle (that most people ignore anyway :) ) I've put my dev diary efforts into editing together some video captures of some of effects (see below). Note, these normally take place in the virtual world of ghost hack (which we haven't seen much of yet), but for now I've captured them in a 'padded cell' test room :).

The most fun I've had with effects is to use attraction controllers - I've ended up having to work out some basic maths for them so I can put particles into orbit around the controller. When you hit the right combination, you can get some lovely effects as they spin around. It's quite fun to set an enormous lifespan on the particles and watch as their orbits slowly decay and they eventually float away, since you can never get it 100% right. Of course, if we had minute long effects, ghost hack would become pretty boring, so I've tried to make most of the effects quite brief.

Ghost Hacking Video Reel

High res downloadable version (35 Meg, Mpeg)
Or, if you prefer:
Google Streaming Video
YouTube Streaming Video

------------------------------------
Poo Bear - Mr. Robot Programming
------------------------------------

Bug Bonanza

When a game project moves into its final phase a lot of disparate systems begin to mesh together and people (new users) begin to explore their interfaces as the game takes proper shape and becomes fun(ctional). Systems that were tested and seen to work in isolation suddenly fail as code paths are exercised in new and subtly different ways. I hear people complain that newly released games are often not properly tested and contain too many bugs and obviously they have a right to feel upset, but testing a game properly is extremely difficult. Mr. Robot is just now entering this problematic birthing phase where we are starting to shake out all the skeletons that have long remained hidden within the games many forgotten cupboards.


The front end, coming together nicely, except for that class A bug taking out the debugger...

We will certainly be beta testing the game to bullet proof it further, but some amount of internal testing must be undertaken first lest we be drowned within a deluge of obvious and avoidable bugs from our unhappy testers. The volunteer beta-test team have a right to expect a fairly stable game. However, before even internal testing can begin I must wrestle the many subsystems within the game into compliance. In some ways this is one of the more stressful periods of development as many extremely obscure bugs will be exposed and require me to work long into the wee hours to lay them to rest.


JJ (from Starscape), now an out of work jobbing actress, stands in until the final cast arrives...

The main culprit in this time of woe is memory corruption, it can have many causes and is simply an area of memory that is written over in error destroying whatever was there initially. The most insidious example is when an error causes a piece of innocent empty unused memory to be overwritten causing absolutely no problem whatsoever. Why is this insidious? As we approach the end of development different systems begin to ramp up with their full in-game content, where we initially had 10 sound effects, now we have 200. This is a huge change in memory layout and what were empty or unused areas of memory remain no longer and all of a sudden evil little bugs that have slept quietly for years suddenly wake up.


Inventory, now working perfectly.

There are tools to help out like Compuware's Boundschecker or Rational's purify, but they are very expensive, fragile and complex tools. If you have deep pockets then it would make sense to get one early on and start using it regularly throughout development. Both come with something called "code coverage" which allows you to see how much of your code actually did anything when you ran it. It might seem odd, but this is extremely important as you can create a "test plan" designed to ensure every little bell, whistle and knob gets tweaked during testing. If you aren't exercising every code path then you aren't going to find as many bugs and the devils will lurk undiscovered only to pop up months later when you've forgotten how that system works.


Auto unlock: In game key system.

Deciding What's Next.

As one project slowly grinds to a conclusion, thoughts of the next come to the fore and the plethora of "clever" ideas and swiftly jotted musings that form the game ideas vault are pored over with renewed vigour. The time between projects when ideas are unconstrained, fleeting, paper-based entities is definitely one of the most joyous. As the new project draws near the harsh light of reality forces its way in and begins to burn away many of these flights of fancy. If people were happy with text adventures then we could create epic journeys into the stars or voyages to the very depths of hell and back. However, people want a lot more than a great idea, they want a professional, polished, piece of entertainment served with the minimum garnish of "work" and bothersome "education" and lashings of thrills and eye candy. When I say "work" I mean the effort required to master anything new or unfamiliar. When I say "education" I mean the instruction required to understand what it is you are actually meant to be doing. Don't under estimate "work" and "education". If you've been brainwashed by a multi-million dollar hype campaign and shelled out $50 then you have a pre-built desire to push through any shortcomings, invest some real time and mine out that core of goodness in all games. If you're looking at a free demo it took 2 minutes to download, of a game you've never heard of, while waiting for "Lost" to start on tv, then it better be smooth sailing and instant thrills! So how do you create something so slick and beautiful and yet stand even the slightest chance of delivering it within 12 months?

Don't ask us! Mr. Robot stands testament to our failure to deliver in a timely fashion. :)

Can we change all that? Can our next project deliver something just as innovative, fresh and pretty, but in half the time? Should we even try to work so quickly?

One of the problems with Mr. Robot was the time spent prototyping the idea to start with. It's quite an unusual mixture of puzzle solving, adventure, platform action and turn-based battling. It took many months of experimentation to crystallize those conflicting ideas into something cohesive. Then there was the huge amount of custom hand made content.

If you are trying to make something nebulous within a specific time frame it can help to think about those elements that are more predictable. As you chop away at the available time you begin to see just what is feasible and what isn't. Saying you have a year, or two years to make something sounds a lot, but when you begin to break it down it is amazing to see how quickly that time is eaten away.

1. Update Starscape: The 1.6 update list has been gathering dust a long time, so it is essential we get onto that as soon as we can and it will take at least a month to complete. This isn't even adding new content, just minor improvements, bringing some of the admin systems into line with Mr. Robot, non-critical fixes, etc.

2. Investigate new middleware: After losing our tools programmer we are now far more interested in open source solutions than hiring a replacement. Letting one person create a full set of industry standard tools is a mammoth task and it is very risky to rest everything on custom built foundations written by one person. Some work can be done beforehand, but you will still use at least a month setting up a new renderer, sound system, networking, physics, model exporter, etc.

2. Prototyping: Even if your idea is not innovative you must still do some basic prototyping to ensure everyone understands what it is you are trying to make and what resources you will need. As the prototype takes shape you will get an idea of the tools needed to build it, this usually involves a custom editor of some kind and a scripting system. Even if you are proposing a very simple game you will need at least 2 months here unless you are simply remaking a previous game with minor improvements.

4. Creating tools: Once you have working prototype tools it's time to flesh them out with all the added functionality and time saving features that are essential to prevent your content creators killing you out of frustration. It's vital that your production process is smooth and efficient so expect at least a month here, anything more complex than a few text files and it will take a lot longer.

5. Production: Hopefully you don't have any more questions hanging over the project and everyone can just get on with it. This is the one area that is flexible on time, do you want 10 levels or 5?

6. Testing: A critical phase that it is all too easy to skimp on; expect at least 2 months.

7. Contingency time: However long you think it will take, it will take longer guaranteed, just accept it. If you genuinely believe something will take a year then you better add 2 months on, sad but true.

So if we are proposing something simple (i.e. nothing like Mr. Robot!). With ideas and technologies that aren't too unfamiliar, so it has a chance of a 12month schedule, then we will still need 9 months minimum not including production. So the question then is: how can you produce the content for your game (production phase) in just 3 months? With Mr. Robot each room was hand made and there was a constant need for new room artwork and new hand coded challenges within the rooms. So unless we want a very short game indeed we need to procedurally generate some or all of the content. Starscape is a good example of partial procedural generation as script files were used to create the game universe and seed it. Starscape's universe is quite small but procedural generation can be taken a lot further, just look at Elite or Diablo.

The drawback to procedural generation soon materializes in repetition as human beings are quick to spot patterns and similarities which they then tire of quickly. So procedural content can save time, but to create truly compelling procedurally generated content is very complicated and would take a great deal of research and therefore more time; the one thing we don't have! So it would seem a game like Starscape is what is needed, something driven by a procedural engine yet tightly guided by the hand of a designer. A compromise.

Analysing such a nebulous problem as your next project is very difficult and I suspect there is no solution that is both exciting and risk limiting. I sometimes envy true indie developers, people who make games in their spare time while either studying or holding down a full time job. I personally cannot work on something part time like that, I have to commit all my energies to one thing. However, you are no longer truly independent as the financial pressures of real life soon seek to push you towards shorter schedules and a faster turn around.

Leaving the mainstream industry behind we thought we had defeated the demon entirely, but sadly we just wounded it. We must still find balance in all things even if that means reigning in our ideas and cooling the forge of innovation.