A generic skill system tailored for Godot's design.

[willnationsdev]

Context

Working on an RPG. Characters can use several skills of varying nature. However, many game genres can include highly complex, interlocking skill systems. I would rather develop an open-source subsystem (either a module, GDNative plugin, or Mono plugin) that can deal with this problem, to be maintained by the community.

Problem

Feature requirements include:

• Skills may share characteristics (both stats, i.e. data, and behavior, i.e. logic).
  • Example: Fire wall, Fireball, Fire touch, Fire cone, Iceball, Icewall, etc.
• Some abilities execute immediately (an active skill). Others execute indefinitely, periodically, or when certain conditions are met (a passive skill).
  • Example (active): Fireball: shoots projectile, hits target, deals some damage.
  • Example (passive): Burn: when applied to a target, it deals 0.5% of the target's health as fire damage every second.
• Skills can affect the characteristics of other skills.
  • Example: Keen Mind - boosts intelligence for 1 minute.
    • Skills in the "magic" category now are more potent.
  • Example: Explosive Touch - applies fire damage upon physical contact. The affected target now "Explode"s when hit by another Fire type skill.
    • An active skill applies a passive skill that triggers an additional active skill late.
• Skills should be editable from the Godot scene editor.
  • I should be able to, at a bare minimum, create a scene with a Skill node at its root and fully visualize and configure the skill's characteristics by editing the scene.

Suggestion

Create a data-driven, multi-threaded Server API with nodes and resources that work together to fulfill the requirements.

Solution

I am considering doing all of the following:

1. Split the work of a Skill up into parts.

   • Create a Targeter type responsible for fetching the targets from the world.
     • Targeters have 0+ children.
     • If a Targeter has children, it should automatically incorporate their targets.
   • Create an Effect type responsible for mutating the state of one or more targets.
     • Effects have 0+ children.
     • If an Effect has children, it should automatically incorporate their mutations.
   • Likewise, if a Skill node has children, it should automatically incorporate their executions.

2. Make a Skill's parts be resources instead of nodes.

   • The only node that is necessary for the system to be visualized independently is the Skill node. Targeters and Effects are more of a configuration for how the Skill should behave and do not need a visual editor of their own. Performance could be improved drastically if what previously would be tens of nodes in a hierarchy (so potentially thousands of more nodes in the world than necessary), can now instead be a single node with a few nested resource arrays.

   • If any sort of process or input callback is necessary for an Effect or Targeter, we can pass requisite information to the type's callback manually (delta, input event, etc.). This would be similar to how Unity's MonoBehaviour components receive callbacks from their attached GameObject.

3. Make a Server pattern for multi-threading mutation requests from Skill nodes in phases.

   • The engine already has an established convention for handling scenarios of coordinated operations between several nodes.
     • Many nodes need to render something. Limited resources in rendering. Natural advantages to having a bird's eye view of rendering operations. Have a VisualServer that coordinates requests for rendering submitted by nodes.
     • Many nodes need to play audio. Limited resources in rendering (buses). Natural advantages to having a bird's eye view of audio operations. Have a PhysicsServer that coordinates requests for playing audio submitted by nodes.
     • Same story with Physics (limited CPU time) giving us the PhysicsServer. Nodes submit requests for querying the physical world.
     • Same story with TranslationServer (limited CPU time) giving us the TranslationServer. Nodes submit text to be translated.
     • New scenario: Mutation operations against specific groups of nodes (limited CPU time) giving us a SkillServer. Skill nodes submit skill execution requests accompanied with target acquisition and effect application data.
   • All servers can be accessed directly as low-level APIs, if someone doesn't need the high-level node editing workspace to create a skill.
   • Multithreading is an option with a SkillServer that has an overview of all skills that must be executed within a frame.
     1. Collect a targets from the world (a read-only operation).
     2. Collect all data necessary to mutate properties (a read-only operation).
        • All necessary parameters for Effects would need to be registered ahead of time. Likely as Role/Property pairs. source/power, target/health, etc.
        • property acquisition would very likely need to go through the scripting API most of the time as game data structures are likely to change often. Hardcoding getters associated with specific types or interfaces would make things to inflexible for iteration.
     3. Apply Effects to all targets using the fetched data.
     • While phase 3 needs to be done after the other two, and phase 2 likely needs the objects collected from phase 1, each phase can individually be multithreaded to handle all requests from all Skill nodes in the active scene.

4. Make a SkillUser node. Skills are parented under a SkillUser and may only target other SkillUser nodes. Why? Because SkillUsers have state information necessary to apply or receive a Skill's instructions.

   1. They have Conditions: a list of resources that execute a Skill based on a specified Trigger, e.g. periodically, on insertion, or on removal.
      • This will allow us to design passive abilities that target SkillUsers (as Skills).
   2. They have an output SkillFilter and an input SkillFilter. These are simply stacks of SkillModifiers. SkillModifiers apply a change to a Skill as it is applied or received, respectively.
      • This will allow us to design passive abilities that target Skills (as SkillModifiers).

My biggest concern with this idea is that it would end up being a lot of work for not much gain as you'd still be going through repeated scripting API callbacks to fetch the data from nodes with roles in the Effect mutation parameters. The level of separation there is between the data and the logic could result in a lot of wasted time just trying to lookup data. I do however think that if we can minimize the complexity and flexibly repurpose data and logic for the skills, then we can achieve the goal well.

With that said, I also feel like the current system is likely too complicated for someone to pick up easily, so I'm looking for ways to maintain the power/flexibility it could present while also simplifying it for learning purposes.

I appreciate any feedback, whether its thoughts on ways to improve the design or a suggestion to go with something else entirely.

[Xrayez]

Characters can use several skills of varying nature.

Do you think it makes sense for characters to share skills? Lets say I'm working on a combat turn-based game where different units could reuse skills acquired by individual members of a group/team. Sort of like clan/family skill.

When you describe the skill system, it reminds me of a weapon system which seems to share common logic. The only difference is that skills are more "magical" rather than "physical". See this GodotWeapons plugin for instance. In there different components can affect how a weapon behaves.

In this case, sharing skills would be something like using the same arsenal of weapons between members of a team.

With that said, I also feel like the current system is likely too complicated for someone to pick up easily

The mentioned plugin is already too general purpose for me so I've felt like I could write some more specific system for that, but I guess this is with any software, it just needs better documentation and examples.

[willnationsdev]

Do you think it makes sense for characters to share skills?

Well, if two in-game characters can both simultaneously have the same spell learned / have the same weapon equipped, then characters would be sharing logic for the Skill. That is what I meant.

When you describe the skill system, it reminds me of a weapon system which seems to share common logic. The only difference is that skills are more "magical" rather than "physical".

The only "magic" is in the examples I used, but you could presumably use this same system for a shooter a la Borderlands (was actually one of the use cases I thought of while designing it).

• Guns have a certain way that they shoot (a skill). They have unique ways of firing projectiles (a Targeter) and apply different kinds of mutations to the state of their target (1+ Effects).
• Characters have traits that can influence the way these effects are interpreted (boosts, resistances, extra effects, etc. all done through the SkillModifiers in SkillFilters).
• Characters have the dying state that inhibits their movement and bloodies up the screen.
  • a Condition that with a Skill applying/removing those effects when the Condition is applied/removed.
  • the Condition triggers an additional Skill when circumstances in the environment are detected:
    • Killed an enemy: remove the Condition.
    • Timer runs out: death (yes, this would be implemented as a "Skill". Self Targeter + Die effect).

In this case, sharing skills would be something like using the same arsenal of weapons between members of a team.

Right. But it would also be for even just parts of a Skill (re-using Targeters or Effects to compose new Skills).

The mentioned plugin is already too general purpose for me so I've felt like I could write some more specific system for that, but I guess this is with any software, it just needs better documentation and examples.

Very true. Maybe I'll find ways of simplifying the design as I dig into it further. It'll be a while before I can really devote much time to it anyway.