[ FAQ ]

Frequently asked questions

Honest answers to the questions that don't fit cleanly into the other pages — licensing, scope, comparisons, what's stable, what isn't.

"Why GOAP instead of just Behavior Trees?"

Behavior Trees require you to hand-author every sequence. GOAP lets the planner invent sequences automatically by combining actions whose effects satisfy a goal state. BT is explicit (you design the tree); GOAP is declarative (you define actions and goals; the planner synthesises the action chain).

Two practical wins:

• Action count scales sub-linearly. Adding a new action to a BT often means re-authoring every branch that should now consider it. Adding an action to a GOAP archetype just means dropping the asset in — the planner picks it up automatically wherever its preconditions hold.
• Emergent recombination. A planner can chain actions you never manually sequenced. Your "Cook" action's effect is FoodReady=true; your "Eat" action's precondition is FoodReady=true. You never wrote "first cook, then eat" — the planner derived it.

For tightly-scripted, designer-driven sequences (cinematic combat encounters, multi-stage boss fights), BT or StateTree often fits better. Intent Forge can sit inside one of those as a single task, so it isn't an either/or — see Why Intent Forge.

"Do I have to write C++?"

No. The Quickstart is 10 minutes, Blueprint-only. Every C++ extension point has a Blueprintable companion: goals, actions, considerations, cost strategies, sensors, executors all have Blueprint subclassing paths.

C++ is faster (5–20× for hot extension points like cost strategies and sensors), but for prototyping and small-scale production you don't need it.

"What about networked / multiplayer AI?"

Not yet. Server-authoritative networked planning needs deterministic search, state reconciliation, and latency tolerance — none of which are addressed yet.

For now: run AI on the server (or on a single host in cooperative games) and replicate the outcomes (actor positions, animation states, GAS attributes) through standard UE replication. The planner stays local.

"Can I ship a commercial game with this?"

Yes. MIT licensed. No royalty, no attribution requirement beyond the LICENSE file. Plugin's LICENSE and the docs site's LICENSE both spell out terms.

"How does this compare to Utility AI?"

Utility AI evaluates each candidate action by a utility curve every tick and picks the highest scorer. No search, no planning ahead. For combat — "pick the best move this frame" — that's the right shape. For longer-horizon tasks where you want a sequence (gather → craft → use), utility AI doesn't help.

Intent Forge's goal scoring borrows from utility AI (the UIntentGoalConsiderationSet mechanism), but the centrepiece is the planner, not the scorer.

"What UE versions are supported?"

UE 5.7+. The plugin depends on the GameplayStateTree plugin (default-enabled since UE 5.5) and on IntentForgeStateTree's StateTree task API. Earlier 5.x versions have not been tested and may require shim work.

When UE 5.8 / 5.9 ship, the goal is to track the latest engine version with one-version lag at worst.

"Why doesn't it need an AIController?"

The built-in Auto dispatch mode (default for EIntentDispatchMode) uses a tickable world subsystem to drive executors directly. It walks the registered components once per frame and calls EnterAction / TickAction / ExitAction from the subsystem, not from a per-actor controller.

This means:

• No AIController allocation per agent.
• No BehaviorTreeComponent overhead.
• No Blackboard data layer (the world state lives on the component directly).
• Works on any AActor — pawn, static actor, anything.

You can use an AIController if you want one (External dispatch mode + your custom controller). The framework doesn't preclude it; it just doesn't require it.

"How many agents can it handle?"

Performance baseline at the reference machine: p99 < 0.5 ms per replan cycle at 2000 agents on a single thread. Linear scaling past that; at 4000 agents the p99 is ~0.68 ms.

That's the framework cost only — your actors, animations, sensors, and movement components dominate at scale. See Performance for the full methodology and a checked-in baseline JSON you can compare your own runs against.

"How do I report a bug?"

Plugin bugs → github.com/dreulavelle/IntentForge/issues.

Documentation bugs (typos, broken links, factually wrong code samples) → the docs repo.

Useful info to include in any bug report:

• UE version + plugin version (Help → About Unreal Editor)
• Output of IntentForge.DumpAgent <PartialActorName> from the Output Log
• A minimal repro (smaller is more likely to get a fix)

"Can I contribute?"

Yes. PRs welcome on both repos. The plugin's contributing guide lives on the plugin repo; the docs side has its own.

Smallest wins first: docs typos, code samples that don't compile, broken links. Larger features (new sensor type, new executor) — open an issue first to discuss scope.

"Is this production-ready?"

Not yet validated in a shipping game. 83 automation tests pass, the architecture is committed to, and the API is stable enough for serious prototyping. But "compiles cleanly + tests green" isn't the same as "battle-tested in the messy edge cases real production hits." Until a real game ships using Intent Forge end-to-end, treat it as production-targeting rather than production-validated.

"Is the API stable?"

When a public symbol is renamed, the old name keeps working for one minor version so your code and Blueprints don't break on upgrade. Hard breaks are called out in the release notes.

The first stable major release will lock the public surface; breaking changes after that follow semver MAJOR bumps.

"Why MIT licence, not GPL or proprietary?"

MIT is the most permissive practical option. You can use, modify, fork, and sell games built with the plugin without sharing your code back. The trade-off is that someone could in theory fork the plugin and sell it as their own — allowed but obviously not ideal at scale. The bet is that the original repo, the original docs, and the original author's continued investment are worth more than the threat of a fork.

"Will there ever be paid features?"

Currently: no plans. The whole framework is MIT and stays that way for the first stable release. Later, if the project picks up enough adoption to justify it, a paid Pro tier (Live Inspector + advanced analytics + a production support channel) is a possibility — but only after the free tier is locked-in and well-validated. Free-tier features won't move behind a paywall.