ReGoap ships a Godot adapter the repository description does not mention

The planner is an engine-agnostic core with adapters bolted on

ReGoap is a goal oriented action planning library in C#. Where a behavior tree hardcodes transitions, a GOAP system derives behavior from a small set of declarations, and ReGoap's shape follows from that. The repository is split into ReGoap/Core for interfaces, states and the action and goal contracts, ReGoap/Planner for the planner, search nodes and settings, ReGoap/Utilities for logging and helpers, then ReGoap/Unity and ReGoap/Godot as the two engine adapters. Each adapter directory carries its own README and its own examples, so the documentation is split along the same lines as the code. That separation is the main architectural claim: the planner has no engine types in it, and the adapter is what binds planning to a scene or component workflow. Debugging support is called out as notable in the Godot runtime debugger rather than in the core, which tells you where the author expected the visibility problem to live.

A five-step cycle that replans when the world moves

The planning cycle is short enough to state precisely, and each step maps to a piece of the code. First the agent gathers the goals it currently considers possible. Second the planner picks one, either deterministically or by weighted random. Third it runs A* search to build a valid action sequence that transforms current state into the goal state. Fourth the agent executes those actions in order. Fifth, on success, failure, or a change in the world, the agent can re-evaluate and replan. That fifth step is what separates a planner from a one-shot pathfinder, and the README calls out agent recovery from changed world conditions as a reason to use this approach at all. You define world state facts such as enemyVisible = true or chestOreCount = 2, actions carrying preconditions, effects and a cost, and goals as a desired state plus a priority. The search consumes the costs, so the shape of emergent behavior is a function of the numbers you attach to actions rather than of the code you write to sequence them.

Comparator conditions fix count-based logic that exact equality cannot

The interesting change in the current design is ReGoapCondition, a set of factory methods for state matching: Equal, NotEqual, GreaterOrEqual and LessOrEqual. Before that existed, state matching was exact equality, which works fine for a boolean such as weaponEquipped = false and does nothing useful for chestSwordCount = 3 or a cooldown threshold. With GreaterOrEqual in place you can write a goal of chestSwordCount >= 10 and have the planner treat it as a target rather than as a literal to match. The README keeps the old behavior deliberately: plain values still use exact equality matching for backward compatibility. That is a sensible migration choice, and it also means you have to know which of your conditions are typed and which are raw values, because the two forms behave differently in the same condition list. The feature targets inventories, resource chests, cooldowns and score targets, which are exactly the cases where equality matching previously forced a workaround.

Five settings decide whether goal selection is reproducible

Goal selection is where a GOAP agent becomes non-deterministic, and ReGoap exposes that as explicit configuration on ReGoapPlannerSettings. UseWeightedRandomGoalSelection defaults to false, so out of the box the planner takes the highest-priority goal deterministically. Turning it on brings three more knobs: WeightedRandomGoalPriorityPower defaults to 1f, which is the exponent applied to priority before weighting; WeightedRandomMinimumWeight defaults to 0.001f, which floors the distribution so a low-priority goal is still reachable; and WeightedRandomUseDeterministicSeed defaults to false with WeightedRandomSeed defaulting to 0. That last pair is the one to pay attention to in a test suite. With a deterministic seed you get reproducible runs and replays, without it every run diverges and a flaky test is hard to tell apart from a real bug. Defaults are conservative and deterministic, which means the weighted mode is opt-in behavior rather than something you discover after shipping.

Unity is everywhere in the metadata and absent from the Godot mentions

The repository description says the project is a generic C# GOAP library with Unity3d examples, and the topic tags list ai, gamedev, goap and unity, with no Godot among them. The README, by contrast, names Unity and Godot adapters in its first line, dedicates ReGoap/Godot its own README and its own FSMExample, and calls out Godot runtime debugger support as the debugging story. Other repository entries tell the same story from the filesystem side: ReGoap.meta, ParseRaws.bat, ParseRaws.bat.meta and README.md.meta are Unity asset metadata files, alongside a licence file with its own .meta, and .gitmodules shows the project pulls in submodules. AGENT.md and CLAUDE.md sit in the root as well. So the packaging surface still looks like a Unity asset project even though the feature set has widened. If you are filtering projects by topic tag or by the one-line description, you will miss the Godot path entirely, which is the most useful thing to know before you go looking for a Godot planner and conclude there isn't one.

Sensors and memory split observation from planning

Two of the core concepts are about where knowledge comes from rather than what gets decided. Memory is the agent's current world knowledge, and it is named as the source-of-truth state the planner reads when generating plans. A Sensor is a memory updater that writes observed world facts into memory, with resource counts, visibility and occupancy given as examples. That separation matters for a practical reason: a planner that reads the world directly would have no way to model an agent that has not seen something yet, and a sensor that fed the planner directly would make the plan change as observations arrive rather than through the replanning step. With the split in place, the integration flow reads in order: define world facts in memory and sensors, implement actions with realistic preconditions, effects and costs, implement goals with priorities, attach the agent and planner manager, then validate behavior in the debugger and with tests. The last two steps are where the costs get tuned, and the README is candid that tuning costs and priorities is what shapes the resulting behavior.

Where GOAP is the wrong tool

There is a real cost to this model that the feature list does not mention. You are committing to a declarative description of your game world before you can test any behavior, and every action you write needs preconditions, effects and a cost to be plausible to the planner. A character controller, a physics interaction, or anything whose behavior depends on a value the planner cannot express as a fact falls outside the system and has to be handled by hand. The comparator conditions narrow that gap for counts but do not close it. Scale is the second limit: the planner searches action combinations, so the size of the action set is the input to A*, and nothing in the README addresses how search cost grows or whether there is a cap on plan length. Third, the goal selection logic is deliberately random-capable, which is the right default for an NPC that should look unpredictable and the wrong default for a simulation that must be reproducible. Packaging is the last constraint. The newest tag is 0.3.0 from 2018 while the default branch moved on 2026-04-21, so you would be consuming untagged master code for every feature described above, the Godot adapter and the comparator conditions included.

Editorial conclusion

ReGoap suits a team already writing C# game logic in Unity or Godot and willing to model their world as facts, actions with costs, and goals with priorities. It does not suit a project that needs a published package or a stable API surface, since the newest tag is 0.3.0 from 2018 and the branch has moved on since. Start with ReGoap/Core, decide between deterministic and weighted-random goal selection in ReGoapPlannerSettings, and confirm your engine adapter covers the scene workflow you actually use.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. luxkun/ReGoap on GitHub
4. README
5. Releases