Not a lot to show this month; even though we didn't take much of a break during the holidays, we did lose about a week.
I've also been trying out a new working methodology that means not much is 100% complete: 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've modelled 9 robot models, then I UV mapped them all, and right now I'm 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 all I have to show this month are two new robots and a bunch of UV mapped ones (a lot of work, but not very exciting to look at!)

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

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.

For the first two weeks in December I've 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 ). 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 ).

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

I also received an email from someone who really likes the texturing style (thanks ) 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'll try and dig up one of the Battlescape ones for next month.:

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)

Last edited by Fost on Mon Jan 10, 2005 9:51 am; edited 25 times in total

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 )

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.

On a final note: We've received more than 20 emails this past month from various people saying they've found the developer diaries lots of fun to read or even helpful in their own work (I think some people were concerned because of our occasionally erratic diary release schedule ). That's great thanks for the support! We are really glad people are enjoying them as they are a fair bit of effort to write sometimes

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.

Incase you missed the news entry a few days ago, The Dev Diary is now available via RSS here, and always from the link at the top of any dev diary entry:
Oh, and if you have no idea what I'm talking about, have a look at our RSS explanation page.
So you should now be able to get the diary entries as soon as they appear (which is pretty handy considering our random release shedule )

Gridites - move around on the raised walkways taking random turns down junctions.

Crazy ivans - move in a straight line until the hit something at whoch point they turn a random amount and move off again.

Lefties - move in a straight line until they hit something at which point the try to do a 90degree left turn before carrying on. If they are blocked they try a 90degree right turn and if that doesn't work they just reverse their course.

Orbitals - they follow the edge of whatever they are touching so they tend to move in circles around obstacles.

Each robot looks different and as you can see from the above descriptions they all behave differently. As you play the game you will learn to recognise them and then start to be able to avoid them or even use their behaviour to your own advantage. Predictable enemies are pretty fundamental to any platform game, I suppose the more types you have the bigger the game can get without repeating itself. There are still a few more robots to implement yet, but I think this enough to get the first zone of the ship working.

Crazy ivans - move in a straight line until the hit something at whoch point they turn a random amount and move off again.

Like the scientists from Rescue!

Poo Bear wrote:

Lefties - move in a straight line until they hit something at which point the try to do a 90degree left turn before carrying on. If they are blocked they try a 90degree right turn and if that doesn't work they just reverse their course.

Like the boulders from Dungeon Keeper!

Poo Bear wrote:

Orbitals - they follow the edge of whatever they are touching so they tend to move in circles around obstacles.

Like the spirits from Repton!
(I used to have all the Repton games on the BBC. Looks like they're still about.)

And the mice in Chu Chu Rocket I think I am finally starting to see the light! The different combination of enemies where you can learn to predict their movements will be really interesting, and the more you add should make it exponentially more fun.

I can't see either of the applets working, which is a shame because they look interesting.

There must be many games that use the idea of the lefty type robots. There's one on the tip of my tongue even, that looked a bit like boulderdash's side view, but was more like chuchu rocket in execution (in that you set up the play area, and hit go).