Moba-like Ability/Skill system

I want to create a ability system like any moba (LoL, Dota 2, etc.)

Originally I started thinking about this system a weapon system instead of an ability system. And depending on what weapon the player currently had equipped this is what would drive the attack.

However, after thinking about it for a while I came up with a lot of holes in that approach.

So, I’m trying to figure out what other people are doing.
I thought of using interfaces and a class hierarchy to support this. I also think it would be a good idea to utilize blueprints for some of this as well.

My current code is implementing this via the weapon system approach.
Attempting to think this out I drew the following diagram.

Keep in mind that I’m not asking how I would implement the logic for my concerns (the red notes).
I’m trying to think out how this code would be organized (not the logic, I know how to code logic).

Now that I’m thinking of more of an ability driven system, I’m thinking that I should start from an Ability class and work my way down.

I know that I’ve heard composition over inheritance, but I have trouble designing systems like this on paper.

Also, I’ve thought about possibly making this configuration driven.
However, I would really like to keep this as simple as I can. We get used to doing things so easily and quickly in Unreal. So organizing a system like this is pretty daunting.

Could anyone help me organize my thoughts?
Any code or diagrams are appreciated.

Also, if anyone knows of any tutorials around this I would love to see them. I really couldn’t find much on this topic.

Thank you!

So you are saying I could have both Weapon and Ability classes. Or I could just have weapon classes hmmm…decisions.

Is there any chance you could code a basic skeleton structure for this that would implement one of my example concerns?

Also would you code the general classes in c++ and then create the more specific weapons like shotgun, sniper, etc as blueprints?

I was thinking of decomposing everything down into ability classes. So the base would have everything that all abilities have. Like animation, cooldown, etc.

you can code this stuff in C++ or blueprints, but i would go with blueprints.

blueprint interfaces are a lot easier to work with than c++ interfaces, since they automatically update dependent blueprints with any changes you make to the interface functions. and since this is gameplay code rather than engine code, scripting it in blueprints should work well for iterative prototyping. since these systems will reference a lot of content browser assets, like meshes, textures, and animations, it makes sense to use blueprint to set up those references. Hard coding asset references in C++ is bad practice.

so i would make all of the abilities and weapons as blueprint actors, and have a list of them inside the PlayerController. you could probably use an array of WeaponActor Class_Asset_IDs, so you only have to load the class to get data for menus, and you only have to spawn the weapon from class when its equiped.

I won’t post any code, but i can address each of your concerns with enough information for you to write the code:

teleport = get pawn, set location
Team Heal = store team references, use damage interface
GunSwap = Spawn Actor, Destroy WeaponReference, SetWeaponReference, pass reference to self
projectile = spawn actor, pass in self as instigator reference
Bomb = same as projectile
summon = same as projectile
InstantHit = line trace from socket, use damage interface
melee = collision volume or line traces, use damage interface
AeaOfEffect = same as melee
PassiveAttacks = Timer, same as melee

any attacks should pass an instigator reference which has enough information to determine the player name and team ID, so you can make friendly fire and score logic.

I’ve never used blueprint interfaces but I will give them a read.

If you were to write this would you use create a weapon hierarchy, ability hierarchy, or a combination of both?

I’m trying to get a high level understanding of the design.
What would be the first thing you do?

you can write them all based on the same class if you want, but it really doesn’t matter, that’s just semantics. the way you organize your code should feel comfortable to you.

maybe the base class is an Item, and a sub class is quest item, which you can’t drop, and abilities can be a subclass of quest item that are invisible, and go in an different inventory pocket, and maybe have a different upgrade system tied to a skill tree.

maybe weapons could be a subclass of Item which can be equipped in a weapon slot, and RPG weapons could be a subclass of weapon that has randomized prefixes and suffixes and randomized stat modifiers.

but i don’t know enough about your game’s design to provide a hierarchy of classes. maybe you want to be able to loot items from dead people, or drag physical items around in the world, or collect items that cannot be dropped, or maybe you consider some items stolen or maybe you can only hold a certain weight of armor, but you can stack 99 potions in hammer space…

you will just end up reorganizing all of this as you playtest, so just get started, make it fun, make it balanced, and reorganize as you go.

no problem. i noticed i forgot to answer what i would do first…

the first thing i would do is make the blueprint interface, with functions for Hurt, Heal, KnockBack, Teleport, and Use. then you can make your pawn base class implement that interface, and you can play with making hitscan functionality and spawning projectiles within the pawn class, without even worrying about weapons. you can also make destructible environment props, lava death volumes, and levers your character can interact with, using the same blueprint interface. after you have some fun mechanics working, you can move some of that code into equipable weapons and abilities.

Yeah, semantics was my intention for this thread and is what I always struggle with :confused: Thanks for all your help.

Hmm well the way I was thinking of Weapons originally was pretty much guns. And then I was thinking that magic and things like that would be an Ability. But now I’m not so sure I was thinking about it correctly. For example, a projectile gun and a projectile magic are pretty much exactly the same. So it wouldn’t make since to make one a weapon and the other an ability. Except for the fact that the weapon can be dropped and the ability can’t.

Were you saying to make one single Interface? Would that mean that anything that implements that interface has to implement all of it’s functions? I’m not sure that DamageInterface is really a good name for it since it would handle healing, teleporting, and so many other things besides damage.

i was just trying to give examples of the kind of things you want to handle with an interface, since i have no idea how your game is designed. you could probably handle all of those functions with just Use and Damage. if you use a treasure chest, it opens, if you use a person, they talk to you, if you use a barrel, you pick it up, negative damage is healing, buying something is damaging your wallet and healing your opponents wallet, etc…

I like calling it damage interface because its less boring than all the other generic synonyms for message sending transactions.

the more the environment reacts to the players actions, the more immersive the world is. too many options for interacting with the world is more fun than not enough options, and i doubt the overhead of unused functions is going to ever hurt your framerate:

For sake of this questions the game design I was talking about was moba style; specifically LoL or Dota 2. So each character 4 abilities that are triggered via a different key press. I think the only thing that may be a bit different than that is the fact that you can swap out weapons for a specific ability. For example, you have a shotgun ability and instead pick up a sniper - which changes the ability.