-------------------------
Poo Bear - Programming
-------------------------

This game has been worked on as a pet project for years on and off, so the first job was to replace the prototype world code with something more robust and stable so that objects could collide, fall and support one another when stacked. Once that was working I could start to use the collision system to push objects around properly.

I've implemented about 6 different types of robot so far, the idea is to make each one look and behave uniquely. Some are very simple like the patrollers that just move back and forth in a straight line between obstacles. Others are more complex like the stalker that comes straight after the player and circles around any obstacles that might get in the way.

Multiple enemy robots patrol a room
(*No lighting here remember [wink] )

There are a lot of basic puzzle games and basic platform games kicking around that simply collate a large number of unconnected "rooms" in order of difficulty. I find the lack of purpose, plot or world spoils the whole experience and rarely play such games for long (apart from Tetris, fashion cents, bookworm and bejewelled of course ;) ). Classics like Mario and Sonic with a basic story, recognizable characters and a connected world are much more interesting. This is why Mr.Robot's rooms actually map together properly to make areas within a huge spaceship i.e. engineering and cryogenics. If we can build a proper little world then we have a better foundation to hang a plot from and also introduce an element of exploration and purpose.

There are a lot of bits and pieces still to put together, mundane but essential items like locked doors, teleporters, water hazards, lifts, etc, etc. Once all the bits are in place we can start to put it all together.

-------------------------
Fost - Art
-------------------------

I've been trying out a new working methodology: usually I work thus:

• Make concept art (or model) and get any feedback.
• Rework until I'm happy the model is heading in the right direction.
• Finalise Model
• UV Map
• Texture
• Animation (if required)
• Any final shader tweaking and export

Generally, I've always tried to avoid the production line mentality that pervades many large game companies; I believe it stifles creativity. Of course, in large teams, this only works if all the artists are capaple of modelling+texturing+animating, and that's not always the case so you end up having to production line the whole process based on the varying abilities of your team (I've been really spoiled in the past by working with very talented art teams).

I thought I'd try an experiment though and see if I could speed up any of my workflow. Obviously I can't make much of a production line on my own :) but I can use some of the concepts. Basically I'm batching up sets of models and working on them as a group.

For example: I model 9 robot models, then I UV map them all, and then I texturing them all. This helps to some extent because I'm pretty slow to get into any particular task, and so modelling/mapping/texturing a big bunch of objects in one go helps cut out some of the time it takes me to get into the swing of things. I'm pretty sure it's helping out a little - I estimate I've saved about 2 days work so far on the robots.

The above does however mean that I go through long periods with little interesting to show: a bunch of UV mapped robots is a lot of work, but not very exciting to look at!


Inferno- HEL's chief 'henchbot'. Not a flying toy.[wink]


Basic droid with simplest predictable AI (bounces between two points)

There's still some work to do on the robots because the final shader set we have agreed on isn't fully complete yet so I'll need to do a bit of finalisation work 'tarting them up' with some simple controlled reflection and texture scrolling effects as soon as Goober has a free minute to finish off the shader set.

I've also been building up a complete set of scenery for the Cryogenics zone (This is where the ship's cargo of colonists are held in cryogenic suspension). I went a bit mad adding pipe sections that can be criss-crossed and bent all about the room (Might be a bit of a nightmare to edit rooms in this zone!). I've also kept the wall edges straight this time - the storage zone walls have a slight kink in them, which means they need every part to be customised (probably a mistake on my part as it makes more work for me and makes the rooms harder to edit - but it looks nice :D ). Keeping everything straight means it's easier to put things like lift sections wherever you like.


Floor tile set for the cryo zone. These are far more complicated than the ones from the storage zone; essentially their surfaces form a complete '2D' tile set that can be used to change the floor pattern however you like (Even more hair loss when editing :D ).


An example of the floor tiles fitting together, and a cryo chamber with sleeping crew member.


Cryo zone wall sections - there's too many parts to show so I've just built a little diorama here that illustrates how they fit together. Each pipe variation requres different bends/splits/junctions etc.

The last cryo zone image above illustrates one of our unsolved issues: we need to find some way to cap off objects at the edges so you don't see any outlying geometry. This would not have been a problem with the 2.5D isometric games of yesteryear, but we are obviously fully 3D so there's a new set of problems. I'm sure we'll think of something :D

I received an email from someone who really likes the texturing style (thanks :D ) asking if I'd show some more texture examples and how I build them up. I'm not sure how much use it will be, but I thought I'd include the Photoshop file too.

Here's a basic crate texture;
(not the most exciting of textures though!):


I try to keep highlights and shadows on a separate layer so they are easy to balance. If you fill a colour dodge layer with black it creates nice blooming effects over any colour that isn't totally pure (i.e. red slightly brightened up). This is how colour dodge layers worked in old versions of photoshop, for some reason, in later versions, if you don't fill the layer with black first it doesn't have the bloom side effect.
Download the photoshop file (700k)

-------------------------
Goober - Programming
-------------------------
Thankfully, with Poo Bear taking on the main game development of Mr Robot, I'm freed up to concentrate on our reusable engine and the Mr Robot editor. Currently my tasks revolve around providing enough editor functionality to allow Poo Bear to continue working on his tasks without having to wait around or change to something else. The editor, while somewhat clunky and quirky in its operation, is reasonably usable. Of course, there's always ways to improve its user-friendliness, but the tool is for in-house use only at the moment, so we're concentrating on getting things working and working robustly before concerning ourselves with making it particularly nice to work with. Should there be opportunity I'll improve the way things work.

On a side note, I stumbled across an entry in the MSDN describing a couple of interesting compiler switches that can be set in MSVC, /Gh and /GH. What these do is tell the compiler to call into two specific functions at the entry point and exit point of all functions in projects compiled with these flags. Use of this facility is a little bit weird because while in the _penter and _pexit functions you write, you cannot call any other functions if there's the possibility they've also been compiled with the /Gh or /GH switches, because that will end up calling back into the function you just came from and you can wave goodbye to your stack.
Why is this useful? Well, for one you can track which functions are called in your application, it's a simple matter to get the return address from the stack and fix that up so that it matches the addresses in the linker map file. It's also possible to implement a simple profiler by getting the CPU timestamp counter at the start and end of a function and working out how many clock cycles expired while in that function. Obviously it's a little more complex because you have to take recursive functions into account, but it's possible, and could be easier to work with than how we traditionally profiled our code using g_profiler.Start( blockname ) and g_profiler.End( blockname ) type calls. Explicit calls are ok, but they do require the programmer to mark the entry and every exit point of a function. By having the compiler do it for you, you reduce the possibility of silly mistakes.

What this culminated in was a very simple sort of profiler that we can use to tune our applications. Currently the output is very primitive, consisting of a function address, total clocks spent in the function, number of calls into the function and average clocks per call. What I'm planning on doing is writing an app to parse the linker generated map file and the profiler output and display the information in a friendlier way (i.e. having something resembling a function name), and being able to export to .csv file or something similar. It's not VTune, but it'll give us enough information for us to be able to pinpoint bottlenecks and work out solutions to performance problems.