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

Heavy Metal

Sign in to follow this  
Poo Bear


Goober - Programming
I've been getting vertex animated meshes working. Now, some people might think that vertex animation is a bit of a step back, when you consider that skinned meshes are all the rage with the kids these days, but there are good reasons for doing things this way instead. No, really!

Essentially we needed something built quickly, that was efficient. To support doing skinned meshes we (that is, I) would have to have built an animation system to drive the skeleton, plus tools to export the skeletons, the meshes and the animations from whatever DCC (Digital Content Creation) application Fost wanted to use. This is something we do want to do eventually, but it's overkill for this project when you consider the size of the characters on screen, and how much animation they will require (i.e. not that much really). Using vertex animated meshes, we can just export a bunch of static frames from the DCC app and munge them together to get our vertex animated model. But that's still too much work for me :). So I was playing with an MD3 viewer I wrote one day when I realised the answer was literally staring me in the face (with a railgun in hand at the time too). There are a huge number of MD3 exporters and creation tools available, and loads of them are license free, so we can use them to build our data. The MD3 file format is license free, because it's just a file format. So I've taken that MD3 viewer of mine and munged the code into our engine, and it's working nicely, I think. John Carmack has previously spoken about this very subject, using id file formats in other commercial endevours, and his stance was that it's ok as long as you don't use the id code to generate the data. With the vast quantity of 3rd party tools available, I really don't see that as a problem :)

The other cool thing about doing things this way is that I was able to build and test the system without needing to bother Fost for test data. There are a ludicrous number of Quake3 models kicking around on the net, and that was all the test data anyone should ever need :)

If anyone is interested in writing their own MD3 importer/viewer/tool-chain then I got the file format information from this page. It's all pretty straightforward, even the slightly wacky normal encoding :)

Poo Bear - Programming

All the bots are working for the first zone and the player is moving around well, added items you can pickup like keys and the doors they unlock. So the first zone has really come together and I can move around with all the rooms connected together and see how it all gels.

Adding an onscreen map really helps visualize the "world" and getting that to work was quite fun. In the past I've always had maps either created by an artist or you had to run some slow external process to generate it and there was usually some photoshop touching up required. I never did like that so this time I'm generating it on the fly. This means creating a blank texture in memory, updating it every time you walk into a new room and then uploading it to the graphics card. Sounds simple enough, but getting something like that to work fast when the game has never seen the rooms before is tricky. Think about all the possible room designs someone might make, with stairs and odd shapes, holes, doors and goodness knows what. How can the game work out exactly what the floor is to draw it and still get everything to line up and connect? The answer is to pretend you're the robot and recursively visit everywhere that the robot could if it was walking around and just draw where he walks. Nice and future proof, you always have an up to date map when building levels, it's made automatically and it's guarenteed to scale so when you scroll it around it always lines up properly (unlike the ones an artist makes - tsk!).

Here's one the computer made earlier:
Mr Robot: World Map
Now that things are closer to actually working you start to see the holes in all those lovely levels you made. It sounded good in your head, it made sense on paper and it looked good in the editor. Why then, does it never work when you're playing the game? All of a sudden people are interested now that things are working and it isn't long before there is a long list of bits of the game where people can do something unexpected and then something breaks or they get somewhere they shouldn't. It might only take a day to get something in and working, but it usually takes 5x that long to fix it up and stop people being able to break it.

Mr Robot: Asimov Hitches A Ride
Asimov hitches a ride...

Initially getting Samson to work we had to use stand-in box objects to see if we could make it work. His entire design had to be collision led. He also needed to be able to turn on the spot easily so he would not rotate his collision volume into other objects, and also provide a front 'platform' for carrying Asimov. If you see the collision objects around Samson, you can see how they have influenced Fost's design:

Mr Robot: Samson Collision Objects
Asimov being carried by Samson. everything fits nicely into a box and rotates nicely within the box.

Mr Robot: Asimov gets a lift...
Asimov stands on the platform created by Samson's arms. You can see here how Samson's arms have had to be designed to create the 'shelf' that holds Asimov.

Fost - Art

Mr Robot: Scenery Masking
Started the pretty dull but highly necessary task of masking off areas on all the exising scenery objects. This is one of the final 'cracks' that are stopping the game from looking finished (Even though it isn't finished, we are pretty close to having it look like it is.) If the game was 2D then this wouldn't have been a problem, but with 3D you end up with parts poking out of the back of objects. Since the backdrop will be black, I've added geometry resembling black capes and hoods round the backs of any objects that would show through. It's looking really good so far (I was a bit worried this wouldn't work when objects were next to each other - but so far no problems.

I've also been working on a new robot character. I've really been in hog heaven with this one - he's just a big dumb robot! Something I really wanted to do for a long time is a heavy lifting robot (yes I'm sad). This robot started life as an idea to have other robots as allies to the player that would help him on his journey. The first idea we had was a heavy robot called 'Big AL', that the player could essentially use like a moving platform to reach higher with. In the end we renamed him to SAMS-1 (Samson), because everyone kept calling him 'Big Gay AL' (after the South Park Character) :D.
Currently he weighs in at just over 1500 polygons - which is a bit more than he should have, but I love him so much I don't want to remove anything now! Hey - I'll justify it by saying he's a hero character!

Mr Robot: Big Al Concept Art
Samson concept art
(At this point we didn't have a name for him,
so I called him 'AL-76' after the Isaac Asimov short story :D)

Mr Robot: Samson Game Model Render
Render of final Game model
This actually shows why you should always try and design things
from the viewpoint they'll be seen in the game.
Samson's big grinning mouth isn't that visible in the game right now.
I might try and do something about that before we release though. Samson Wallpaper

Choosing a lighting mode

Here's some tests I've been doing of the most basic shader setup for lighting. Basic vertex lighting is multiplied (modulated) by the object's texture map, the trouble with this, is the brightest a model can ever get, is the colour of it's texture, and only then on a side directly facing and close to a light. An easy way round this is to use Modulate2X or Modulate 4X in the shader. This means the light can overbright the texture, and helps stop the whole scene being slightly dull. It does mean however, that you have to mess with the lights a little to stop everything looking like a nuke has just gone off. So I wanted to do some tests first to make sure we were using the right shader mode (changing this later would basically mean redoing each room's lighting :cry:)

In the end I decided Modulate 2X gives enough of a brightness range to work with. Modulate 4X adds a little bit more, but it is much harder to set up more subtle colour variations (It is technically not an issue, but it's much harder to 'think' in 4X - especially when you have lots of lights playing off each other - for me at least anyway!)
Mr Robot: Vertex lighting (Modulate)
Modulate lighting

Mr Robot: Vertex Lighting (Modulate2x)
Modulate 2X lighting

Mr Robot: Vertex Lighting (Modulate2x)
Modulate 4X lighting
Sign in to follow this  


Recommended Comments

I'm unsure whether or not I've posted on your journal before, but let me tell you that this game is looking absolutely awsome. Keep up the excellent work.

Share this comment

Link to comment

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

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!