Jump to content
  • Advertisement
  • entries
    109
  • comments
    175
  • views
    117645

More fun with weapons and armors

Sign in to follow this  
Emmanuel Deloget

237 views

The update is going to be short - I don't have much to say :)

Yesterday I added some basic races to the game system; I decided to give some equipement to these races, so I created a bunch of class to inherit InventoryObjectWeapon and InventoryObjectArmor.

The new weapons are: WeaponDagger, WeaponWoodStaff, WeaponShortSword, WeaponLongSword, WeaponWarAxe, WeaponWarHammer and WeaponSpear.

The new armors are: ArmorHelmet, ArmorTorso, ArmorArm, ArmorLeg and ArmorShield.

As you can see, nothing really - except that I only needed less than one hour to add these. This is not really a great achievement since there isn't a lot of code to write.

More interesting, I also added WeaponEnchanted and ArmorEnchanted.

I was facing a small problem: how to say that a weapon is enchanted? After all, if I add one weapon type to the game, I may have to write the same code to handle the enchanted version of the weapon. The other solution is to add an "enchanted" property to the weapon. But then what if I want to create ethereal weapons? Or fire-based weapons? Adding yet another property to the base weapon class is really not a ggood option.

Fortunately, design patters are going to help again - in particular the decorator design pattern.

WeaponEnchanted is a decorator. It modify the behavior of any other kind of weapon, allowing me to create a new kind of weapon on the fly (the same goes fro the ArmorEnchanted class). If I want to add another property to the weapon, I'll simply add another decorator to the class framework and that's it: instant enchanted ethereal weapon :)

See you later ;)
Sign in to follow this  


3 Comments


Recommended Comments

Having dealt with coding such a system (for Morning's Wrath)

my initial thought is that you are over-subclassing

you pose the question (well what if i wan't this or that?) designing this system so that it can fullfill endless possibilities is a fool's errand, and will result in lots of kludged code down the line.

I can already see you running into what I ran into, such extensions as 'ArmorEnchanted and WeaponEnchanted' this would mean you would need a whole other set of Armor* classes that allowed for enchantment.

one way around this is using Multiple-Inheritence, but that quickly starts binding you down and makes objects which seem similar but are not.

using a decortor is a good idea, but again, only if this logic must be in 'real code'.


What would I do?

specialization should be handled through scripting, stay with some basic types, Armor (if there is a very very large differnce between them, then also go to 'where it is worn')
in code have the variables and functions that apply to all armor.

each 'armor item' should have a script bound to it, which should recive such events as:

taken
dropped
mounted (worn)
dismounted (taken off)
broken (if armor can be destroyed)
repaired (if armor can be repaired)
and others you feel are appropriate (such as 'enchanted')

these script triggers can then be utilized to make each item custom through interaction with the engine and the character associated with them.

this keeps your engine code small, uncomplicated and generalized

and it offloads the game-logic into scripts (where it belongs? =D)

either way, that is what I would do =D
YMMV =D

Share this comment


Link to comment
Quote:

I can already see you running into what I ran into, such extensions as 'ArmorEnchanted and WeaponEnchanted' this would mean you would need a whole other set of Armor* classes that allowed for enchantment.

I'm not quite following this. Decorator classes should inherit from the same parent class as the object they are decorating. So long as you are coding to the interface rather than the implementation this should be essentially seamless integration.

Quote:

What would I do?

specialization should be handled through scripting, stay with some basic types, Armor (if there is a very very large differnce between them, then also go to 'where it is worn')
in code have the variables and functions that apply to all armor.

each 'armor item' should have a script bound to it, which should recive such events as:

taken
dropped
mounted (worn)
dismounted (taken off)
broken (if armor can be destroyed)
repaired (if armor can be repaired)
and others you feel are appropriate (such as 'enchanted')

these script triggers can then be utilized to make each item custom through interaction with the engine and the character associated with them.

this keeps your engine code small, uncomplicated and generalized

and it offloads the game-logic into scripts (where it belongs? =D)

Sounds interesting. I'm not quite seeing how this works (i haven't relied on scripts yet). Could you explain this approach a bit more (or point me to some references)?

Share this comment


Link to comment
The main idea is to offload the game logic into scripts.

by doing this you can have 100 different scripts that define all the different objects and what they due (asuming they are all different in incompatible ways) instead of having to code 100 different classes to handle the specialized functionality.

using scripts instead of classes is good because they can operate within the context of a single instance and they dont require you define an object specialy for them.

for instance, lets say in the game you had 'The Awesome Ring of Levetation, Fire Trails and Accuracy'


instead of having to code three different systems (for levetation, fire trails, and accuracy) you could instead lump this together into a script that reads data from the engine (such as your character's information) and then can modify it through the script.

writing classes is only really effective if you have objects that have a well defined role, and they will be used a lot.

if you have a lot of weird combinations and abilities, it is hard to shoehorn them all into a set of interfaces, and must easier simply to code out the interactions.

so writing a script that can work on somthing as simple as a 'ring class' and give you those complex features is good.

In our game we did this a bit, but we didint have very specialized items, but some were, and this saved us from having to make a lot of specialized classes.

a good example is a ring that adds to your life every 10 seconds.

if you decorate the ring class with such a potential ability, you risk making the code cluttered and having the object 'doing too much'

if you subclass it to do that, then to get two or more features in you would need to do multiple inheritence or a chain of parenting.

with scripting, you can simply keep your ring class, and tell it to use 'ringThatGivesMeLife.script' which has an event which is triggered every second.

there you check if it is worn, and if so check if 10 seconds have gone by, if so, give the wearer some more life.

this makes your system far more 'programmable', wherein coding all of the features is rather 'fixed function' in your abilities of what you can do.


hope that clears some things up.

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!