Villagers With Practical Routines

Ashen Hearth’s published design direction uses goal-oriented action planning, or GOAP, for practical villager routines. Sensors write facts into world state, goals describe a desired result, and actions declare what must already be true and what they change.

The purpose is not to make a villager look randomly busy. It is to make a choice explainable: which goal mattered, which facts were available, and why did this action remain valid?

The Four Parts Of The Current GOAP Architecture

The inspected Unity reference implementation separates four responsibilities.

1. Sensors describe the present

A sensor observes one concern and updates world state. Existing state keys cover facts such as hunger, available food, target presence, attack range, health, ammunition and zone constraints.

This prevents each action from independently scanning the whole scene. It also makes update frequency explicit: a slowly changing need does not have to be polled on every frame, while a combat range check can update more often.

The reference agent schedules polling sensors with per-sensor intervals and spreads their initial updates instead of making every agent sample everything on the same frame. That is a practical performance measure, but it also introduces a design constraint: any state that can become urgent needs an event or a sufficiently responsive interval.

2. Goals define a desired state

A goal is a ScriptableObject with a priority and one or more desired world-state conditions. Agent profiles sort goals from highest to lowest priority before trying to build a plan.

For a homestead worker, conceptual goals might include becoming warm, resolving hunger or completing assigned work. The exact goal only becomes meaningful when its desired state is concrete. “Be useful” cannot be planned; “not hungry” or “fuel delivered” can be tested.

3. Actions declare preconditions and effects

Actions are ScriptableObjects with preconditions, effects and an exposed cost. Runtime behavior is implemented by the action, while the planner works with its declared state transition.

A simplified food chain might read like this:

SeekFood
  requires: IsHungry = true, HasFood = false
  changes:  HasFood = true

EatFood
  requires: IsHungry = true, HasFood = true
  changes:  IsHungry = false

The declaration is not the movement or animation itself. It is the promise the planner simulates. If runtime execution cannot keep that promise—for example, another agent consumes the target item—the action must fail cleanly and request a new plan.

4. The planner simulates and backtracks

The planner clones the current world state, applies an action’s declared effects and recursively searches for a sequence that satisfies the goal. It avoids reusing the same action inside one candidate plan and backtracks when a sequence reaches a dead end.

The agent then executes the resulting queue one action at a time. Before and during execution, preconditions can be checked again. A changed condition or an action-specific interruption clears the stale plan and triggers replanning.

A Necessary Honesty About Cost

The reference action model exposes a Cost value, but its current recursive planner does not compare total candidate-plan cost. It accepts the first viable sequence it finds in the configured action order.

That means action ordering currently carries more behavioral weight than the field name “cost” suggests. Calling the implementation fully cost-optimized would be inaccurate.

This is an important next step because a settlement often has several valid answers. A villager could use nearby stored food or walk farther to harvest a crop. Both may satisfy hunger, but distance, danger, reservation state and stockpile policy should eventually influence which plan is preferable.

Until cost comparison is implemented and tested, profile ordering should remain deliberate and the debug surface should show the chosen goal, action queue and facts that made the plan valid.

Replanning Without Thrashing

Reactiveness is useful only when it remains stable. Replanning on every frame can make an agent abandon work whenever a minor state value changes.

The inspected reference agent uses several guards:

• world state has a version that changes only when a value actually changes;
• planning has a minimum interval;
• failed plans wait before retrying when no new world-state version exists;
• running actions can define their own interruption conditions;
• sensor work is scheduled instead of synchronized across all agents.

These controls reduce wasted work, but they do not replace action ownership. A farming or hauling action still needs to release its reserved target when interrupted. Otherwise the planner can recover while the world remains locked by stale state.

Direct Orders And Autonomous Needs

A settlement game eventually has to reconcile two sources of intent: what the character needs and what the player asks them to do.

The cleanest approach is not to bypass planning for every order. A direct order can become explicit state or a higher-priority goal, with clear rules for cancellation and emergency interruption. A “hold” command should not quietly lose to an idle goal; a character in immediate danger may still need permission to break it.

This is where authoring matters as much as algorithms. Priority values, sensor ranges, action availability and interruption policy together create the perceived personality of an agent.

What GOAP Does Not Solve

GOAP chooses a plausible state transition. It does not automatically solve:

• navigation and unreachable targets;
• shared-resource reservations;
• animation timing;
• inventory capacity;
• social believability;
• save/load of work in progress;
• good player-facing feedback.

Those remain separate contracts. Keeping them separate is useful because a pathfinding failure should not be “fixed” by changing a hunger goal, and a missing inventory slot should not appear as mysterious planner indecision.

Ashen Hearth’s direction is therefore practical: build a planner that can be inspected, connect it to small survival facts, and expand the routine library only when each new action has clear ownership and failure behavior.

Read Farming Before Empire for an example work chain, Keeping the Hearth Alive for the settlement pressure those routines serve, or explore Ashen Hearth for the wider game direction.