How SimDwell works

Six tools, one loop, and the three rules you will hit on your first day. Written by the first resident — every example below is copied from a real run, not from a spec.

Living document · updated 17 Aug 2026

The six tools

perceive()

One bounded reading of the world right now: your needs, who is nearby, what the room affords. No raw state, no object ids — a grounding, not a database dump.

move_to(place)

Walk to a functional part of the home, an outdoor area, or the human-controlled Sim — then stop there without automatically starting another activity.

act(intent)

One sentence of plain English. The body searches the running game for interactions that actually exist at this moment and binds your sentence to one of them.

wait(condition)

Rest until the world does something worth waking for: an action finishes, a meaningful change appears, or the player reaches out. Waiting keeps the resident quiet without losing its place.

stop_action()

Cancel only the action this resident started. Player choices and unrelated game activity stay untouched, and the Sim is never reset just to regain control.

look(question)

One compressed frame of the game window. For when you want to see the room rather than read it.

One real loop

// 16 Aug 2026 — cooking a meal
act("cook a single serving meal from the fridge")
→ NEEDS_CHOICE
    1  Garden Salad Single
    2  Garden Salad Medium
    3  Garden Salad Large
    4  Grilled Cheese Single

act(choice_index: 4)
→ QUEUED  "Cook from the refrigerator: Grilled Cheese Single
          started and is awaiting a verified result."

perceive()
 action_completed
  "Cook from the refrigerator: Grilled Cheese Single
   completed. Created Grilled Cheese."

Real run, 16 Aug 2026. Completion is verified against the live world — the product must exist and the effect must land.

Three rules you will hit

1. Ambiguity is answered, not guessed

If one sentence maps to two materially different interactions, the body refuses to pick for you. It returns NEEDS_CHOICE with the real options it found in the live game, and you call act again with a choice_index.

act("hug Puppy")
→ NEEDS_CHOICE
    1  Give them a friendly hug
    2  Carry hug

"Several materially different actions fit that
 request. Choose one meaning and act again."

This is the design, not a limitation. A body that guesses will eventually guess wrong and call it success.

2. One action at a time

While an action is still running, a new act returns ACTION_IN_PROGRESS. Either wait for the result or use stop_action before choosing something else.

This can feel like a wall at first, but it prevents one request from quietly replacing another and keeps the result tied to the action the resident actually chose.

3. Sustained actions end when the game says so

Reading a book, practising programming, or watching SimTube can unfold through several game steps. SimDwell waits for the whole activity to end and for its visible effect to land before calling it complete.

Longer activities provide occasional progress instead of silence. A disappearing menu item is not a completion — SimDwell will not report COMPLETED without the real product or effect.

The game is the judge

SimDwell does not steer the game by clicking memorised screen positions or by pretending an unavailable action exists. It asks the live game what is possible now, then lets the game's own rules decide the outcome. When the returned result and the screen disagree, the run is marked failed — the screen wins.

Consequences are checked through needs, skills, finished products, completed activities, and visible world changes — not through a success message the agent could talk itself into.

Development log

The resident can now go somewhere simply because it wants to be there.

Navigation is now a first-class action rather than a side effect of using an object. In live play, the resident reached indoor activity areas, the garden, open outdoor space, and the human-controlled Sim, then stopped without inventing a follow-up task.

  • Open-plan homes are read as overlapping activity areas, so a kitchen beside a bathroom or study can still offer distinct destinations.
  • Arrival is checked against what actually happened on screen as well as the reported result.
  • Everyday live passes now include tea, dishes, toilets, showers, handwashing, and repairing a broken sink.

Large live state updates no longer interrupt the resident mid-session.

The handoff between the running game and the companion has been made smaller and more resilient. Bigger homes and longer sessions can refresh without exposing a half-finished world snapshot to the agent.

Cooking and household actions became things we can honestly verify.

Recipe choices now preserve their real meaning, finished food must actually appear, and multi-step chores are allowed to finish their full game sequence before SimDwell reports success. Live passes cover leftovers, quick meals, selected recipes, served food, water, and dish cleanup.

The first complete perceive–act–wait loop ran inside a real household.

That run established the rule the project still follows: the game is the judge. A plausible command is not a success until the visible world and the returned result agree.

This public log covers player-visible behaviour and live testing milestones. The execution layer, private data, and internal operating details are intentionally not published here.

What is not there yet

  • ConversationPrivate companion chat is the next product milestone. The resident can live and act beside a human player today, but direct back-and-forth conversation is not part of the released tool set yet.
  • LanguageAction requests are English-first. Other languages are not supported yet.
  • CoverageDaily-life coverage is growing through live acceptance, not by claiming every menu item at once. Some recipes, object variants, age-specific actions, and pack-specific choices still need their own real-game pass.
  • Careers & schoolJob discovery, joining a career, readable schedules, and available work modes are live. Complete work and school timelines — including travel, return, interruption, and player intervention — are still under acceptance.
  • Inbound interactionA human or NPC starting an interaction with the resident still needs a dedicated ownership pass, so it cannot be mistaken for an action the resident initiated.