Viability of using actors for stats/abilities/items/etc?

Development Programming & Scripting Blueprint
1

Hi all,

I’m currently working on putting together a small action RPG prototype just for fun. I’ve been trying to think of different ways to handle stats, I want to provide flexibility for quick iteration later on so I want to avoid hard coding as much as possible.

Some context, my current implementation has a CharacterSystem actor component that can be added to my BaseCharacter that will handle things such as receiving damage, dying, etc. Each stat (health, mana, etc) is a child of my BaseStat which implements various functionality such as arrays of modifiers, name, etc. This seemed like the best approach for making my available stats very scalable. My initial idea was to make my BaseStat a scene component and have the CharacterSystem read from a list of available stats and then register each stat to the parent actor at runtime. However, I can’t seem to find a way of doing this as it looks like components can’t be registered at runtime. Which leads me to my question…

Is it an issue to use an actor for each of my stats? Realistically any one character (players and NPCs) may have a dozen stats or so. That means I’d be spawning dozens of individual actor instances per one character I spawn. Going forward it’s likely I would use a similar approach for an inventory, having each item as an actor attached to the inventory parent. Would this be a problem?

There’s some part of me that feels wrong about spawning so many actors but I’ve been looking into the overhead of non-rendering, attached child actors and it doesn’t actually seem all that bad. I could use structs but each of my stats but breaking and remaking structs whenever a value is updated seems like a pain and if the overhead of using actors isn’t that great then the more accessible development approach seems worthwhile. It also means I can hook events into various value changes which I’d lose with structs.

Thanks in advance,

:slight_smile:

EDIT: To add some extra context to the scenario. I’m hoping the eventually this project will evolve into something similar to Diablo or Torchlight. Say 1 to possibly 8 player coop, with tens of AI in any one area at a time. All levels and world data would be volatile and only character data would need to be persistent.

2

Watching this one…

4

Going to bump this as it seems I’m not the only one this information would be helpful to.

On a related note however, I’ve been going ahead with my implementation and I’ve not yet noticed any issues. It seems like non rendering actors are pretty light weight, I tried spawning in a few hundred actors and there wasn’t any noticeable problems. It does seem like if you disable ticks (I’m calling functions on the children using the parents tick) and have no model specified an actor attached to a parent really isn’t all that much to worry about.

It would still be much appreciated if anyone has any insight into problems I may encounter down the line as even with spawning many actors they’re all currently still fairly simple just storing values and having functions called on them every few ticks. If anything I’m expecting an actor based inventory to be the thing that causes issues, I shall let people know when I get to that…

5

i use actors as base for spells, my test show its reasonably ok to have 1k replicated actors, so if your active spellbook is not THAT big, its fine to have all logic wrapped out as actor class, feels kinda bad, but it seams to be easiest way, you dont looking for BEST stats with blueprint anyway.

about inventory, if your items passive(dont have any active mechanics) they don’t need any respresentation, it might be just an array of enum.

6

Awesome thanks for the response.

The inventory stuff I was thinking I could probably get away with using structs for actually. It would just need to store the stats of the weapon/armour/etc and then the class to spawn when it’s equipped/dropped.