Weapon system solutions
by Daniel Buckmaster · in Torque Game Engine · 02/23/2008 (1:11 pm) · 7 replies
My question is aimed mainly at people developing FPS games with Torque. The question is - how do you implement weapons?
The default system uses ShapeBaseImages for rendering weapons attached to players and Items for representing the loose weapons in the world. That's nice, but there's two flaws with this:
1. ShapeBaseImages aren't real objects - so they can't store their own dynamic fields and similar.
2. Items have crappy physics.
The obvious solution to 2 is to use RigidShapes in the world. However, the solution to 1 is trickier. My idea is to 'wrap' RigidShape and ShapeBaseImage with a GameBase-derived class that manages them. It's this object, with no shape or other presence, that stores any members for the weapon (as well as some other cool ideas I have). Its datablock stores a few pointers to RigidShapeData and ShapeBaseImageData. The objects themselves can be in one of two states - parented to a ShapeBase (as a mounted image) or free in the world (as a RigidShape). Functions like getTransform called on this helper object (bureaucrat) will redirect to RigidShape::getTransform or ShapeBase::getImageTransform depending on what the object is doing.
So, that's the idea. Good or bad? I think there's both. It requires an additional object for every weapon - bureaucracy, like I said. However, it allows persistent storage of members for weapons - so weapons could be damaged in real-time, for example. In addition, there doesn't need to be any physical presence for the weapon to exist - so, if you want the weapon to be 'stowed' in an inventory, you simply destroy the RigidShape and dismount the image, but you still have the bureaucrat keeping track of the essential data.
The default system uses ShapeBaseImages for rendering weapons attached to players and Items for representing the loose weapons in the world. That's nice, but there's two flaws with this:
1. ShapeBaseImages aren't real objects - so they can't store their own dynamic fields and similar.
2. Items have crappy physics.
The obvious solution to 2 is to use RigidShapes in the world. However, the solution to 1 is trickier. My idea is to 'wrap' RigidShape and ShapeBaseImage with a GameBase-derived class that manages them. It's this object, with no shape or other presence, that stores any members for the weapon (as well as some other cool ideas I have). Its datablock stores a few pointers to RigidShapeData and ShapeBaseImageData. The objects themselves can be in one of two states - parented to a ShapeBase (as a mounted image) or free in the world (as a RigidShape). Functions like getTransform called on this helper object (bureaucrat) will redirect to RigidShape::getTransform or ShapeBase::getImageTransform depending on what the object is doing.
So, that's the idea. Good or bad? I think there's both. It requires an additional object for every weapon - bureaucracy, like I said. However, it allows persistent storage of members for weapons - so weapons could be damaged in real-time, for example. In addition, there doesn't need to be any physical presence for the weapon to exist - so, if you want the weapon to be 'stowed' in an inventory, you simply destroy the RigidShape and dismount the image, but you still have the bureaucrat keeping track of the essential data.
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
When the item is dropped, the object that gets created in-world automatically gets tagged with script variables that hold this data, so each dropped item has variables like itemCondition, loadedAmmo, and so on, which can be read back into the inventory when the player picks them up.
This solves the problem without the need to rewrite the ShapeBaseImage, which strikes me as a lot of work for minimal payoff. In addition, because I've written the inventory system into code, I can easily sync this data to the client when needed for low overhead GUI access to the inventory list. If this doesn't concern you, you can just as easily update the script inventory to store this info for each item.
Remember that the Image system was never intended to be a real-world object; it's just an effect that gets attached when a weapon is equipped. It's up to you to set up an inventory back end that handles stuff like damaged items, carry limits, and determining which items can be equipped.
As you said, issue #1 is much easier to solve, and simply requires that the in-world dropped items use Rigid or another physics setup (PhysX, for example). I would recommend having two types of items in your game; Item, the existing item class, which could be used for static items placed in the level (using Rigid for all of these will probably be a performance hit), and RigidItem, which is basically the Item class with RigidShape as the parent.
It's definitely worth mentioning that this system won't work if your item gets transferred from a Player to, say, a Vehicle, unless Vehicle objects also possess an inventory system (they honestly probably should if you expect to be able to equip an item from the Player's inventory on a Vehicle).
*edit: Also, I agree with Ramen-sama that having the RigidShape exist while the item is being held makes no sense. There's no reason the weapon needs physics unless it's been dropped into the world.
02/23/2008 (2:03 pm)
I was concerned with the same issue some time back, and so I implemented a completely new inventory system that can keep track of the data I need every item to carry. Instead of the default script inventory, which simply keeps a count of how many of each item the player has, I used a list of items like many RPG's. Each item is stored in this list, equipped or not, and the list also holds data about each item (condition, ammo, what clip is loaded, etc). When the item is dropped, the object that gets created in-world automatically gets tagged with script variables that hold this data, so each dropped item has variables like itemCondition, loadedAmmo, and so on, which can be read back into the inventory when the player picks them up.
This solves the problem without the need to rewrite the ShapeBaseImage, which strikes me as a lot of work for minimal payoff. In addition, because I've written the inventory system into code, I can easily sync this data to the client when needed for low overhead GUI access to the inventory list. If this doesn't concern you, you can just as easily update the script inventory to store this info for each item.
Remember that the Image system was never intended to be a real-world object; it's just an effect that gets attached when a weapon is equipped. It's up to you to set up an inventory back end that handles stuff like damaged items, carry limits, and determining which items can be equipped.
As you said, issue #1 is much easier to solve, and simply requires that the in-world dropped items use Rigid or another physics setup (PhysX, for example). I would recommend having two types of items in your game; Item, the existing item class, which could be used for static items placed in the level (using Rigid for all of these will probably be a performance hit), and RigidItem, which is basically the Item class with RigidShape as the parent.
It's definitely worth mentioning that this system won't work if your item gets transferred from a Player to, say, a Vehicle, unless Vehicle objects also possess an inventory system (they honestly probably should if you expect to be able to equip an item from the Player's inventory on a Vehicle).
*edit: Also, I agree with Ramen-sama that having the RigidShape exist while the item is being held makes no sense. There's no reason the weapon needs physics unless it's been dropped into the world.
#3
The other part of the reason was a cool thing I had coded for my previous weapon class, that was basically a RigidShape that you mounted to things. I had a whole system of timed script callbacks, all contolled from datablock values. With that system, basically, you could do everything from overheating to burst fire. It looked more lightweight than SBI's state system, but I don't actually know if this is the case. Certainly far less members.
02/23/2008 (10:30 pm)
Quote:What the heck are you needing all this for? Why would you care if your weapons had physics going on them?
Quote:Also, I agree with Ramen-sama that having the RigidShape exist while the item is being held makes no sense. There's no reason the weapon needs physics unless it's been dropped into the world.The RigidShape doesn't exist when the weapon's mounted. When you stick the weapon onto a ShapeBase (it has been picked up), the Rigid is destroyed, and an image may be mounted. Then when the ShapeBase drops the weapon, a Rigid is created and the image is unmounted.
Quote:Remember that the Image system was never intended to be a real-world object; it's just an effect that gets attached when a weapon is equipped. It's up to you to set up an inventory back end that handles stuff like damaged items, carry limits, and determining which items can be equipped.Most of the reason I wanted this system is so that an inventory system remains just that - an inventory. The objects themselves retain their own fields relating to condition and ammo, rather than the player having to do that. That just makes more sense to me. I guess Torque doesn't allow that sort of setup, though.
The other part of the reason was a cool thing I had coded for my previous weapon class, that was basically a RigidShape that you mounted to things. I had a whole system of timed script callbacks, all contolled from datablock values. With that system, basically, you could do everything from overheating to burst fire. It looked more lightweight than SBI's state system, but I don't actually know if this is the case. Certainly far less members.
Quote:I would recommend having two types of items in your game; Item, the existing item class, which could be used for static items placed in the level (using Rigid for all of these will probably be a performance hit), and RigidItem, which is basically the Item class with RigidShape as the parent.RigidItem is a good idea. I want to look into RigidShape performance hits - apparently, when it's still, it doesn't do any of the complicated calculation stuff, so the hit is reduced when you just have a large number of them sitting around.
#4
02/23/2008 (10:41 pm)
@henry - For my RPG items, i do something similiar, i keep track of all items as ScriptObjects. It's easy as heck to tag them with whatever information i need.
#5
02/23/2008 (11:39 pm)
A ScriptObject for each item? Or using a ScriptObject based inventory system? Basically what I'm advocating is having an invisible helper for each weapon - whether the weapon is currently displayed as a mounted image or a loose rigid shape. This helper object keeps track of all the weapon's persistent data (and my custom callback system).
#6
Every character also has a scriptObject representing them for when they are not presently on screen.
02/23/2008 (11:41 pm)
Every item is a script object is how i do it.Every character also has a scriptObject representing them for when they are not presently on screen.
#7
02/24/2008 (5:58 am)
That sort of sounds like exactly what I was suggesting :P. Except using a GameBase derivative instead of ScriptObject, so the helper can process ticks, use datablocks, etc. 
Torque Owner Cinder Games