After implementing the animation state machine and per-state behaviour scripts, the next step is defining a clear workflow for building enemies on top of this system. This post explains the intended pattern for implementing enemy behaviour so that all gameplay code follows the same structure. Overview Enemy behaviour is built using three main pieces: StateMachineScript (per state) EnemyController (shared logic) Animation State Machine (transitions & flow) Each one has a clear

After exposing the animation system to gameplay through AnimationAPI, the next step in my engine was introducing a way to attach behaviour directly to animation states. At that point, gameplay scripts could already trigger transitions, query the active state and control playback. However, all behaviour still had to be written in external scripts, usually centralized in a single controller. That quickly became hard to scale, especially when dealing with multiple states and tra

After building the visual state machine editor, the next step in my engine was exposing that runtime animation system to gameplay scripts. At that point, the engine could already load animation state machines, evaluate transitions, react to triggers, and blend correctly at runtime. That made the system usable from the animation side, but gameplay code still had no clean way to interact with it. Scripts needed a proper runtime API layer so they could trigger transitions, query

After getting the animation state machine working at runtime, the next step in my engine was improving the editor workflow around it. At that point, the engine could already load an animation state machine resource, start from a default state, react to triggers, and blend transitions at runtime. That was enough to validate the system technically, but editing the resource through inspector fields alone was still too limited and not very comfortable once the number of states an

After building animation playback and skinning, the next step in my engine was moving from “playing a single clip” to actually controlling animation flow through a state machine. In the previous stages, the engine could already import animation clips from glTF, reproduce them at runtime, and deform the character correctly through skinning. That was enough for isolated playback, but not for real gameplay logic. Characters do not just play one animation forever: they need to sw

After completing basic runtime playback for glTF animations, the next milestone in my engine was skinning. In the previous phase, I could already import animation clips, play them back at runtime, and apply them correctly to the node hierarchy. The skeleton moved as expected, but the mesh itself still stayed frozen in its bind pose. This task was about solving that missing step: deforming the mesh according to the animated skeleton. What I wanted to achieve The goal was to ma

One of the first animation milestones I tackled in my engine was building a basic runtime playback system for glTF models. At this stage, the goal was not skinning yet. The idea was to get the engine to the point where it could import animation clips, play them back in real time, and apply them correctly to a model hierarchy. In other words: make the joints move properly before worrying about deforming the mesh itself. What I wanted to achieve The task was focused on setting

One of the biggest AI movement milestones I tackled in my engine was integrating Recast & Detour and building a full workflow around offline-baked navigation meshes, debug visualization, path queries, and NavMesh-constrained movement. At this stage, the goal was not crowd simulation, dynamic obstacles, or fancy steering. The point was to get the engine to the stage where it could: build a NavMesh from scene geometry, save it as an engine resource, load it per scene, query pat