DaFool wrote:
The reason I insist on dual-wielding (or triple-wielding for that matter) is that it will be easier to make games with battleships, mecha, or fighter planes that have equipment pylons where you can put stat-changing equipment such as more cannons, more fuel (extended range), more armor more powerful engines, etc. You can trade an armor slot for more cannons for maximum damage, for example.
Well, firstly: as the code stands today, there's no reason you couldn't write a skill/set of skills or a damage resolver which counted how many weapons you had, or how many weapons with the same (arbitrary) attributes, and use that to alter the way the attacks worked or the resolution of the damage.
So maybe you have an "Autocannon attack" skill, and each AC on your mecha can shoot three times:
- It would be possible to write a custom Fighter which scanned its equipment and performed the same action four times for a mecha with four ACs, for a total of twelve shots.
- It would be possible to alter the attack resolver to do four-times the damage when you have 4 ACs, or make the to-damage checks four times, or whatever.
- It would be possible to alter the skill to count your ACs and send four times the number of attacks to the attack resolver.
- Each of these can discriminate between ACs on your mecha and lasers via an 'autocannon' attribute that you can selectively apply to just the various different AC weapons when you're setting up the equipment lists in the first place.
All I'm saying is that right now, I'm not going to include any special dual-wielding code in the engine, because it's the kind of thing that
can be done in custom code outside of the engine and is game-specific enough to need to be done in custom code outside of the engine. One game might want two ACs to perform two separate attacks for the same Action-Point cost, another game might want two swords to just multiply the attack score by x1.5, etc..
(And of course, if you want to do it fairly simply without writing any extra code, just have each of your autocannons give a +5 to the attack stat. I've written some utility base classes for "piece of equipment which gives a straight bonus to some stats" and "piece of equipment which applies a multiplier to some stats", so it should be pretty easy to do without writing custom classes.)
DaFool wrote:
Right now I'm assuming that the equipment system is tailored for human units where the items are already segregated and have only one slot allocation for each type.
The demos assume a human unit, and the default limits assume a human unit, just because that's convenient. But there's nothing implicit in the equipment system that means it couldn't be used for something like you describe, and of course it's possible to write an extra Equipment-managing class (descending from the existing FighterEquipment) which provides extra functionality if you want to.
Basically, each piece of equipment has attributes - a list of strings. You can have as many as you like and they can be whatever you like. The FighterEquipment class which is responsible for holding a fighter's equipped items is set up with a set of limits - attribute names mapped to numbers, which are the maximum number of items with that attribute that the fighter can carry.
So the defaults are something like {'weapon': 1, 'armour': 1, 'shield': 1}, meaning that the fighter can only equip one thing with the 'weapon' attribute at any one time, one thing with the 'armour' attribute, and so on. Hands are dealt with in a similar way: there's a HandedFighterEquipment class, which adds on a check for the number of 'hand' attributes an item has. So the default sword has an attribute list of ['weapon', 'hand']; a poleaxe might have ['weapon', 'hand', 'hand'], while Cyclops' laser-eye-thing might just have ['weapon'].
If you want to do a mecha game with slots, you can just adapt this, and give your items attributes that describe how many slots they take up. So a small AC might have ['weapon', 'slot', 'autocannon'] while a large one has ['weapon', 'slot', 'slot', 'autocannon'] and an armour slab has ['armour', 'slot'].
Obviously there's going to be some things which don't fit into this paradigm, and for those things you'll need to subclass the FighterEquipment class and write your own implementation. The first example that comes to mind is something like the Diablo/UFO/Deus Ex inventory, where each piece of equipment takes up a number of squares in a particular pattern and you have to shuffle stuff around in order to fit it on your mecha.
