Hello, I'm having trouble implementing melee weapons in an entity component system and I was hoping you could help me.

Firstly, I made an inventory component to hold all my different weapon entities. Each weapon entity contains a WeaponComponent that holds its firerate, clipsize, accuracy, etc.. A shooting system then creates a projectile based on the properties of the weapon component. This worked pretty well, as I was able to add lots of different kinds of firearms easily. When I tried to implement a melee weapon though i was stumped. Could you please point me in the right direction here guys :/

Maybe this'll help:

-InventoryComponent

++weaponVector <Entity>

++addWeapon(weapon:Entity)

++getWeaponComponent()

++updateCooldowns()

++isReloaded

-WeaponComponent

++ClipSize

++ReloadSpeed

++NumBullets

++fireRate

++etc...

ShootingSystem()

update()

if is shooting and inventory.isReloaded

then createBullet(inventory.getWeapon)

resetcooldown

Well you have two main choices, I think: either you combine the concept of melee and range weapons, or you make them completely separate.

List out the properties of a melee weapon and see if it makes sense to combine with range weapons into one WeaponComponent. If so, then have your ShootingSystem handle melee weapons too (but rename it). Or you could separate the logic into two systems.

Having separate systems would also be natural if you end up having completely separate components (MeleeWeaponComponent and RangeWeaponComponent).

On the other hand, if there are things like restrictions on simultaneous use of weapons (you can use a melee or a range weapon, but not both at the same time), or if it depends how many hands your character has free or something, then having a single system managing all the logic might make more sense. Can you have a weapon that is both melee and ranged?

Basically, it really depends on the constraints you have regarding the types of weapons in your game. There's no right answer, it's whatever makes sense and is most natural in your scenario.

NB: It seems a bit weird to have things like isReloaded and updateCooldowns on InventoryComponent, but I guess if your inventory is exclusively weapons then it makes sense. I tend to put anything other than absolute basic logic into a system though.

The weapons are generally not that complex and the player can only use one weapon at a time (It's a sidescroller shooter). i guess I should broaden the shooting system to include melee weapons.

I also avoid putting any logic in components as well. The functions in the inventory are mostly simple functions that loops through the weapons changing certain values or logical expressions. And thanks for the quick response

Hello.

The mellee weapon could still fire projectiles that you dont see and have short range then the animation does the rest.

There the same thing.

Set the speed of the projectile to the swing of a sword time it hits centre say.

A full fledged solution to this problem would be to redefine what a weapon is. Looking at a firearm, it's a flying bullet that causes harm. In general, for ranged weapons it's the projectile. And for melee weapons it's a cutting edge or a tip. Hence weapons cause harm only in specific situations, e.g. the bullet must fly, the sword need to swing, etc.

With a DamageSystem in existence, let the entity register a DamageCause component with it. A DamageCause holds a simple geometry, either explicit or implicit, e.g. a straight line in the case of a firearm and a line following the cutting edge in the case of a sword. This simple geometry is given with the weapon's local co-ordinate system as reference, so its "follows" the weapon. A DamageCause has further a damage value, perhaps a damage type (if you want to consider specialized armor), but especially an enabling flag. The DamageSystem will check for collisions only if the enabling flag is set to true.

The mechanisms that set said enabling differs by weapon type. A bullet is usually not visualized / animated because of its high speed. So the player / AI controller is probably the part that enables the DamageCause due to an action command. A sword is harmful only when used as a weapon. Hence the animations showing a sword swing or jab enable the DamageCause (an animation need not be restricted to playing a sequence of pictures; any value can be animated if a belonging animation track exists and the variable of interest is bound to it).

Notice that there is no hindering in adding another DamageCause to a rifle with a geometry along the stock, and enabling this DamageCause by an animation that shows some battering (not sure whether this is the correct word for what I mean) using the rifle. A sword may also have different DamageCause components for different kinds of attacks.

What is left now is a mechanism that handles the load state and so on of firearms. This can be solved to add a second component, e.g. a ChargeComponent (perhaps in derived forms), to model the specific features. It provides specific controls to the player (e.g. reloading), but also need to be considered by the player / AI controller (because of some state dependency).

An entity becomes, well, let's say "a weapon" now by adding a DamageCause. Notice that in principle a vase may become a weapon when used as a missile. The entity may have a dependency on projectiles, and it causes damage only if used as a weapon.