Major transplant
by Daniel Buckmaster · 12/23/2009 (9:09 pm) · 5 comments
WarEngine feature: weapon objects replace mounted images. That necessitated transplanting some nice features from ShapeBaseImage into Item. In the meantime, RigidShape gets an upgrade and I get back into Blender.
I've never understood the logic of using ShapeBaseImages instead of actual mounted objects. Especially when, in an FPS context, weapons need to exist as separate objects in their own right, not just when mounted to a character. Hence my attempts to create a unified 'Pickup' class, first by inheriting from RigidShape, then by creating a 'wrapper' for a ShapeBaseImage datablock and an Item or RigidShape object. I've finally reverted to my first idea, but with a lot more know-how on my side.
The new Item class – I've just decided to use Item instead of creating a new class, since Items in their current form won't be useful for me – is inherited from RigidShape, so it has nice physics. In the process of working a little more with the RigidShape class, I've come up with a few modifications to it that should be useful for everyone (look for a resource soon!). The most important:
As I mentioned, I've transplanted the state machine from ShapeBaseImage to Item. The process was more tedious than difficult, but now I'm going to have to do some thorough testing to make sure the new system is stable (I'm still not sure I thoroughly understand how state updates should be networked). However, I'm very much enjoying the benefits of having an object-based system, rather than images being totally reliant on the ShapeBase they are mounted to. The biggest advantage is persistence: if I have a weapon with a state machine, and I drop it, the state machine remains unchanged. A good example of where this might be useful is weapons that overheat – dropped overheating weapons will carry on merrily melting down, using all the sound and particle effects they would use when held by a character. And on a smaller scale, weapon objects themselves can now store things like shot counters for burst fire – instead of having to rig up a huge, inefficient state machine with multiple fire and reload states for burst sequences, I can use a member of the weapon to count shots. And with the addition of one more state, I have an alternate-fire setting for single shots.
Anyway, I'll stop bragging about my weapon-making prowess and address the question: what happens to ShapeBaseImages now? I'm really not sure. I'm certainly going to be gutting them down quite a bit – they won't do much more than render a shape (with optional animations, maybe) and allow you to mount objects on their nodes. Useful for small detail objects that you want to swap around – maybe different helmets on a soldier, for example. (Though I want to manage armour through an inventory system same as weapons, so they'll end up being Items as well... :P)
I guess youse'll want some screen-shots... happy to oblige.

The lovely Bolter I created to test the new Item class. See here for more shots and WIP stuff.

The Bolter starring in-game, replete with dodgy physics (this is its rest position after being dropped from the sky).

Exciting! The Bolter's state system works! Now to make the states actually do something...
EDIT: I forgot to explain myself!
Just why am I jumping around so much? My next blog was going to be about the finished Actor class, and announcing it as a resource. Well, frankly, my coding right now is being dictated by our team's new short-term goal of releasing a small demo before March. That requires a few basic systems to be implemented - not necessarily with any depth, just enough that we can get a test character running around an environment and shooting things.
So with the Actor class suitably finished (nowhere near as finished as I want - but basic stuff is there), I've moved on to the Item class so we can put some weapons in the level. I'll be leaping around a little more before March, probably to do some artwork - then I'll try to return to some semblance of a logical schedule :P.
EDIT: Forgot another advantage of the object-weapon system: once I've gotten rid of the stupendous amount of ShapeBaseImage-related stuff in ShapeBase, the class will be less bloated. Woot. Always a good thing.
I've never understood the logic of using ShapeBaseImages instead of actual mounted objects. Especially when, in an FPS context, weapons need to exist as separate objects in their own right, not just when mounted to a character. Hence my attempts to create a unified 'Pickup' class, first by inheriting from RigidShape, then by creating a 'wrapper' for a ShapeBaseImage datablock and an Item or RigidShape object. I've finally reverted to my first idea, but with a lot more know-how on my side.
The new Item class – I've just decided to use Item instead of creating a new class, since Items in their current form won't be useful for me – is inherited from RigidShape, so it has nice physics. In the process of working a little more with the RigidShape class, I've come up with a few modifications to it that should be useful for everyone (look for a resource soon!). The most important:
- Fixed some warp-jittering by networking a full position, not a compressed one
- RigidShapes can now be mounted to other objects and don't collide with them
- Removed more unnecessary fields left over from HoverVehicle
- There's now a RigidShapeObjectType!
- Planned: adding camera shake when a RigidShape impacts
- Planned: fixing collision resolution so RigidShapes can knock each other (and Players) around
As I mentioned, I've transplanted the state machine from ShapeBaseImage to Item. The process was more tedious than difficult, but now I'm going to have to do some thorough testing to make sure the new system is stable (I'm still not sure I thoroughly understand how state updates should be networked). However, I'm very much enjoying the benefits of having an object-based system, rather than images being totally reliant on the ShapeBase they are mounted to. The biggest advantage is persistence: if I have a weapon with a state machine, and I drop it, the state machine remains unchanged. A good example of where this might be useful is weapons that overheat – dropped overheating weapons will carry on merrily melting down, using all the sound and particle effects they would use when held by a character. And on a smaller scale, weapon objects themselves can now store things like shot counters for burst fire – instead of having to rig up a huge, inefficient state machine with multiple fire and reload states for burst sequences, I can use a member of the weapon to count shots. And with the addition of one more state, I have an alternate-fire setting for single shots.
Anyway, I'll stop bragging about my weapon-making prowess and address the question: what happens to ShapeBaseImages now? I'm really not sure. I'm certainly going to be gutting them down quite a bit – they won't do much more than render a shape (with optional animations, maybe) and allow you to mount objects on their nodes. Useful for small detail objects that you want to swap around – maybe different helmets on a soldier, for example. (Though I want to manage armour through an inventory system same as weapons, so they'll end up being Items as well... :P)
I guess youse'll want some screen-shots... happy to oblige.

The lovely Bolter I created to test the new Item class. See here for more shots and WIP stuff.

The Bolter starring in-game, replete with dodgy physics (this is its rest position after being dropped from the sky).

Exciting! The Bolter's state system works! Now to make the states actually do something...
EDIT: I forgot to explain myself!
Just why am I jumping around so much? My next blog was going to be about the finished Actor class, and announcing it as a resource. Well, frankly, my coding right now is being dictated by our team's new short-term goal of releasing a small demo before March. That requires a few basic systems to be implemented - not necessarily with any depth, just enough that we can get a test character running around an environment and shooting things.
So with the Actor class suitably finished (nowhere near as finished as I want - but basic stuff is there), I've moved on to the Item class so we can put some weapons in the level. I'll be leaping around a little more before March, probably to do some artwork - then I'll try to return to some semblance of a logical schedule :P.
EDIT: Forgot another advantage of the object-weapon system: once I've gotten rid of the stupendous amount of ShapeBaseImage-related stuff in ShapeBase, the class will be less bloated. Woot. Always a good thing.
About the author
#2
12/24/2009 (9:17 am)
Good stuff, mate.
#3
12/29/2009 (3:26 pm)
Nice work, Daniel. I'm very interested to read more and see a resource at some point. =)
#4
01/20/2010 (3:08 am)
Man you're developing tons of exciting stuff! I hope to get my hands on all this soon! :) You will bring it out as resource right? Or at least as purchaseable package?
#5
If that makes sense ;P.
Also, I feel like the more resources, the stronger Torque as an engine, and that's always a nice thing.
Oh, and I managed to improve RigidShape's performance a little, so that'll be in there.
01/20/2010 (12:30 pm)
Certainly a resource. My policy with paid packs is that I don't want to sell anything I'll be using in my game. I'm in this as a hobby, and I will make the game I want to make. I see no harm in then releasing bits of my game that others can use. If I did make something that I won't be using in my game (like the art pack I mentioned a while ago), then I would charge for it, because it represents effort I'm expending not towards the goal of my game as a hobby.If that makes sense ;P.
Also, I feel like the more resources, the stronger Torque as an engine, and that's always a nice thing.
Oh, and I managed to improve RigidShape's performance a little, so that'll be in there.
Torque Owner Tuomas Kaukoranta
Oh and BTW, you're not the only one to create a Bolter for no particular reason.
EDIT: PS. Merry Christmas!