Weapons that don't exist (ShapeBaseImage adv/disadv)
by Daniel Buckmaster · in Game Design and Creative Issues · 07/06/2009 (4:33 am) · 3 replies
I'm making an FPS, but in some aspects I want it to be closer to an RPG - mostly in terms of having an inventory and being able to pick up lots of world items. Think Deus Ex, but without the skill progression. This means all sorts of object types, but weapons in particular.
With this in mind, what would you say if I said I wanted to throw away the ShapeBaseImage system and mount my weapons as objects? What are the particular advantages of using images versus objects?
This is how I see it right now.
Image pros
-They're apparently lighter-weight (in rendering terms?) than objects. Why?
-Don't take up as much network capacity as a free object
-Images aren't real objects with an ID and everything
Image cons
-All dealings with images must be through their 'owner' object
-Images take up Player network bits, especially if I want to use them for equipment as well (which I do)
-Images aren't real objects with an ID and everything
Not considering
-Collision: I've got some ideas to add collision to images - I'm already adding hitboxes to ShapeBase, so it'll be a simple job to make images use their own hitboxes
-State system: I'm confident I'm proficient enough with Torque to add the state system to a class like Item to use with my weapons
I know the number of objects in the world will be rapidly increased if I go this route, but I think that what I gain in terms of an elegant and easy-to-work-with system for weapons and items outweighs this. I invite anyone to tell me otherwise ;)
(I suspect I may have posted a similar question to this a while ago... I consider myself more knowledgable than then and better prepared to discuss the question.)
With this in mind, what would you say if I said I wanted to throw away the ShapeBaseImage system and mount my weapons as objects? What are the particular advantages of using images versus objects?
This is how I see it right now.
Image pros
-They're apparently lighter-weight (in rendering terms?) than objects. Why?
-Don't take up as much network capacity as a free object
-Images aren't real objects with an ID and everything
Image cons
-All dealings with images must be through their 'owner' object
-Images take up Player network bits, especially if I want to use them for equipment as well (which I do)
-Images aren't real objects with an ID and everything
Not considering
-Collision: I've got some ideas to add collision to images - I'm already adding hitboxes to ShapeBase, so it'll be a simple job to make images use their own hitboxes
-State system: I'm confident I'm proficient enough with Torque to add the state system to a class like Item to use with my weapons
I know the number of objects in the world will be rapidly increased if I go this route, but I think that what I gain in terms of an elegant and easy-to-work-with system for weapons and items outweighs this. I invite anyone to tell me otherwise ;)
(I suspect I may have posted a similar question to this a while ago... I consider myself more knowledgable than then and better prepared to discuss the question.)
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
1. To me, it's a far more intuitive and easy system to work with objects. Just in terms of writing scripts, and for modders who write scripts, this way of doing it seems far less confusing. It simplifies tasks like inventory management and persistent item properties like attached objects (scopes, bayonets), and condition.
2. As I mentioned, it's easier and cleaner to keep track of persistent properties of items. For example, if I'm holding a plasma gun and fire it until it critical overheats, then I drop it... the Item class doesn't have a 'critical overheat' state like images do. I would have to implement all the stuff in the image class into any Item class I used. It's easier if everything is in one class, and one object.
They're my non-technical reasons for this... as far as I'm aware, the technical side of the argument mainly favours images as opposed to objects. My non-technical side favours objects :P.
I'm not worried about the coding work I'd have to do to implement any amount of functionality to a new class... I've already done that with players, and I'm kind of looking forward to something relatively simple like weapons :P.
07/06/2009 (8:19 pm)
Okay, I didn't really do a good job of explaining why I want to deal with mounting objects rather than images.1. To me, it's a far more intuitive and easy system to work with objects. Just in terms of writing scripts, and for modders who write scripts, this way of doing it seems far less confusing. It simplifies tasks like inventory management and persistent item properties like attached objects (scopes, bayonets), and condition.
2. As I mentioned, it's easier and cleaner to keep track of persistent properties of items. For example, if I'm holding a plasma gun and fire it until it critical overheats, then I drop it... the Item class doesn't have a 'critical overheat' state like images do. I would have to implement all the stuff in the image class into any Item class I used. It's easier if everything is in one class, and one object.
They're my non-technical reasons for this... as far as I'm aware, the technical side of the argument mainly favours images as opposed to objects. My non-technical side favours objects :P.
I'm not worried about the coding work I'd have to do to implement any amount of functionality to a new class... I've already done that with players, and I'm kind of looking forward to something relatively simple like weapons :P.
#3
If you have the skills to pull it off, I say do it (if it was me I would keep the changes to the engine to a minimum, and keep my main focus on doing what the engine does already, but that is mainly because I normaly don't have the know how to do major changes... if you do have that know how, there is alot that you can do to make stuff more custom to your game by changing the engine. So if you can do it, do it :)
Just keep in mind that you are making a new system, so you better off planing it from de ground up (and probably custom made to what you plan to have on your game).
So, besides the extra time and effort that you'll put in to it, I don't think I have another good excuse not to do it. If that's not an issue... then do it.
07/07/2009 (3:21 am)
I kind of agree with your point 1 (although you can get used to do things with images after a while), and for what I'm getting from your posts, you realy want to do that weapon class object.If you have the skills to pull it off, I say do it (if it was me I would keep the changes to the engine to a minimum, and keep my main focus on doing what the engine does already, but that is mainly because I normaly don't have the know how to do major changes... if you do have that know how, there is alot that you can do to make stuff more custom to your game by changing the engine. So if you can do it, do it :)
Just keep in mind that you are making a new system, so you better off planing it from de ground up (and probably custom made to what you plan to have on your game).
So, besides the extra time and effort that you'll put in to it, I don't think I have another good excuse not to do it. If that's not an issue... then do it.
Torque Owner ZeMag
I probably can't be of mutch help, but I nothice you missed a big pro: images are already there (ok, you may have to do alot of work to add whatever you want, but the basics are there, right).
Can't help you with the technical advantages or disadvantages discussion, but my gess is images are optimized to work as weapons, while normal shapes aren't, witch will slow down the game a bit, and force you to basicaly build your own weapon/item system. But if you want something that images can't provide, then maybe you're better off starting a new type of object from basic shapes (then again, don't do mutch source engine coding, so am not the right guy to advise you with that).