Arbiter

C++20, SFML3, CMake, GoogleTest · In progress

Problem

Wanted a dedicated space to practice modern C++ and game AI systems architecture, separate from building a full game.

Features

Utility AI scoring system (Considerations, Response Curves)
Blackboard-based shared data system
CMake FetchContent for dependency management
Unit tested with GoogleTest

Approach

Built Utility AI from composition-based building blocks — Consideration classes hold a ResponseCurve and a Blackboard key, Actions aggregate multiple Considerations into a score. Chose composition over inheritance for flexibility.

Dev Log

I started Arbiter after finishing a steering behaviors project, wanting a dedicated place to build real game AI systems instead of one-off demos.

The first real design decision was how to structure Utility AI. I considered hardcoding each Action's Considerations directly in its constructor, but went with a more flexible, data-driven approach instead — Considerations are built from composable pieces (a ResponseCurve and a Blackboard key) rather than inheritance hierarchies.

One thing I didn't expect: getting the Blackboard's string-keyed lookup right took more thought than the scoring math itself. It's a small piece of the system, but it ended up shaping how every other class reads shared game state.