Start Building

Case Study - Shipping a Cozy Farming Sim with AI-Driven NPC Schedules

We set out to ship a small cozy farming sim with one twist: NPC daily schedules were designed and tuned with AI. Not scripted by hand for every character and every hour. This is what we did, what worked, what failed, and what we would do differently.

Why AI for NPC Schedules?

In a cozy farming sim, villagers need to feel alive. They open the shop at 9, tend the garden in the afternoon, and show up at the tavern at night. Doing that for 15+ NPCs across seasons and story flags usually means huge lookup tables or brittle scripts. We wanted variety without manual authoring of every schedule line.

Goals:

  • Reduce authoring – No hand-written 7am–midnight blocks for every NPC.
  • Keep coherence – Schedules should respect role (blacksmith, farmer, baker) and world logic.
  • Allow tuning – Designers should be able to say "more time at the tavern" or "avoid rain" without editing code.

So we used AI at two stages: initial schedule generation (from short briefs) and tuning passes (from designer feedback). The game logic stayed in our engine; AI produced structured data we could validate and tweak.

The Setup

  • Engine: Unity (C#). NPC behavior and time-of-day were already in place.
  • AI: We used a single LLM API for both generation and tuning. No custom models.
  • Data format: Each NPC had a list of "schedule entries" – time range, location ID, activity ID, and optional conditions (e.g. weather, day of week). We stored these as JSON and loaded them at runtime.

We did not let AI run the game or drive real-time decisions. AI only produced schedule tables; our code executed them.

Phase 1 – Generating Schedules from Briefs

For each NPC we wrote a short brief: name, role, personality, and a few constraints (e.g. "always at the market on Sundays"). Example:

Brief: "Mira, the baker. Up before dawn to prepare bread. Opens the shop at 7. Takes a break mid-morning. Closes at 2 and spends afternoon at home or in the garden. Likes the tavern on Friday nights."

We sent the brief plus a strict JSON schema to the LLM and asked for one day (we later repeated for different days and weather). We got back something like:

  • 5:00–7:00 – Home (preparing)
  • 7:00–12:00 – Bakery (working)
  • 12:00–12:30 – Home (break)
  • 12:30–14:00 – Bakery (working)
  • 14:00–18:00 – Home or Garden (relaxing)
  • 19:00–22:00 – Tavern (Friday only)

What worked: First-pass schedules were good enough to drop into the game. We got plausible, role-consistent behavior with minimal prompt engineering. Designers could iterate by changing the brief and re-running.

What didn’t: The model sometimes invented locations or activities we didn’t have (e.g. "beach," "library"). We fixed that by listing valid location and activity IDs in the prompt and asking the LLM to only use those. After that, invalid entries were rare.

Phase 2 – Tuning with Designer Feedback

Designers played the build and gave natural-language feedback, e.g.:

  • "Mira is at the bakery too long; she should close earlier on weekends."
  • "The blacksmith should never be at the tavern when it’s raining."

We sent the current schedule plus the feedback to the same LLM and asked for an updated schedule (again as JSON). We then diffed the result against the previous version and only applied changes that still matched our schema.

What worked: Small, targeted edits (e.g. shift one block by an hour, add a weather condition) were reliable. Designers could work in prose instead of editing JSON.

What didn’t: Big, ambiguous requests ("make everyone feel more alive") produced noisy or inconsistent changes. We got better results when we asked designers to give concrete instructions (who, what, when/condition). We also ran a simple validator (schema + valid IDs) on every AI output before applying it.

Phase 3 – Variety and Edge Cases

We wanted the same NPC to have different schedules for different days or weather, without authoring every combination. So we:

  • Generated a "base" schedule from the brief.
  • Asked the LLM for variants (e.g. "rainy day," "Sunday," "festival day") with instructions like "change only 2–3 entries; keep the rest."

What worked: Variants stayed coherent and felt like the same character. We could add new variants (e.g. "post-quest") without redoing the whole schedule.

What didn’t: We had to guard against the model changing too much. We added a rule: "at least 80% of time slots must be unchanged from the base." That kept variety without breaking character identity.

Lessons We’d Reuse

  1. Use AI for data, not control. Generate schedules (or dialogue, or balance numbers) as structured output; let your game code remain the single source of truth.
  2. Constrain the output. Provide a strict schema and a fixed list of valid IDs. Validate every response before it touches the game.
  3. Prefer small, concrete tuning. "Shift Mira’s closing time to 1pm on Saturday" beats "make the village feel busier."
  4. One source of truth for logic. Time, weather, and story state live in the engine; AI only proposes content that respects those.

For more on behavior design and NPC systems, see our guide on building your first AI NPC and the Unity AI Toolkit.

FAQ

Did AI write the game code?
No. AI only produced schedule data (time, location, activity, conditions). All runtime behavior was our C# and Unity logic.

How did you avoid invalid locations or activities?
We listed every valid location and activity ID in the prompt and validated each AI-generated schedule against that list before importing.

Could this work for dialogue or quests?
The same pattern works: brief + schema + valid IDs, then generate or tune with feedback. We used it only for schedules in this project.

What model did you use?
We used a single commercial LLM API. The approach is model-agnostic as long as the model can follow a JSON schema and stay within given IDs.

Was it faster than hand-authoring?
For the first pass, yes. Tuning and validation took time, but we avoided writing hundreds of schedule lines by hand. For a larger cast or more variants, the gain would be even larger.

We shipped the game with AI-generated NPC schedules that felt coherent and were easy to tune from natural-language feedback. If you’re building a cozy sim or any game with lots of character routines, this pattern is worth trying: AI for structured content, your engine for rules and execution.

Found this useful? Share it with your team or bookmark it for your next cozy or simulation project.