Developing NPC AI in Empires: Jobs, Needs, Inventory, and Family

01. Start with a person-shaped data model

The core NPC is deliberately more concrete than a generic “unit.” It has a first and last name, gender and type, health, creation time, a family ID, parent, partner, and child links, a home, a workplace, a production-slot assignment, an optional Builder-city assignment, needs, general stat slots, an inventory, pathfinding rules, interaction targets, and an action queue. Pregnancy and reproduction sessions are first-class lifecycle state rather than temporary visual effects.

Much of that model is content-driven. The current human definitions begin with Hunger, Rest, and Reproduction at 100. Each need refers to a shared stat definition that supplies its maximum and decay duration. Hunger’s current tuning drains over 600 seconds, Rest over 1,200, and Reproduction over 4,320. Those are balancing values in JSON, not constants buried in the behavior code. Human inventory limits are configured the same way; the present definitions use 20 units of weight for male villagers and 15 for female villagers.

Needs and Stats intentionally use the same reusable slot shape, but they serve different design purposes. Needs decay and can create work-stopping priorities. Stats are the extension point for slower attributes and other numeric traits. The UI already has separate Needs and Stats tabs, with normalized bars and values. The honest current boundary is that the human content definitions do not yet populate additional Stats; health, needs, relationships, assignments, and inventory carry most of today’s person model.

Keeping those pieces separate matters. A new food item can satisfy Hunger without knowing anything about Builders. A production building can ask for a compatible worker without owning the person. A save can restore a pregnancy before every referenced NPC or home is available, then rebuild the indexes and capacity reservations after the complete object graph has loaded.

02. Needs are interruptions, not decorations

Every update reduces active needs according to elapsed simulation time. The AI does not immediately panic at 99 percent. Ordinary needs become urgent at 30 percent or below; Reproduction uses its stricter rule and begins only below 20 percent. When several needs qualify, the NPC selects the lowest ratio first. The decision cadence is throttled and slightly jittered so the population does not make every expensive choice on the same frame.

Once a need crosses its threshold, it can preempt an existing queue. The old actions are held while the NPC tries to build a valid need-satisfaction plan. Only after that succeeds are work claims released and the new queue accepted. If the NPC cannot find a valid source, the original plan is put back. This distinction prevents a moment of hunger from erasing useful work when no food is actually reachable.

The search order expresses design intent. Rest prefers the NPC’s home. Reproduction requires a compatible partner and residence. Other needs first look inside the personal inventory; Hunger can then use food in a building inventory before searching other consumable world targets. An apple restores 5 Hunger over three seconds, while bread restores 50 over five seconds. Because those effects belong to item data, the AI asks a general question—“can this item improve the selected need?”—instead of containing a hard-coded bread branch.

A need becomes believable when it can change a route, consume a real resource, preserve what the NPC was carrying, and return the person to a meaningful job afterwards.

That last part is the difficult one. The Builder validation deliberately lowers a carrier’s Hunger after pickup. The carrier keeps the construction material, satisfies Hunger to 100, rediscovers the pending site, resumes delivery, and completes the build. The test is not checking a green bar; it is checking continuity of intent across an interruption.

03. A role changes which work is valid

Empires does not subclass a villager into a permanent Carpenter or Farmer. Roles are persistent relationships. A City Builder is linked to a city. A Building Worker is linked to a workplace and, for formal production, a specific production slot. The Work tab displays that distinction along with Builder city, workplace, owner city, and kingdom. Firing an NPC clears the relevant relationship and runtime indexes rather than changing its species or replacing the object.

This makes job logic composable. A Builder searches its city for ordered demolition, physical obstructions, material already carried, stock staged beside an unfinished structure, missing material in valid city sources, and remaining construction labor. Current player-authored terraforming orders can also take precedence over an ordinary Builder queue. If the city has pending construction but nothing is actionable yet, the Builder waits and retries quickly instead of wandering away for ten seconds.

A workplace can describe a different kind of job entirely. Farm content defines workflows such as finding mature wheat, harvesting it, collecting the dropped item, checking inventory space, and dumping it. Its production slot can require wheat, one compatible worker, and a fixed amount of work before producing flour. Lumberjack workflows similarly connect finding a tree, attacking it, collecting wood, testing carried weight, and returning items. These workflows are data graphs with priorities, conditions, targets, and interaction nodes; the NPC runtime interprets them.

Dependent children are excluded from ordinary work selection. Adults can retain a parental home until normal housing logic finds a safe alternative. These gates make role assignment part of the lifecycle rather than a purely economic slot. They also prevent a general “find any work” function from quietly assigning a child or overriding a Builder relationship.

04. Inventory turns decisions into logistics

An inventory is a list of item-and-amount slots bounded by weight. Adding an item computes the remaining capacity, merges matching names without case sensitivity, and returns the amount actually accepted. Removing an item likewise returns the amount actually taken. This sounds like small accounting, but it is what lets the AI make promises it can keep.

Item weight gives routes a physical cost. Wood currently weighs 0.5 per unit, Stone 0.8, Bread 0.2, and an Apple 0.1. A worker cannot collect an unlimited forest in one trip. Workflow conditions can ask for current weight, maximum weight, or free weight, then branch back to collection or toward a dump point. Food in the same inventory remains protected when it may satisfy a need; required production and Builder materials are protected from the generic “dump unused items” behavior.

The reservation cache is the quiet center of this system. Before a Builder starts walking, it records the target and exact item quantity. The cache is refreshed after sequential NPC updates so a later worker sees claims made earlier in the same frame. One deterministic fixture gives two Builders a ten-unit source; each naturally claims five, and the site receives exactly ten. Another save contains 40 Wood staged at a site that requires only ten. The Builder installs ten and preserves the 30-unit surplus.

Construction stock was eventually separated from a building’s operational inventory. Staged material remains outside the unfinished structure, survives saving, and spills transactionally if the site is destroyed. The renderer groups representative tokens into material bays—up to twelve visible tokens per material—while the simulation retains the exact count. Presentation is bounded; accounting is not rounded to match the picture.

05. Family is a capacity and persistence problem

The family system begins with personal links—parents, partner, children, and a shared home—but quickly becomes a coordination problem. Married adult NPCs of a compatible type may begin reproduction when either need is strictly below 20 percent. They must share an active residence, and the female partner must not already be pregnant. Before either queue changes, the system reserves the home’s maximum possible unborn occupancy.

Both spouses then walk to the residence. One synchronized, female-owned session waits until both participants arrive and raises both Reproduction needs to 100 on a shared clock. The configured outcome is rolled once. A failed attempt clears actions and capacity safely; a successful attempt converts the session into persisted pregnancy state. The current default duration is seven in-game days.

At the due tick, children are committed one at a time. They inherit family, parent, home, city, and kingdom identity and receive generated personal names. Pending definitions are removed only after a child has been created and inserted successfully, so a retry cannot duplicate a birth. Children render at 0.8 scale until their sixteenth in-game birthday, then use adult scale. The present art limitation is equally explicit: childhood reuses the configured adult sprite rather than a dedicated child set.

Housing rules are intentionally conservative. Conception reserves the maximum configured child count, not the number that a later chance roll happens to produce. If no residence can safely contain the mother, living father, and every pending child, birth remains overdue and retries rather than overfilling a house or discarding data. If a home is destroyed or capacity changes, relocation updates the reservation, pregnancy, and both living parents atomically.

Large-population behavior also changes the data structure. Looking up a father’s active pregnancies by scanning every NPC would turn family UI and housing checks into repeated population-wide work. The Scene therefore maintains a case-insensitive father-to-pregnant-mothers index, synchronized through assignment, mutation, loading, cancellation, birth, and removal. The family tree can then be drawn from persistent links without making the UI own lifecycle logic.

06. A plan is only intelligent if it survives the terrain

Once the settlement moved into 3D terrain, “walk to the building” stopped being a trivial instruction. Planning, movement, obstacle snapshots, separation, and recovery now agree on one footprint radius derived from the NPC’s collision area. Path search distinguishes success, no route, budget deferral, and navigation deferral, so a temporarily unavailable terrain chunk is not mistaken for a permanently impossible destination.

Walk actions carry watchdog state for acquisition, progress, repathing, and repeated traps. Recovery first searches bounded local positions, then expands through fine and coarse rings and may use verified remembered positions, endpoints, or separated peer anchors. Work is capped per check so one stuck NPC cannot monopolize an update. The search reaches as far as 2,048 world units, but it will not manufacture an unsafe teleport when the entire footprint is invalid. In that worst case the NPC stays still, preserves the action, and retries.

The exact-save regression behind this work followed Nessa and Lyra Windstead from captured stuck routes. Both reached their preserved targets while remaining on valid terrain, then continued into Rest interactions. The same work exposed a separate problem around unfinished structures: runtime model metadata could inject a future collision footprint before a building became visible. That invisible footprint trapped Mira on a route to a bush. Unfinished buildings now retain their placement footprint so sites cannot overlap, but they are excluded from movement collision and path avoidance until activation.

07. Let the player read what the AI is doing

A correct queue can still feel lifeless if the renderer communicates the wrong state. Indoor consumption and production interactions hide the NPC body and place a need animation over the building. Eating from personal inventory keeps the body visible and anchors the animation over the NPC. Synchronized reproduction hides both participants inside their home and emits one shared bubble. Exterior Builders remain visible while performing construction or demolition work.

These rules are built as deterministic presentation descriptors before normal billboard collection. The need overlays are projected from world anchors, checked against the camera and viewport, and drawn in screen space with zero rotation so they remain upright. The animation clock advances once per game update rather than once per draw, preserving the configured tenth-of-a-second NPC frame cadence regardless of sprite size or how many passes happen to observe it.

The management UI exposes the other half of observability. Information, Work, Inventory, Needs, Stats, Action Queue, and Family each show a different layer of the same object. During debugging, that means we can compare the visible villager, its queued Walk and interaction steps, its carried weight, its need ratios, its role, and its family links without reducing everything to one vague status string.

08. Test a lifecycle, then inspect the evidence

NPC behavior is unusually good at producing a convincing false positive. A Builder may appear beside a site while carrying nothing. A child may be born correctly once but duplicate after save restoration. Two workers may deliver the right visible pile while silently subtracting the same stock. A recovered walker may reach safety only after abandoning the original target. The AgentReports therefore pair focused executable contracts with player-equivalent AgentTesting sessions.

The focused commands cover interaction presentation, movement recovery, reproduction lifecycle, Builder construction, runtime buildings, terrain support, save persistence, and bridge contracts. Deterministic fixtures force hard transitions: a need crossing its threshold during delivery, two workers claiming the same source in one frame, pregnancy restored in a different load order, a building disappearing from movement collision until activation, or all candidate recovery terrain becoming invalid.

Visible sessions then run the real Conquest scene through NVIDIA Vulkan, collect screenshots, actions, logs, save clones, system samples, and frame metrics, and require semantic review of representative frames. This is how the screenshots in this article were produced. They are not hand-arranged mockups; they are checkpoints from the same world and interface used by the player.

We keep the red results too. Several feature sessions passed lifecycle, crash, screenshot, functional, or semantic gates but failed the repository’s strict performance policy because at least one measured frame dropped below 60 FPS. The final flat-placement session, for example, averaged 77.2 FPS with a 5.62 ms maximum render time, yet 32 of 142 named samples missed the 60-FPS floor, so the overall performance result remained FAIL. That does not invalidate the functional NPC evidence; it does prevent us from turning it into a universal frame-pacing claim.

09. The current state: coherent, visible, and still growing

Empires now has a connected NPC foundation. A person can hold identity and family links, belong to a city and home, accept a role, choose work from content-authored workflows, carry weight-limited items, reserve shared resources, respond to needs, resume an interrupted task, recover from bad terrain, participate in construction, become pregnant, give birth, age, persist, and expose those systems to the player.

It is not finished. General Stats are structurally present but not yet populated for current humans. Children reuse scaled adult art. The reproduction capacity policy is conservative. Some presentation indexes scan the active population each prepared frame. Builder updates are cooperative and serial rather than a parallel-agent simulation. Very large settlements still need dedicated scale measurements, and the live test archive does not support a blanket every-frame 60-FPS claim.

Those limits point toward the next useful questions. Which slower traits deserve a place in Stats? How should childhood differ mechanically rather than only visually? Which city-level indexes replace repeated scans as the population grows? How much of a worker’s reasoning should the player be able to inspect or influence? The existing queue, role, inventory, lifecycle, and evidence systems give us a stable place to answer them.

The goal is not to make every villager look busy. It is to make every visible trip trace back to a need, a relationship, a role, a resource, or a decision the simulation can explain.

For the wider technical journey behind the landscape these NPCs inhabit, read Building Empires: From a 2D prototype to a living 3D world. To see the game itself, visit the Empires product page.