# Sim Sim: a studio that keeps improving without losing the game Research and proposed operating design — 15 September 2026. This is a design artifact, not an implemented agent system, release authorization, or scheduler configuration. ## Recommendation Build a **stable game supported by a continuously learning studio**. Let AI search, prototype, test, and prepare improvements frequently. Change the player's world only when a particular version has passed explicit gates. Do not make elapsed time, an AI's own beauty score, or a successful bot run sufficient reason to publish. The realistic promise is: **protect a proven quality floor; discover improvements; reject regressions; preserve the player's history.** No current system can guarantee that each autonomous update will be more beautiful, more fun, or viral for everyone. The first implementation should remain First Light: one bounded place, humane routine, causal choices, persistent consequences, and accurate companion explanations. The current review preserves the rain/cooling-grid premise and explicitly identifies voluntary replay, emotional attachment, acquisition, and virality as unproven. Simsim reconciliation (source retained in the studio record), feasibility review (source retained in the studio record). ## What Golden Empire usefully teaches The local Golden Empire records already contain a strong studio constitution and a scope steward. The former connects choice, consequence, memory, and expression; the latter demands a smallest proof and challenges duplicate systems. Their existence means that adding another aspirational manifesto alone is unlikely to solve coherence. Studio constitution (source retained in the studio record), Product Steward (source retained in the studio record). A dated design review records three conflicting palette sources, art that read as a pasted-on sticker, duplicate action surfaces, and an instruction to judge the complete frame across desktop and portrait. These are concrete failure modes to prevent in Sim Sim. They are **historical document findings**, not a new audit proving the present Golden Empire implementation is broken or establishing the definitive cause of the user's dissatisfaction. Design review, 9 August 2026 (source retained in the studio record). The practical change is to make design executable: one material library, one source of interface tokens, one asset import contract, approved scene references, and a release job that cannot silently replace those references to make its own change pass. ## 1. The protected design package Each approved package is immutable by version, with deliberate amendments creating a new version. It is not a forever-frozen artistic direction. | Artifact | What it prevents | Enforcement | | --- | --- | --- | | Identity charter | New agents interpreting “future society” as a new genre every week | Named owner; product promise and exclusions included in every task | | Reference scene and capture set | Optimizing an isolated hero image while ordinary play deteriorates | Same scene, action script, camera, seed, time, build, resolution, and quality tier for comparisons | | Material, light, lens, motion, and sound rules | Assets individually attractive but incompatible together | Shared engine assets and import validators; no per-feature parallel token system | | Character and location continuity sheets | Face, silhouette, scale, clothing, layout, and cultural details drifting | Stable asset IDs; approved turnarounds and material references; in-engine inspection | | Interaction contract | Overlays and “smart” helpers crowding out the world | One home per action; input/state diagrams; touch, keyboard, controller, captions, reduced motion coverage | | Simulation and memory schema | Cinematics, advice, and history inventing different outcomes | Typed causal events and supported checkpoints; state machine validation | | Evaluation registry | Every coder redefining “good enough” | Independently maintained tests, references, device budgets, and evidence requirements | | Asset provenance manifest | Untraceable replacements or irreproducible generation | Source/license evidence, model/version when available, inputs, source hashes, derivatives, author review, import settings | Critical change rule: a candidate cannot change its implementation **and** loosen the acceptance standard in the same unattended release. Intentional new art direction is reviewed with both old and proposed references visible. A passing image-similarity metric cannot approve a creative direction. Evaluate motion as well as still frames: first input, close examination, ordinary traversal, interaction feedback, rain, low light, interruptions, captions, menus, save/resume, and completion. Include the least flattering moments, low-spec rendering, and long enough captures to see stutter, repetitive gestures, popping, or audio fatigue. Accessibility is part of the design target; beauty need not mean constant movement or sensory intensity. ## 2. Four different kinds of intelligence | System | Useful job | Evidence it cannot supply | | --- | --- | --- | | Deterministic scripts, property tests, and search | Check causal rules, reachability, save round trips, illegal states, boundary cases, and known journeys | Emotional attachment or aesthetic quality | | Offline RL and other playtesting bots | Search for exploits, unreachable rewards, dominant actions, stuck states, or unintended policies | Whether a person enjoys the activity or wants to share it | | LLM/vision reviewers | Flag continuity, writing, layout, or instruction problems and suggest hypotheses | Reliable final artistic judgment or representative player preference | | Real human playtests | Observe comprehension, agency, delight, attachment, voluntary return, and actual sharing | Exhaustive correctness or rare state coverage | Unity ML-Agents supports agents with observations, actions, and reward signals; training and inference are separate phases. Its current package documentation also covers imitation learning and multi-agent scenarios. This is a plausible tool for a Unity simulation test harness, not an automatic game designer. Start with scripted and search-based tests; add RL when it finds failures those cheaper methods miss. [Unity ML-Agents 4.1 theory](https://docs.unity3d.com/Packages/com.unity.ml-agents@4.1/manual/ML-Agents-Overview.html). RL optimizes the specified reward. A “fun” proxy can be exploited: time played rewards waiting, clicks reward busywork, task success rewards trivialization, and screenshot likes reward spectacle while controls suffer. Specification gaming is an established problem, including agents exploiting reward design and simulator assumptions. These examples motivate our recommendation; they do not prove that any particular Sim Sim optimizer will fail. [DeepMind: specification gaming](https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/). LLM judging has documented position, verbosity, and self-preference biases in language evaluation. That research does not validate LLMs as judges of game beauty or fun. Use them as fallible assistants, with shuffled A/B order, concrete rubrics, known counterexamples, and periodic comparison against human decisions. Multiple models agreeing is not independent player evidence. [Zheng et al., 2023](https://arxiv.org/abs/2306.05685). ### Bot design for this game - Maintain several policies: curious novice, methodical completionist, impatient player, motion-limited/input-limited player, and exploit seeker. These labels describe test behavior, not claims that bots accurately represent those populations. - Give discovery-test bots only player-visible observations. A bot reading hidden objective flags cannot establish that a player understands what to do. Privileged state inspection remains useful for correctness tests, separately labeled. - Keep some seeds, event sequences, interrupted saves, and scenarios held out from candidate optimization. Use fresh samples periodically; repeatedly optimizing against a visible benchmark eventually turns it into training data. - Freeze the bot policy and game rules for a given comparison. If both change, separately report the effects; bot adaptation can hide a game regression. - Compare baseline and candidate on matched conditions and multiple independent seeds. Record failures and uncertainty, not just the best run or average score. RL evaluation research specifically warns that few-run point estimates can mislead. [Agarwal et al., 2021](https://arxiv.org/abs/2108.13264). - Keep NPC model training offline. Publish a versioned model only after testing, with a deterministic fallback. Online adaptation affecting a player's experience should have an explicit design, limits, reset, and separate evaluation. ## 3. A minimal autonomous improvement pipeline ```text Consented evidence + observed defects + approved backlog | Prioritize one hypothesis | Bounded candidate job | Isolated coding / asset workspace | Reproducible build and artifact manifest | Independent tests and visual/audio comparison | Human preview when play or art changes | Opt-in test release -> stable release window | Observe -> retain or roll back ``` The first version needs a repository, an asset manifest, a job queue with durable status, isolated build workers, an evidence directory, and a release registry. One orchestrator can assign specialist jobs; persistent agents, a graph platform, or a separate studio dashboard are not prerequisites. Every candidate records: hypothesis, observed problem, exact scope, protected files, base revision, design-package version, generation/build inputs, test plan, expected player benefit, budget, stop conditions, result evidence, and rollback target. Art generation and code edits share the same change record when they depend on one another. ### Separation of authority | Role | Allowed | Deliberately unavailable | | --- | --- | --- | | Scout | Read consented evidence and propose a task | Production edits or publishing | | Builder | Change an approved scope in an isolated workspace | Production credentials; altering approval policy or protected evaluation references | | Evaluator | Run frozen tests and inspect artifacts | Editing candidate code to make results pass | | Release controller | Promote an approved artifact by digest | Running arbitrary generated commands or rewriting source | | Creative director | Amend identity, approve experiential change, adjudicate tradeoffs | No automation should infer this authority from agent consensus | A second agent with the same writable files and credentials is not meaningful separation. Enforce boundaries with permissions, protected paths, read-only test bundles, scoped tokens, and a release process outside the builder's workspace. Keep player text, generated content, and dependency documents as untrusted input; none may become job instructions or executable code through a content field. ### Progressively earn autonomy 1. **Now:** unattended analysis and candidate preparation; reviewed integration. Establish an enjoyable vertical slice and reference quality first. 2. **After repeatable proof:** auto-merge narrowly classified, reversible maintenance whose behavior preservation is independently checked. Changed gameplay, identity, companion tone, or hero assets still needs preview evidence. 3. **Later:** promote approved data/content variants inside a pre-approved envelope, with separate stable and experimental channels, compatibility rules, observation windows, and automatic retreat. 4. **Research track:** adaptive systems that learn from consented player evidence. Treat the optimizer itself as a versioned experimental product, audited for fairness, pressure, privacy, and drift. Autonomy is permission per change class, not a single all-powerful switch. Reclassify a supposedly cosmetic change when it changes visibility, feedback, attention, performance, or a player's ability to understand an action. ## 4. Scheduling, budgets, and freeze periods A cron trigger should wake an evidence check. It should not manufacture a feature merely because an interval elapsed. No new evidence, no approved task, or a full work queue means a clean no-op. Proposed initial operating defaults, to calibrate after measured runs: - At most one active candidate affecting a subsystem; serialize final integration. - One hypothesis per candidate; at most two repair/retake cycles before shelving it with the evidence. A retry cap covers generation, code repair, render, and evaluation together rather than resetting at every tool boundary. - Set per-job and daily compute/currency limits in the runner before allowing paid APIs. Count failed generations, retries, idle GPU time, artifact storage, and tests. Stop at the limit; no silent provider or paid-cloud fallback. - Idempotency keys, job leases, heartbeat expiry, cancellation, and maximum runtime prevent duplicate cron runs and abandoned workers from multiplying work or spend. - Hold ordinary feature releases during an active human comparison. Use a stable reference version; urgent repairs get their own recorded exception. - A suggested first public rhythm is one curated release window per week and an observation period between changes. This is a starting design choice, not a claim that a week is statistically sufficient. - For a small audience, use invited testers and explicit observations. “Five percent rollout” may be one person and gives no reliable experiment. At larger scale, define sample size, minimum effect, analysis plan, and guardrails before rollout. - Freeze when crashes, save failures, performance regressions, negative play reports, or spending limits breach their declared thresholds. Resuming requires a specific diagnosis and passing evidence. This artifact does not create any schedules or authorize charges. ## 5. Protect the player's world through updates **Release unit:** engine/build ID + rules version + content manifest + model/prompt version + save-schema version + approved design-package version. Store it as an immutable record. A player session pins compatible versions; do not mutate their simulation halfway through an action. **Causal state:** use explicit events with sequence IDs and validated state transitions. Generated prose describes the recorded result. It cannot grant resources, change history, or execute new code. Authoritative gameplay actions pass through the same validation whether proposed by a player or a companion. **Three replay promises:** distinguish a readable historical record, an executable checkpoint supported by pinned rules/content, and a derived image/video. A random frame in generated media is not automatically a resumable game state. Store actual accepted AI outputs when needed; do not rely on reproducing an old cloud-model call. **Save migration:** make a copy before migration, test older supported saves, preserve unknown optional fields when appropriate, and declare unsupported versions. Prefer additive changes and reversible migrations. Test disconnect, crash, partial download, storage-full behavior, and retry. A checksum detects changed bytes; it proves neither honest play nor identity. **Rollback:** retain the previous build and manifests, rehearse restore, and ensure the previous client can still read the state produced during the test rollout. A binary rollback that leaves incompatible saves or server schema behind is incomplete. If backward compatibility is impossible, use a separately tested restore/forward-repair plan before promotion. **Offline and private continuity:** the authored core should remain playable through model/provider outages. Player memories stay private by default, with export/reset/delete behavior designed from the outset. Exported or shared media must have an explicit preview and action by the player; beauty should create voluntary sharing without involuntary disclosure. ## 6. Evidence of fun and beauty Use a small set of interpretable outcomes instead of one composite “wonder score.” | Question | Early evidence | Misleading substitute | | --- | --- | --- | | Can a newcomer act meaningfully? | Observe unprompted first action and ask what changed and why | Bot completion rate | | Does the place feel coherent throughout play? | Blinded reference/candidate captures plus complete hands-on sessions | Best screenshot or prompt adherence score | | Are consequences worth caring about? | Player accurately recalls a choice and cares to inspect its later trace | Number of narrative lines generated | | Does the rhythm feel pleasant? | Comfortable control, readable consequences, permission to pause; observed frustration and fatigue | Longer sessions by themselves | | Do people want another visit? | Voluntary return or replay without a reward for doing so | Stated enthusiasm immediately after a guided demo | | Do they want to share it? | Actual voluntary export/share and recipient interest; record motives qualitatively | Likes on a concept image or a bot's predicted virality | Begin with a handful of formative sessions to find concrete issues. Such a sample informs design, not population-level claims. Alternate A/B order, preserve a baseline, distinguish founder taste from broader audience response, and keep accessibility/performance as independent gates. Report counts and uncertainty. Repeatedly selecting winners from tiny experiments creates false confidence. For the artistic bar, the creative director owns a coherent intention and authentic emotional response. Audience preference can inform that direction; it should not automatically flatten it into the most statistically average style. ## 7. Concrete failure modes and their tripwires | Failure | Early tripwire | Response | | --- | --- | --- | | Every update becomes louder | More overlapping effects, screen coverage, motion or sound intensity | Compare against approved attention/motion budget; review in ordinary play | | AI replaces intimacy with task lists | New tutorial overlays, prompts, chores, and repeated explanations | Observe first session; remove unneeded prompting; preserve silence | | Many beautiful assets create an ugly world | Lighting, scale, materials, character or palette mismatch in scene | Reject at import/integration review; adjust shared assets before regenerating everything | | Evaluator rewards itself | Candidate edits goldens/tests or submits only favorable captures | Protected references; evaluator-owned captures and evidence; manual amendment path | | Bots improve while people struggle | Faster bot success alongside human hesitation or confusion | Keep human and bot results separate; redesign affordances | | “Engagement” turns into pressure | Notifications, streak punishment, friction, or hidden difficulty changes | Reject against the player promise; do not optimize coercion | | Auto-update destroys history | Migration failures, missing IDs, unavailable content versions | Stop promotion; retain original saves and compatible build | | Multiple coders create design forks | Parallel token sources, duplicated state, repeated UI controls | Single owner per subsystem and serialized integration | | Endless generation consumes the project | Retries exceed cap or variants grow without decisions | Stop the job; require a narrower hypothesis and reference correction | | Beautiful demo hides inaccessible play | Low contrast, inaccessible input, motion discomfort, low-spec stalls | Fail release despite high visual preference | | Changing the game feels arbitrary | Same action produces unexplained new rules across sessions | Version pinning, readable release notes, optional experimental channel | ## Smallest proof before building the autonomous studio Deliver one polished interaction where a deliberate player action changes a visible object, writes a causal event, survives save/reload, and receives an accurate explanation. Capture ordinary play on the weakest supported target. Then complete the bounded First Light chapter and observe real players. Run one subsequent improvement through the proposed pipeline manually: baseline → hypothesis → candidate → independent evidence → human preference → controlled release → compatibility/rollback rehearsal. Measure the actual time, cost, rejection rate, and player result. Automate the parts proven useful. This establishes a studio practice grounded in a real game and a real improvement.