• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Fost - Art

Move Your Body

Goober finished animation support a while back, but I didn't have time then to test it. We are using the MD3 model format (from Quake III) for animated models only. There's some limitations compared to our own format, such as no vertex colours/multiple uv sets, but it supports animation frames, and more importantly, there's a lot of existing, cheap/free animation programs out there that also support MD3. There was a lot of free loader code knocking around which meant Goober could get something up and running quickly.
Getting a model into the game is not as simple as just exporting it because we have to tag the MD3 with our own shader system files, so there's also a separate text file that sets that up. For my first animation I again tried using a bunch of separate meshes exported from wings 3d. I have to say - I would never recommend anyone try this :) It's the worst way you could animate EVER! Basically I'm getting animation out of a modelling package that doesn't support animation. I export each model to a numbered set of moonpod models, and then use a commandline tool that Goober has written to compile the MD3.

This is truly awful, not just because the export process is slow (even when using lots of batch files to automate it), but because you have to animate each frame in isolation, and you can't see the others. I ended up making a pencil rough of the animation on paper, scanning each frame, and then using it as a backdrop to line everything up. then if anything looked odd on the pencil test, I could take a screengrab of the model, print it out, sketch over it on my lightbox, and adjust bits until the pencil test looked good. Then I can use that as a backdrop in wings3d to line up all the objects.

Incidentally, at this point, I must publicly thank Stan Hayward, creator of Henry's Cat, for the valuable animation talk he did on the BBC many years ago. I just had a look and found that Stan has loads of 'getting started' animation lessons here

Mr Robot: Asimov Pencil Animation Test
Animation Pencil Test

Anyway, that's obviously not going to work as a plan for animating the rest of the Mr Robot models, so I need to investigate budget modelling/animation packages. We bought a copy of milkshape ages ago, and I've been putting off learning anything about it, but it does seem to have everything I need to do animation properly and also exports direct to MD3. I'll probably still continue to model using wings3D (I've gotten pretty comfortable with Wings3D over the past few years), and then animate using milkshape. I seem to have a knack for inventing convoluted art pipelines :)

Here's the result of a lot of effort - a 16 frame walk cycle :)
(2.5 meg flash video)
Mr Robot: Keep On Walkin

ORGUS: A Brain The Size Of A Planet!

We have quite a lot of robots now, but, you can never have enough! Here's our latest addition to the friendly bots on the ship, meet Orgus!

I often model the robots after an initial rough (I call them toilet roll doodles:)) because it gives me enough of a silhouette to know I'll like the end result.

For friendly bots, I tend to work this up into a far more detailed picture - they have for more personality than the enemy bots(I hope!), and it's important to me to get that across. The enemy robots are deliberately 'soulless' and I can usually nail them with a quick scribble.
Mr Robot: Orgus Concept Art Stages
Orgus Concept Art Stages

Orgus' design is based on how I'd always imagined Marvin the robot should have looked when I read 'The Hithchiker's Guide To The Galaxy'; essentially an enormous brain with legs and arms.

Orgus is slow and weak in the physical world, but will come into his own during ghost hack where the processing power he has available can kick butt!

Mr Robot: Orgus Final Game Model
Orgus Final Game Model

Water Vertex Shaders

Not the most interesting way to use vertex shaders, but we've used a vertex shader to scale the textures up and down with water blocks. this means that no matter what size you make them in the editor, they always come out looking the same.
Mr Robot: Water Vertex Shader

Poo Bear - Programming

Battle Control

Battle mode brought with it quite a large management overhead in menu screens as I discussed in our last journal entry and now we have the second menu screen load to implement. This time we need mini-screens within the actual battle for things like:
  • deciding what each of your avatars is going to do in the next round.

  • changing the currently equipped items (ice and ice_breakers).

  • selecting a program to fire off.

  • selecting a carried item to use.

  • selecting a special attack.

Menu screens are a real pain, they aren't the most exciting aspect of development yet they are vital to the players experience. They don't usually contribute to the fun but they can easily get in the way of the fun and therefore a lot of care needs to be taken in their development. A lot of the functions within a battle are streamlined replications of the larger menu screens done previously. Why bother? why not just make the player switch to those other more detailed screens? That would have been easier but it would certainly have got in the way of the fun. It would have meant bringing up a full screen menu right in the middle of a battle; not a good idea. Menu screens are a tool to let the player operate and interface with the game, they must be intuitive, enabling and transparent. When the game goes beta we'll enter a cycle of user testing and alteration, not just to fix bugs but to make sure the menus don't get in the way.

Streamlining Workflow

If you ever want to give yourself a shock then take one work day and try and analyze your efficiency and work rate. It is difficult to do because if you consciously try and analyze what you are doing from minute to minute it will affect the results. How much time do you spend chatting with colleagues, eating snacks, at lunch, reading emails, browsing the net, day dreaming, writing emails, checking the newsgroups, going to the toilet, in meetings? Now take into account that the human mind cannot stay focused and concentrated on a specific task for long periods and that once distracted it can take up to 15mins to re-enter "the zone" - a fully concentrated state of mind. So before we've even looked at the tools we use we have an uphill battle just to get a decent amount of work minutes each day. Now consider what you are actually doing and how worthwhile it is. Whether you are an artist or a programmer you will spend your time making minor changes and then reviewing them in action. You tweak a texture on a model, save it, export it, run the game, load it, get to the point where the object in question exists, use it, review it, repeat. Same thing happens with code, alter something, compile a new exe, run the game, get to the point where you can see the change, review it, repeat. The bigger the game gets the slower this loop becomes. If you manage to get 2 hours of useful work a day (yes it can easily be that small) how much is spent clicking buttons, waiting for compiles to finish, loading saves, navigating to a certain point in the game? How much of that super valuable focused work time is wasted? The key to maximising work time in game development is fairly obvious:

  • let the game reload everything on the spot without having to turn it off and restart.

  • put the minimum number of clicks between starting any operation and completing it.

  • Automate everything assuming the normal best practice, if there are unusual cases then add provision for handling them but don't break a smooth automated process just because 1 time in 10 a user needs to make a decision.

  • Put time into tools, they are boring and dull but are vital. The easier it is to do something the faster you can do it. The faster it is to do something the more likely you are to have time to experiment. The more experimentation is done the more unique gameplay emerges making a better game.

  • Use scripts and initialization files wherever possible, if changing something means recompiling then only a programmer can do it, it will take time and therefore it wont happen most of the time.

LUA scripting

This month as part of that mantra we've started putting in the LUA scripts that operate any unique functionality in a room. A room doesn't need a script as most things happen automatically i.e. running, jumping, pushing switches, getting killed. However, if that was all there was to it it would be a little clinical so when we want people to talk to you or something unusual to happen we put it in a script. That way a programmer doesn't have to write it or test it, all he has to do is provide support functionality in the form of a suite of functions the script can call that make things happen (that's my next pile of work spoken for then ;)).

We've also been implementing one-click context sensitive reloading, this means whatever you are looking at in the game you just need to hit one button to make it all reload.

Player Animation

The game now supports morph target animation so this month I built a player that allows us to load a range of animations and control how they are played back and tweened. Tweening blends two animations together, this is how you smoothly get from walking to jumping.

Ghost Hack Battle Enhancements

I've also been adding some more advanced features to battle mode character development. Your avatars will grow in skill based on their actions while fighting, but the player will also win "upgrades" which he can use to increase abilities like attack and defence and therefore customize his characters to his own preference.

Another layer of strategy is provided by special attacks which must be charged up before they can be used. Each character has unique special attacks which are very powerful but take a long time to charge. You can only do one at once so you could get all your avatars fully charged before a particularly difficult hack or just get lucky when things look bleak and pull off a signature move to save the day.

Goober - Programming


Previously the room rendering just worked its way through all the objects in the room, found out what model they wanted to use to render (if any) and created an instance of that model for them to use. This is ok for smaller rooms, but once rooms get to any decent size, and contain a large number of blocks, rendering time increases to a point where it's just not going to work out on lower end hardware. This isn't an issue with polygon counts or shader complexity, just a simple fact that we're calling the rendering API's draw function lots of times per frame, which is pretty inefficient. In some cases you just have to do that, and there's nothing you can do about it (like if different models have different shaders or textures), but a lot of the rooms use a small set of models instantiated lots of times, this is where clumping comes in useful. Essentially what you do is instead of creating lots of individual mesh instances, you create one big vertex buffer and pre-instance the model you want into this big vertex buffer. Then when you want to render you just fire the big vertex buffer at the rendering API and it has a decent amount of work to do per draw call, so you amortize the overhead of the draw call itself across a number of models. This is all in now and works automatically, aside from us having to tag which objects are allowed to clump and which aren't, and has worked out to be a good win in terms of rendering time per frame, to the extent that the debug version (at least on our development PCs) runs at intended frame rate again, with some headroom, rather than looking like the main character is moving through treacle. This bodes well for the game running well on lower spec configurations.

Animated Meshes

As you can see in Fost's update, animated meshes are in and working. My part of the work has been done for a while, but it's only when systems start to get used in earnest do you see obvious cases where things can be improved. In this case it was just simply making them easier to use from the game code point of view, and making any loading errors more obvious to the user (so Fost can see what might be wrong when loading a new file).

Particle System

Next up, and taking longer than I had hoped, is a simple particle system for effects and such. I have a basic system working, but it needs more flexibility to be really useful. Hopefully it'll be at a state where it's usable by Fost and Poo Bear, and at that point we'll have more idea of what other features might be required for it to be useful in the final, shippable game.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement