Fost - Art
Move Your BodyGoober 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
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)
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.
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!
Orgus Final Game Model
Water Vertex ShadersNot 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.
Poo Bear - Programming
Battle ControlBattle 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 WorkflowIf 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 scriptingThis 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 AnimationThe 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 EnhancementsI'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