Dominatus - Finite State Machine + Utility Hybrid Behavioral AI for Dotnet Game Engines

[yuechen-li-dev]

I promised you guys game engine tooling months ago, so here is something I built that I want to show you guys.

https://github.com/yuechen-li-dev/Dominatus
https://www.nuget.org/packages/Dominatus.Core/

In one sentence: It's a behavior AI runtime that combines the best of every approach to game AI: determinism and traceability of hierarchical finite state machines, the easy author-ability behavior trees, and adaptability under complex situation of utility AI.

All of it is in normal C# on dotnet 8, there is no separate bytecode VM nor visual editor, so all the tooling that you would expect from the Dotnet CLR ecosystem just works: Roslyn, xunit.net unit tests, etc., and you can just use Git for version control of your NPC AI and dialogues.

The biggest advantage is there really isn't anything new to learn: If you know Csharp, you know how to write Dominatus nodes.

I made it because I wasn't happy with any behavioral AI system currently available on the Unity Store or open source on Github, as they tend to be visual scripting heavy or reflection heavy, and most finite state machine system with explicit transitions are especially difficult to write, and so I decided to build my own behavior AI system, and this is the result:

If you are familiar with Unity coroutines, this should be super simple for you, as a basic AI node looks like this:

public static IEnumerator<AiStep> Patrol(AiCtx ctx)
{
    while (true)
    {
        ctx.Bb.Set(Keys.Destination, GetNextWaypoint());
        yield return Ai.Act(new MoveToCommand(ctx.Bb.GetOrDefault(Keys.Destination)), Keys.LastMoveId);
        yield return Ai.Await(Keys.LastMoveId);
        yield return Ai.Wait(1.5f);
    }
}

Which I think it's pretty easy to write compared to traditional finite state machines. I do have a full architecture and authoring guide on the repo as well, for people who are interested.

It comes with battery included:

• Strongly typed blackboards for memory
• An event bus based mailbox/actuator system for how the agents interact with the game world.
• Ariadne, a Yarn Spinner like dialogue system built on top of Dominatus, which allows you to write text adventures directly in CSharp, I have a playable demo right now that you can build with VS and play in your terminals.
  • If you take a look at the source code script for this demo text adventure, it's slightly more boilerplate than Yarn Spinner, but pretty much better in every other respect: uses normal Csharp control flow, no variable/state synchronization issues, integrates with the rest of the Csharp codebase.
  • To use it as a dialogue system in Stride, I think all that's needed to be written is a runner connecting the Dominatus system to Stride's UI, which should be relatively easy to do.
  • It's probably a bit arrogant for me to say this, but I personally think that everything you can do in Yarn Spinner, you can do it better in Ariadne.
• Persistence, a full save/load system with rollback support, outputted in chunked JSON, built in.

Beside the text adventures, I also have a playable fishtank simulator as a demo built in MonoGame to demonstrate the utility AI portion of the system, Dominatus.Fishtank. You can build the csproj in VS yourself, or you can download it on itch.io in the link below. Still need to add video to it, it looks better in motion.

https://yuechenli.itch.io/dominatusfishtank

And as usual, always free, always open source.

@Eideren I know you've been working on an AI/dialogue system of your own, would you (and other interested Stride maintainers too) mind taking a look at it, test it out, and let me know what you guys think?

[Eideren]

Haven't been able to run the fish tank (missing sdl dll exception) to see how it runs, but have looked at the authoring guide to get a clue on how we use it. Quite a vast feature set and documentation, really impressive, I do really like the idiomatic c# as well.

For dialogs and AI I tend to prefer designing non-programmer-centric tools, it's mostly a result of prefering to create authored over systemic content in games. Authored content is easier to setup if your tool bridges the gap between level design, animation and writing, while systemic should be programmer centric to prevent any friction when designing and manipulating those systems.

From what you said, I understand that your goal here is to be programmer centric, so I'll focus on that.

I don't think iterators are the right fit for the overall architecture, I implemented a thin AI SM over it a couple of years ago, so I understand your drive for using it, it definitely is more straightforward than states defined as update loops, or manually writing SM logic in a c# MoveNext-like method, but it leads to some interesting corner case, like some of what you mentioned in your guide.

• I find that having to yield break under certain circumstances, for clarity or control flow, is not that straightforward when your states become larger
• Push and Pop is uniquely could be more idiomatic t
• Awaiting for a specific thing to happen in the world, like your deferred completion, without incurring an additional delay before resuming can be awkward to create. A busy loop is easy to setup, but is definitely not free, and with AI already taking a big chunk of the frame time...

Strings as Ids and output for the example choices is a though sell as a programmer, but I understand that the alternative may be far less terse.

These days I prefer working with asynchronous methods instead

• The state's delay can be as granular as it wants with task completion source and the likes, and doesn't often require new class definition and the likes
• pushing would just be calling the method and awaiting its task
• poping would be returning, and if we want to prevent the caller from continuing we could throw or return a boolean it should satisfy.
• Goto could be calling the task before returning, or returning the task for the caller, or a high SM system to handle.
• The state's output is closer to idiomatic c#, with returning just one value, or none, instead of an iteration, and doesn't need to be abstracted away to fit into AiStep or pushed to the blackboard to read from the caller.

But there is no silver bullets really, I find it significantly harder to debug than other methods, a pain to setup persistence/saving, and definitely has a higher barrier to entry.
So take all of that with a grain of salt. In comparison with getting this up and running, those are all fairly trivial issues, and doubly so if this is more of a personal tool.