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

Set Design - Final Touches.

- click image for flash anim...
Like a human tube of polyfilla, I've just been concentrating on filling in all the holes in the scenery objects list. As Poo Bear makes rooms, he makes a note for me of anything that he needs. For example - we've been using Storage area doors in the cryo area, so I've made some shiny new doors for cryo (left). I've also been going through the rooms and adding a few little unique bits of scenery - there's more than 200 static (i.e. not counting robots, items or anything that can be moved around) scenery objects in the game now, so it doesn't look too repetitive, but anything that helps break up the look of the backdrops adds that little bit extra to the overall impact of the game's look. Lighting is also proving to be a great way to alter the look of the rooms.

Anyway, enough talk! This month I'm just going to fire scenery artwork and room pictures at you.


I removed the insignia from the shuttle, so I could add it back in using an overlay object. This means I can have a different insignia decal for each shuttle- just another little thing I think is nice to do so that each room in the game world has small touchness that make it unique.



Fat pipes make great dividers for the cryo section.



Just a corridor, but I really love the way the cryo walls pick out light - cryo rooms are the most fun when playing with lighting setups.



Samson sized service corridor.

Top Tips!

This month's mini development tip - many applications have a hidden away option to increase the number of files in the recent file history list. I've been through all the apps I use on a regular basis setting that value to the maximum. My memory has never been very good, and I waste a lot of time trying to remember where I left things on the hard-drive so this helps enormously. In particular with the text editor I use for editing shader files/objects lists/config files etc this has been a minor triumph of technology over memory loss :)

Locker Room

- click image for flash anim...
It's great when you can re-use existing systems. This locker model uses the same game systems as the doors. The front is using the door texture scrolling mechanism to 'roll up' like a shutter. Items can be picked up by searching lockers througout the game.

Magic Pockets

Started work on the inventory items - things Asimov can pick up in the game. There's going to be a ton of items once we get deeper into ghost hack (you can pick up special programs and hacking tools to use in ghost hack). Each item needs an icon that shows up in your inventory, and also I'm adding a 3D model so it can be left on the floor - these aren't really necessary, as everything is picked up in lockers at the moment, but it means the game won't break if someone tries to put an item on the floor. There's already a growing list of ways you can easily break the game because of things you do in the editor, so I'm trying not to so anything that makes the list even longer. We'll have to fix any of those problems before we think the editor can be released, so a little bit of work now is another step towards the editor being public usable.

Secret Squirrel

- click image for flash anim...
Quite a bit of work has being going into the finale of Mr. Robot this month, I did have some images of HEL (the ship's computer) and animation showing him in action, but we decided we should pull them - we've gotten used to being open about what's going into the game, but we should really leave a few surprises in for you! HEL is semi-procedurally animated - I produce an animated control mesh, and sets of objects, and Poo Bear glues it all together with code. I've also been doing a set of scenery objects for the 'Mind Core' section of the ship where the action comes to a head. Again, we want to hold much of that back, but here's the door object I made.

Needless to say, it was a complete and utter nightmare getting this to work :) It uses the existing door code with an edited shader - so Poo Bear doesn't have to do any work. The shader takes the door opening and closing values and uses them for the texture rotation after scaling them to suitable values. The iris door has 9 blades which I lined after finding a diagram in a technical manual for repairing cameras! I've wanted to make a door like this ever since I saw Dallas crawling around in those air ducts in Alien :)

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

Formula Parser

I've talked previously about the power of the LUA scripting language, but sometimes you don't really need that level of sophistication or the program overhead of setting a full LUA instance up in memory. One obvious example is when you are filling out an initialization file for a game entity like the ghost hack enemies. This simple text file contains default starting values for different bad guys, things like name, model to use, animation lists, strength, etc. Some things however, are better expressed as a formula, see below for actual MrRobot examples:

       key	                                      value                     fortitude_formula                    val = 2 + (level / 2);     energy_inc_formula                 val = 1 + ((0.5 * die) -2); 

To make the game use this formula I could have created a LUA instance and executed it that way but I already had a simple function parser on hand that had less overhead and was cleaner to setup.

Done this way the game can pull these formulas out of the initialization files, save them as a small text string and then when needed they are executed directly via the mini formula parser. The words die, level and val are special keywords the parser understands. Without this kind of functionality a game will become littered with hidden magic formulas that can have a major impact on how a game plays. By exposing them in the initialization files a non-programmer can change them as necessary and we don't need to dig through source code to find them or recompile the game when they change. Obviously there is an efficiency overhead associated with doing this, but if it doesn't impact on framerate then its definitely the best approach. This could have been done in Lua almost as easily, I just want to highlight the power and flexibility of scripting languages in general and data driven design techniques specifically.

Download Size

Even in these days of broadband, download size is very important. I think the USA is on track for 65% broadband coverage in the next year or two. So there are a lot of modem users still out there. Even with broadband, file size can still put off people who are browsing and aren't necessarily hunting for your game.

When you look at the size of your game installer you usually find a very high proportion of that space is taken up by artwork. It's a rule of thumb, but most textures are often around 256x256 pixels, so they look nice and crisp at fairly high resolutions like 1025x768. Each pixel has an 8 bit red, green, blue and alpha component. We don't always need the alpha part, it is used by the hardware to control transparent portions of the image. So our example texture will take up 262,144 bytes on disk. MrRobot has about 300 textures currently, which is roughly 75MB. Using something like winzip we can get that down to about 15MB with no loss of quality, a 5 to 1 compression. Now instead of saving the images at full quality (using the tga format) we can use a lossy format like jpg. By saving the image out as a jpg you are pre-compressing it and the harder you do it the worse the image looks. As the compression system is vaguely similar to winzip anyway, then you haven't saved much as winzip wont be able to make a jpg much smaller if at all. The only benefit is you can set the compression level per image by hand, so some might be forced smaller without suffering loss of image quality. So you might get up to 6 to 1, but probably with some image quality issues.

An evolution of the jpg format that isn't widely used is j2k, which means jpeg 2000. This system is far superior to jpg and can easily compress our source artwork at a 10 to 1 ratio, from 75MB to 7.5MB with little to no perceived loss of quality in most images. What I normally do is compress everything at 10:1 and then do a run through of all artwork at the end of the project lowering the compression on the 1-2% of images that are highly complex and suffer artifacts.

The power of j2k has a downside which is extremely slow encode and decode times due to the highly complex nature of the algorithms being used. Probably the oldest freely downloadable j2k library is jasper and the creator did a great service by releasing it. The only problem is, speed wasn't a priority in its development and it is very slow.

www.ece.uvic.ca/~mdadams/jasper/

Encoding time doesn't really matter, because we encode the images once when building the installer. It's decode time that is vital, the image must be decoded back into a flat 32bit image so the graphics card can load it. Or if you're very clever then one of DirectX's compressed formats like DXT3.

All is not lost. A new decoder codec saves the day by being about 40x faster than jasper and unlike all the other big companies making decoders it doesn't cost $10k :) I was also shocked by how easy it was to use compared to jasper, just a couple of lines of code and away it went.

www.j2k-codec.com

You can see an uncompressed (1 meg PNG) image comparison by clicking below :



The new codec is so fast we don't need to have a decompression on install application. Starscape used to install and then launch a small app that crunched through all the images and it took minutes on low spec hardware. The next version of Starscape will hopefully have a rewritten decompressor app that should just take seconds. I think it is worth keeping that post-install decompression app as Starscape is meant to run on very low spec hardware and has a huge amount of artwork. MrRobot being a fully 3d game, is far more efficient with regards to texture space and also needs a higher minimum spec machine to run. Therefore I'm probably going to leave the textures in their j2k format and decompress them on the fly when loaded. Initial tests showed this made the one-off game start load go from 9sec to 13sec which I think is fine. Further testing will be needed of course, but I think it's worth a slightly slower load to make the install process faster and simpler.

Early Usability Testing

The core game (everything but ghost hack) has now reached a point where some basic usability testing can come in handy. We have a small test group of computer illiterates that we find handy for this kind of thing (parents or grandparents are usually very good depending on their familiarity with computers - obviously, some basic knowledge is required.)
We then sit them in front of the game, and let them go. The important thing is not to guide them. Reinforce in advance that this is not a test of them, but a test of the game, and there are no wrong answers - otherwise you end up with them being overly cautious and not wanting to feel stupid trying things. Then just note down what they do, what buttons they click on first etc. You can even video the whole thing if you have a camera handy. If you come across an interface problem, or a bug, then you can just help them past that point and explain that it's a problem with the game, and carry on.

This initial pass has highlighted some basic issues with the tutorial - mainly a couple of points where the player can become lost, or miss something like a door that has been opened for them. Not too bad, and pretty easy to rectify. It's nice to get a lot of things out of the way before beta.

One thing that has been suprisingly successful is the camera. A couple of people in the group were originally chosen to test Starscape because of their inability to play 3D games. It seems that the fixed camera, whilst obviously a choice we made to make development easier on ourselves, also helps people with atrocious spatial awareness make sense of their in game surroundings. They do have some initial trouble with the 'isometrically' lined up controls - 'up' being 'up-right', but they soon get over that, and it's amusing to see people who have never been able to play Mario 64 jumping around like rabbits after 5 minutes with Mr. Robot. When we get nearer release we will do a larger beta test with people randomly selected from those who bought Starscape. With a large beta using players all over the Internet it is important to have squashed as many bugs as you can beforehand. When people are not actually in the room with you it is a lot harder to properly analyse their input.

Procedurally Animated Models (sort of...)

The game's finale takes place inside the 'mindcore', a set of rooms surrounding the ship's supercomputer: HEL. In designing what HEL should look like, we came up with the idea of an animated head built from lots of small cubes. The vertex data to do that would be huge (we estimated 30 meg+ just for HEL's animations!) so we came up with another idea: Fost creates an animated, low poly 'control mesh'. We then read this in and build a representation of it from lots of cubes. the entire thing is then shunted off to a dynamically allocated vertex buffer. It looks pretty nice, but you'll have to take my word for it, as we've made the decision to leave most of the mindcore art as a surprise for everyone Wink

Super Powered Batch Files

When preparing the installer we need to pull in exactly the right files from all over the development machine while also applying any special processing like image compression. This is more difficult than it sounds as the game probably has ~700 different files and the development system probably has double that in temporary, debugger, build files. With Starscape this was done using some hand written instructions (which were then lost) and some horrible windows batch files.

Once again the power of Lua comes to the rescue, if you download Lua you'll also get a standalone exe that can load lua text files and execute them. This means your batchfiles suddenly have all the power and sophistication of a programming language. I didn't end up using the interpreter that comes with lua as I wanted to add a few extra functions to do some specific things. Very easy to do, just code them up in C++, tell lua about them, build a new exe and the lua textfiles can then refer to these functions by name and pass data around as if they were built into the language. You can do everything a batch file can (as far as I know) and a huge amount more and the files are infinitely easier to read.