FSM_API: The Pure C# Core That Decouples Your Logic from Any Engine

We recently announced our pivot at The Singularity Workshop: shifting focus from building a custom ECS engine to perfecting the FSM_API (Finite State Machine Application Programming Interface). This move ensures a stronger, more maintainable foundation for MyVR and offers immediate, open-source value to every C# developer.

The FSM_API is the blazing-fast core of this vision. It is built to be completely engine-agnostic, allowing you to define complex, reliable behavior in pure C# and deploy it anywhere—from backend services and robotics to Unity or other game engines.

Here's how FSM_API provides the decoupling and power every developer needs in their toolkit:

---

🧠 1. Decoupling Logic: The IStateContext Contract

The biggest challenge in state management is coupling logic (the how) to data (the what). FSM_API solves this by requiring every managed entity to implement the simple IStateContext interface.

• FSM Logic is Abstract: The FSM Definition (your blueprint) contains the states and transitions, but it knows nothing about "player health" or "door position". It only understands abstract actions like onEnter, onUpdate, and onExit.
• Your Data is the Context: Your custom C# class (e.g., PlayerContext or LightSwitch) implements IStateContext. This object holds all the data and physical methods (like PlayAnimation() or TakeDamage()) that the FSM's actions will call.
• A Self-Cleaning System: The IStateContext includes a crucial IsValid property. If your object is destroyed or no longer relevant, setting IsValid to false automatically tells the FSM_API to unregister and clean up the associated FSM instance, preventing memory leaks and errors.

This clear separation ensures your logic is reusable, and the system manages its own lifecycle.

⚙️ 2. Engine Agnosticism: Deployment Anywhere

Because the core FSM logic doesn't touch Unity's MonoBehaviour or any other engine code, FSM_API is instantly compatible with any C# environment.

• Pure C# Ready: You can define a complex AI system using the fluent FSMBuilder and run it in a simple console application, a backend server, or a robotics controller.

• Explicit Control with Processing Groups: In environments without a built-in game loop (like a console app or backend service), you gain explicit control over the update cycle using Processing Groups:

  1. You create a logical group (e.g., "AI_Logic" or "Network_Processor").
  2. You assign FSM instances to that group.
  3. You manually call FSM_API.Interaction.Update("GroupName") exactly when you want the FSMs to tick.

This level of control is essential for server-side logic and custom engine environments where performance demands are high.

💡 3. Dynamic Power: Runtime Modification

Most FSM solutions are static: once defined, they can't change. FSM_API's FSMModifier shatters this limitation, enabling the runtime recomposition that powers our innovative AnyApp vision.

The FSMModifier allows you to change the FSM blueprint (the definition) after it has been built, even while instances are actively running from it.

• Adaptive AI: Dynamically add a new "Enraged" state or modify the transition condition for "Flee" after a major in-game event.
• Dynamic UI/Content: Add or remove navigation paths based on user unlocks or content downloads without requiring a full recompile or app restart.
• Live Hot-Reloading: During development, modify FSM logic and apply the changes immediately in a running build for rapid iteration.

This is the key to creating applications that can genuinely adapt and change on the fly, transforming static software into fluid, composable experiences.

🚀 Get Started with the Free Core

The FSM_API is designed to be the fastest, most flexible, and most robust solution available for C# developers.

The core DLL is open-source and free, available now on NuGet. Get started today:

• NuGet Package: TheSingularityWorkshop.FSM_API
• Find out more about our full roadmap (MyVR, AnyApp, and the FSM_Layer Asset Store packages) on our Patreon page.