The Spatials V3 devblog 2015-12-14

Internal development notes, very slightly cleaned up and commented a week later.

TL;DR: first ever combat using the new V3 engine, and a first pass at new state machines required for it, plus the associated data model

A major milestone has been reached in V3 development! Combat is now again part of the game. As a first effort AI-controlled combat has been prototyped, making use of the new tools available in the V3 engine. Here's a video showing a fight between officers and pirates, using a simple test weapon:

Half of the development time was devoted to thinking about what was the best approach for the basic V3 AI combat. In the end it was clear the current V3 engine is easily up to the task of replicating anything V2 had, and going way beyond that. The game went from not having any concept of combat to the state the video shows in 3 days.

Here's the notes that show how my design process goes:

- proto combat
    "what to attack?": model for civ assigning and threat matching
        component per civ for faster world queries
        threat aggro: for now just based on player rep relationships, all enemies live in harmony between each other
    "how to attack?": aggressor comp+sys: entities that seek matching vulnerable entities, tries to apply attacks to them
        requires state machine: aggressor-machine
        sight/detection area (model tied to attack)
        walking into range
        stance: hostile toggling (w/ neutral to come later)
        cooldowns (readyness check on attack model/comps)
    aggro vs defensive behavior vs BusyC
        aggression overrides BusyC: aggressor-machine will ignore previous BusyC and override it with the target entity
            this allows to automatically cancel jobs and other lower prio stuff, which check BusyC mutual ownership
        aggression does not check mutual BusyC ownership since that would preclude multiple entities attacking the same target
        if vulnerability is a separate system/SM...
            ... another "I am currently busy attacking" flag is required, and it must be natural for the ECS system and other systems/SMs
        but how to toggle behavior exclusivity for defense? there is an implicit hierarchy of urgency
            damage reception reaction > flee/heal/port/etc to stay alive > attack (if enabled) > feed/sleep/etc > work
        idea: a priority level for BusyC
            this would be an additional check before overriding BusyC: "impose our own BusyC only if our priority is higher"
            it keeps the systems 100% decoupled: vulnerable-machine does not need to know about aggressor-machine yet it interoperates naturally
            and it still works naturally with the current job system, which can opt-in to priorities later on
        idea: a system id for BusyC indentifying the current controller
            it allows to answer "am I the currently controlling system/SM for this entity?"
            with total independence over the actual BusyC and other state "shape"
        with prio and system id, the urgency hierarchy is solved, including future features like need fulfillement
            plus many lower level arbitration problems
    implement prio + owner hint for BusyC plus various ecs-* helpers
    "how to react to attacks?": vulnerable comp+sys: entities that can be damaged by attacks
        super simple proto for attacks, just model hp as a simple 0-100 autoregen value for now
            attack is simple random substraction
        defensive+damage reception behavior: separate state machine
            simple for now, it just activates a random "flee" walk when low on hp
- "what is an attack?": formalize some model for how to damage a vulnerable entity
    sighting and range
    damage points
    no proc hooks, just pass and hardcode to attack-test

What I do is try to first write down what I want to accomplish, and then at another level of indentation, what is a possible idea or solution to the problem. Then I try to find counterproblems to the ideas, and keep editing the text as I go. If I end up implementing an idea, I update the text to match its final form and move on to the next item. If while implementing I realize the idea is bad, I delete the lines in the to-do file and try to come up with new things, or move to a different goal.

The big blocks of work were the state machines, enhancing the BusyComponent system/protocol, and implementing a "fire and forget"-capable system for what is commonly called "procs" in RPGs.

Two new state machines have been introduced, aggressor-machine and vulnerable-machine. Any entity can make use of them by adding their respective components.

Aggressor state machine

In the future their behavior will be able to be customized by new weapons and enemies, as it now happens with the generic job machine. For now a very simple and much of a work-in-progress model for attacks has been implemented, along with the test beam-like attack shown in the video.

Another important change is introducing priorities and owners into BusyComponent. BusyC is a generic way for systems to declare they are "in control" of an entity, for a loose concept of "control". This has worked very well to coordinate work tasks. But combat (both wanting to attack, or being subject to damage) introduce higher levels of urgency. A work order shouldn't take priority over fleeing from an attacker. While the job system already has an internal priority system, it's not right to use it from a completely unrelated system. Indeed the goal is to make a priority system that has zero knowledge about game systems, but still allows them to cooperate.

This was solved very simply by making BusyC store a priority value, and an owner ID. Systems wanting to interfere with an entity must first the current priority of its BusyC component, and if it's higher that their own, they must leave the entity alone. The owner ID allows for systems to know when a given entity is already busy with them, without having to declare new components just for this purpose (which is still a possibility of course).

- placeholder beam-like attack fx
    spawn entity with custom DS
    helper for reading weapon offset, test it
- introduce scheduler-system
    runs at every frame (not phased!), careful with its usage
        ticks - at which game tick the proc must be called
        proc - a symbol to call with s e and optional data passed to the maker
            use refs for any entity passed, never pass ptr
    entity is destroyed after calling the proc
- proper attack timing
    use two attack states in aggressor sm
        do-attack enables pose, creates scheduled proc with the right animation delay, then goes to wait-attact
        wait-attack for now just waits an arbitrary amount of time (equiv to a single sm iter)
            can't do better since aggressor sm is phase 5, decreasing phase increases CPU for little gain
- port test attack beam to the new proc system

After some testing it was clear that the aggressive phasing the engine uses to lower CPU usage was too coarse to allow for smooth and precise playing of some animations and syncing them with effects. To fix this a new "scheduled proc" has been introduced, for one-shot execution of code at a precise moment. The aggressor machine was fixed to delegate the actual attack effects to scheduled procs, so they can be now frame-perfect.