
Farming Before Empire
A practical Unity farming-system design for Ashen Hearth, informed by DTWorldz crop growth, watering, season and persistence reference code.
Jun 7, 20266 min readBy Deniz TrakaUpdated Aug 31, 2026
Ashen Hearth starts farming at homestead scale. The goal is not to simulate an agricultural empire; it is to make the path from an empty patch of ground to stored food visible enough that the player can understand who worked, what changed and why the harvest matters.
That makes farming a survival loop first and an economy feature second.
The Smallest Useful Farming Loop
A useful first implementation needs more than a crop timer. It needs a chain that the rest of the game can observe:
- A field or fertile plot is available.
- A seed or crop definition determines what can be planted.
- Planting starts a crop lifecycle at a known game time.
- The crop moves through visible growth stages.
- Watering can modify the current cycle.
- A mature crop becomes harvestable.
- Harvesting produces something that must be carried, stored or consumed.
The reusable DTWorldz Unity crop lifecycle represents Seed, Sprout, Young, Mature, Harvestable and Dead states. Growth is calculated from the planted game time and the configured total growth time rather than from an animation that happens to be playing. That separation is a useful reference for Ashen Hearth because presentation can change without silently becoming the source of gameplay truth.
Watering is deliberately small in that reference implementation. A crop can be watered once during its active cycle, advancing its effective progress by ten percent of its configured growth time. Ashen Hearth’s eventual balance and watering contract may differ; the useful lesson is to keep the modifier explicit and testable.
Field State And Crop State Are Different
A field answers questions such as “which plots exist?” and “is this plot already claimed?” A crop answers different questions: “what was planted?”, “when did growth begin?” and “is the plant ready to harvest?”
Keeping those responsibilities separate prevents one large farm object from owning every rule. It also gives the AI and save system smaller facts to reason about.
For a worker, the useful world state is not “farm animation should play.” It is closer to:
- an eligible plot exists;
- required material is available;
- the plot is not reserved by another worker;
- a harvestable crop exists;
- the destination inventory can accept the output.
Reservations are especially important when several workers share a small field. Without a claim that is released on completion, interruption or failure, two agents can select the same plot and perform convincing movement toward an impossible result. The visible symptom looks like bad pathfinding, but the actual problem is work ownership.
Farming As A GOAP Chain
Farming becomes useful to a settlement when its actions have explicit preconditions and effects. A planting action might require an available plot and seed, then leave the plot occupied and growing. A harvesting action might require a harvestable crop, then make produce available for hauling.
The exact actions can change as the prototype evolves, but the planning contract should stay inspectable. The GOAP architecture note describes how DTWorldz separates sensed world state, action requirements, desired effects and replanning.
The important limitation is that a planner does not automatically create a good farming system. Navigation, reservation cleanup, inventory capacity, animation timing and failure recovery still need explicit owners. “The AI decided to harvest” is only the beginning of the work.
Seasons Without Hidden Rules
The reusable Unity foundation keeps season progression separate from crop progression. Its season system resolves the current value from elapsed game days and an authored cycle. Spring, Summer, Autumn and Winter exist as possible values, while the default active cycle can omit a season until the authored world supports it.
That distinction avoids an easy content mistake: the presence of a Winter enum does not prove that every crop already has a finished winter rule.
Season-sensitive crop behavior should therefore be data, not an assumption scattered through planting code. A crop definition can eventually answer questions such as:
- Which seasons permit planting?
- Does an existing crop pause, die or continue when a season changes?
- Is growth time modified by season or weather?
- What happens when a save loads after the crop’s expected completion time?
Those rules need clear player feedback before they become harsher. If planting is blocked, the field should explain why. If a crop dies, the cause should be recoverable from state rather than inferred from a missing sprite.
Persistence Is Part Of The Feature
Farming is a good stress test for save/load because it contains both identity and elapsed time.
At minimum, persistence needs enough information to reconstruct the plot, planted crop, lifecycle state and relevant timestamps. Loading should not blindly restart growth, duplicate a harvest or leave an old reservation attached to a worker that no longer exists.
The Ashen Hearth save-system breakdown explains why restoration order and validation matter. Time must be available before time-based state can be interpreted, while a restored crop should not emit normal “just planted” side effects simply because its component became active.
What Is Not Being Claimed
This prototype note does not promise a finished agriculture simulation. Animal husbandry, soil chemistry, irrigation networks, spoilage, cooking depth and large production chains are separate design problems. They should not be implied by the existence of a crop state machine.
The verified reference value is narrower and more useful: crops have explicit lifecycle state, game time has an owner, seasons are configurable, and the surrounding architecture has places for AI work and persistence to connect. Ashen Hearth can adopt or revise those contracts as its own playable implementation is validated.
That gives Ashen Hearth a farming foundation the player can read in the world. Food begins as a need, becomes work on a visible field and ends as something the settlement has to carry home.
Explore the Ashen Hearth game page, then continue with Keeping the Hearth Alive to see how food and fuel support the same survival-settlement loop.
Continue reading
Nearby notes in the atlas.
Related entries are connected by the systems and world they document.
Field noteAshen Hearth
A Fragile Sense of Order
Devlog 01 on the unstable feeling behind Ashen Hearth: scarce resources, passing time, harsh weather and villagers trying to hold the homestead together.
Field noteAshen Hearth
Keeping the Hearth Alive
How Ashen Hearth's campfire design can connect fuel, cooking, warmth and settlement work, informed by a reusable DTWorldz Unity foundation.
Field noteAI
Villagers With Practical Routines
How a reusable DTWorldz Unity GOAP foundation informs Ashen Hearth villager goals, world-state sensors, actions, replanning and known limits.
