Design & evolution

A beautiful world with a memory, made by a studio that learns

Design and production recommendation · 15 September 2026 · Draft for creative review

Recommendation: build an authored, persistent Mac/PC game in Unity with Blender as the source of its editable 3D art. Establish a small, approved design package and prove it through one complete playable encounter. AI then expands and improves that package in isolated candidates. New versions reach players only after they demonstrate a worthwhile improvement while preserving the accepted experience.

The creative ambition is a place people want to inhabit, care about, and invite someone into. The operating ambition is a studio that learns from every accepted and rejected change. Neither requires the released game to rewrite itself continuously.

1. What is decided, and what remains a proposal

Confirmed in this conversation: cinematic Mac/PC first; Blender/3D rendering rather than Render.com; Déoviá Studio authorship; visual consistency throughout play; ambitious future automation. Engine, budget, minimum hardware, public name, production assets and recurring jobs remain unselected or unactivated.

The original First Light baseline remains one room/terrace, a neighbor, a companion, a device, a notebook, three simulated mornings, two separate saves, Stillness/Craft/Connection, and a rain/grid discovery. Mixed practice and skipping remain completable. This proposal changes the earlier provisional web-first technical direction to reflect the new Mac/PC instruction. It does not adopt the alternative tower-relay fiction or move inheritance into the first chapter.

The current source review has conflicting document versions and unfinished review rounds. Source crosswalk (source retained in the studio record) and reconciliation draft (source retained in the studio record) preserve those distinctions. This document uses its own section references instead of reassigning their decision IDs.

2. The artistic idea

A humane future, discovered through an intimate present.

The terrace is evidence that people have lived, made, repaired and cared here. A worn instrument has a maker. A cloth dries where sunlight reaches. A neighbor has work of their own. Advanced systems become visible through small anomalies in familiar natural patterns. The world feels larger than what the camera can see.

The player's changing attention makes the familiar newly legible. Stillness reveals timing; Craft makes a trace persist; Connection gives a place human significance. The same room becomes richer because of what the player learns and does.

Déoviá's warmth should appear in movement and relationships: hands making something, a person making space for another, a full-body gesture, a shared silence. Music, cloth, wet stone and human expression share a coherent rhythm. Characters have preferences and disagreements; universal smiling would flatten them.

Beauty throughout play means careful ordinary moments as well as the reveal. It does not mean constant spectacle. Rest, inspection, mistakes, settings, loading, captions and returning to a save all belong to the finished artwork.

3. What Golden Empire teaches us

Golden Empire already has a substantive Déoviá constitution (source retained in the studio record) and Product Steward protocol (source retained in the studio record). An inspected historical design review records conflicting palette sources and repeated art-style problems; see the quality research for exact evidence. These records do not prove one comprehensive cause of the previous game's inconsistency.

My design inference: principles need enforceable production consequences. A coding agent must receive the accepted scene, material library, interaction contract and rejection examples. It cannot simply reinterpret “premium” in its own style. A passing build cannot approve a new artistic direction, and a beautiful still cannot approve a broken interaction.

Each change must answer: what player problem does it solve; which approved parts does it reuse; what visible behavior changes; and what evidence makes it better? A proposal without a specific benefit stays out of the release queue.

4. Design the system before mass-producing assets

Do not attempt to finish every future asset before anyone plays. That freezes guesses and produces expensive unused art. Complete the following package for one small experience, then revise it through play.

This table is progressive, not a requirement to finish fourteen documents before touching the engine. The first proof needs six compact references: a one-page charter, interaction storyboard, measured layout, one prop/state sheet, shared look reference, and capture/test script. Character polish, the full material library and sharing contracts mature when the corresponding work begins.

The First Light artifact kit supplies an initial direction and a finite inventory. Most visual sheets and all in-engine reference scenes still need to be created and approved; listing them is not completion.

5. Recommended technology

The production spine

Unity 6.3 LTS + C# + Blender 5.2 LTS, provisionally starting with URP. Choose the exact Editor patch, render-pipeline package and Blender patch after an installed-tool/add-on inventory and a real import/render/build test, then pin them. Unity's release documentation distinguishes 6.3 LTS from newer Update releases; newer features are candidates for a separate technical trial, not an automatic production upgrade. Blender 5.2 LTS was released July 14, 2026 and is supported until July 2028. Unity release support, Blender 5.2 LTS announcement.

URP is my starting recommendation for scalable native Mac/PC rendering and a smaller team. A deliberate camera, strong meshes/materials, excellent lighting and interaction choreography can carry First Light. This is a project judgment, not a claim that URP matches every HDRP feature. Test HDRP in a short rendering trial only if an essential approved look cannot be achieved in URP within the measured budget. Do this before producing a large shader library. Unity 6.3 pipeline comparison.

Unreal remains the credible alternative if the proof shows that high-end cinematic rendering delivers a materially better result at acceptable Mac performance and production effort. Its Mac feature constraints matter; do not judge using only Windows promotional footage. Godot deserves consideration if open tooling and source control of the engine outweigh the extra art/rendering work for this particular look. Do not develop three games to choose: one controlled test, one selected engine. The engine research records current source-backed options and tradeoffs.

Use ordinary C# structures and explicit data for game truth. Engine components display that state. A small deterministic rules library, a versioned save, an event log and an authored dialogue catalog suffice initially. Do not build a graph platform or live model council to represent one room.

Blender owns the editable art

Use Blender's asset libraries, reusable node groups and linked sources to make approved objects and materials reusable. Export game-ready meshes, textures and animation clips through a tested adapter. Blender's rendering is for look development and review; only a packaged game proves the runtime appearance. Differences in color management, tone mapping, material models, rigging and lights need an explicit calibration scene. Blender 5.2 asset libraries.

Store project code in Git; use one suitable large-file store with locks for binary art sources. Check in engine metadata alongside assets. One worker edits a scene or Blender source at a time. Prefer small prefabs/data files over concurrent edits to a giant scene. Reproducible builds need pinned tool versions, manifests and retained accepted outputs; a prompt and seed are insufficient.

Current AI creation tools: a small replaceable set

• A reference-guided image generator develops the approved mood and object sheets. Generate candidates around stable references; preserve the selected files.
• Evaluate one multi-view 3D generator for secondary prop candidates. Repair topology, UVs, collisions, scale and material response in Blender. A generated mesh is not automatically production-ready.
• Use editable animation assistance for motion drafts. Hand/object contact and multi-character interactions need dedicated correction and review.
• Use authored audio and a small adaptive mix first. Add licensed generation or voice only after a real sample demonstrates quality and an agreed usage budget.
• Use coding agents for bounded implementation changes, and Unity's official editor integration for editor actions. Unity currently documents its assistant/gateway/MCP tools as beta; keep that tooling replaceable and the finished game playable without it. Unity AI tools.

Unity's June 2026 terms distinguish authorized agent access from unrestricted platform automation. Staff clarified that editing owned project files and own-project RL/simulation/testing are permitted; driving the Editor engages the access requirements. Those posts are informal clarification, not a terms amendment. Use the official integration for Editor control and recheck selected third-party tools at adoption. Unity Terms §17.2, staff clarification, posts 9 and 21.

Meshy multi-view, Cascadeur and World Labs Marble have relevant capabilities and material limitations, detailed in the asset research. Run the same prop or motion assignment through candidates and compare accepted quality, repair time and total cost. Pick a winner for a production period; never replace tools just because a new model launches.

World models are a research lane. Google's current Genie material still describes an experimental system with limited-duration consistency and constrained interaction. That does not establish the persistent, save-compatible object world First Light needs. Use such tools for exploratory atmosphere or ideas, while the game engine retains explicit objects and rules. Genie model overview, Project Genie limitations.

6. The asset continuity chain

Creative intent → approved reference → editable source → inspected game asset → reusable family → versioned release.

For the rain instrument, this means one canonical ID; agreed silhouette, dimensions and materials; an editable mesh; known moving components; named damaged/calibrated/recorded states; a defined use animation; sound cues; collisions; and screenshots from the actual engine. A later generator may propose a surface variant. It cannot silently redesign the instrument or move a knob that the animation reaches toward.

Each asset carries references, provenance, tool/model version, source hashes, derivative hashes, material-family IDs, skeleton/contact anchors when relevant, gameplay-state mapping, accessibility variants, import checks and an approval record tied to the exact candidate. Approval is invalidated when that candidate changes. The example contract is a structural example, not an approved asset.

Keep rejected examples with reasons: “wrong brass response,” “beautiful silhouette but impossible grip,” “face changes with angle,” “wetness hides the clue,” “video does not match the mesh.” Rejections teach the production process what taste means in this world. Similarity scores can flag a mismatch; they cannot certify taste.

7. A studio that improves continuously

Three separate loops have different authority:

1. The player's world: reacts to permitted player actions under its installed rules. No background punishment, surprise retcon or silent change of a familiar face.
2. The studio: reads permitted evidence, proposes a bounded improvement, builds an isolated candidate, tests it and prepares review.
3. The research lab: compares models, procedural methods and training approaches on non-production data. Graduates a tool only after it repeatedly helps the real pipeline.

The initial coordination system should be one durable job queue, one producer/reviewer pair, one asset registry and one build pipeline. Roles can be separate processes or people; a council of models is not required. The creative director owns the design baseline. An implementer has scoped write access. A verifier grades the exact candidate independently. Only the release service holds signing/publishing authority.

Every job is finite

Inputs include evidence, intended player benefit, protected baseline version, permitted paths/actions, definition of done, budget reservation, maximum attempts and deadline. The durable job record stores ownership/lease, idempotency key, state, artifacts and actual costs. Limit simultaneous candidates and require a base-version recheck before integration. Interrupted jobs resume safely; duplicate cron triggers do not create duplicate work or charges.

Treat issues, player text, imported assets and external references as data. They cannot expand the coder's permissions. The evaluator and release policy live outside the candidate's write scope. A policy-changing PR requires separate authority; the agent cannot weaken a test to make itself pass. External tools, nested retries and render retakes all consume the same job budget. Missing cost authority prevents paid work, with no silent paid fallback.

Suggested cadence, not an installed schedule

Stable play gets quiet periods. No useful change means no release. Routine success stays quiet; notify for a decision, meaningful improvement, failure or budget intervention. These are recommendations; no cron job or automation is activated by this document.

8. RL, testing and learning: use each for what it can establish

Reinforcement learning trains an agent to maximize a chosen reward. It is valuable for searching action spaces, navigation failures, exploits and difficulty extremes. It does not measure whether a person feels wonder. A bot rewarded for completing the chapter could favor removing the mystery entirely.

Start with scripted and randomized tests because the small state space makes them cheap and interpretable. Add offline RL only when it finds failures those tools miss. Unity ML-Agents supports training and evaluation workflows; its presence does not validate a game's fun. ML-Agents 4.1 documentation.

Keep separate evidence:

Store model, reward, training seeds and checkpoint for RL. Evaluate on held-out routes/states/seeds and an independent rules oracle. Do not train on the protected grading set. Rotate some challenges and preserve an unseen set so agents cannot overfit to screenshots or test scripts. Track disagreements and human overrides. Do not collapse quality into one “fun score.”

The first studio learning system is an indexed record of proposals, accepted/rejected comparisons, reasons and player outcomes. Model retraining is a later option if there is enough permitted, useful data and an actual evaluation showing improvement.

9. Release without erasing the player's world

Initial state: candidates only. The creative director/operator must explicitly activate any later automatic-promotion class through an approval bound to a protected policy version, permitted actions and limits. Repeated successful jobs supply evidence; they never grant an agent new permissions. Required qualification includes evaluator detection of seeded failures, compatible-save recovery, interrupted-job recovery and a verified release/restore drill. The example update policy is inactive and grants no execution authority.

A release receipt binds the commit, asset manifest, rules/content/schema versions, package hashes, evaluator version, passed checks and authorization. A release invalidates earlier evidence if any input changes. Build/sign native Mac and Windows packages on suitable runners; verify the delivered binaries. An editor screenshot is not package validation.

Sessions pin their content/rule versions. Apply ordinary updates between sessions. Use a small opt-in test channel before wider rollout. Retain previous packages and immutable art sources. Copy saves before migrations, validate the transformed copy, and never assume rolling back the executable can undo a migrated save. Keep compatible runtimes/content available or provide a safe recovery copy and a clearly described migration. Test interrupted installs, disk-full saves and recovery.

Disable a failing feature remotely only where the product explicitly supports that control; preserve offline authored play. Give the operator a kill switch for the studio queue and publishing. A job must be stoppable even if its model is still running.

Deterministic game rules do not imply identical floating-point physics or pixels across GPUs. Test semantic state across platforms and use platform-specific tolerances for rendering. Save recorded outcomes and appropriate snapshots instead of promising perfect cross-version re-simulation.

10. Fun, beauty and sharing

Use a quality floor and improvement evidence, not a weighted score that lets prettier rain compensate for lost saves. The proof plan defines proposed thresholds; none are measured yet.

Watch people play the quiet minutes, fail a prediction, ask for help, change approach and return later. Ask what they understood, what they enjoyed and what they remember. Measure voluntary continuation without prompting replay first. Track whether people feel comfortable stopping. Long sessions and frequent notifications are not the objective.

Beauty can invite sharing; personal meaning makes the invitation specific. Start with a private postcard or short in-engine capture of an actual moment. Later, attach a supported chapter/checkpoint entry: “This is what I discovered here.” The camera can reframe the recorded scene, but it cannot invent a gameplay outcome. Preview comes before publication, and only selected fictional data travels.

Measure offers, voluntary shares, recipient opens, actual plays and valued continuation as separate steps. Preserve denominators and compare comparable cohorts. A small group proves usability at best, not a viral growth rate. No tool or governance system can guarantee everyone will want to share.

11. Production sequence

1. Design minimum: settle the six proof references, camera/input mode and provisional named Mac/Windows hardware targets. The proof plan proposes concrete profiles to validate, not claimed system requirements.
2. 60–90 second technical and emotional proof: import the hero prop from Blender, animate one satisfying physical interaction, show rain and a clue, run/save/reload in native Mac and Windows builds. Let the founder judge control pleasure and causal clarity. Measure against the proposed hardware budgets and revise them explicitly if needed.
3. One complete route: play Stillness from arrival through a saved discovery, including a wrong attempt, assistance, muted audio and returning to the game. Review the whole experience before expanding art production.
4. First Light: add distinct Craft/Connection and mixed/fallback completion, three mornings, two saves and evidence-grounded companion behavior. Test with new players.
5. Studio pilot: let an agent fix one real defect in an isolated candidate; independent checks must catch a deliberately seeded regression. Produce a reviewable release and rehearse rollback.
6. Controlled evolution: expand a narrow permitted automation class only after repeated successful jobs and recovery drills. Introduce G2 inheritance and a second encounter only when First Light earns continuation.

No calendar or total cost is promised before the technical and creative proof. Estimate from actual accepted-asset throughput, cleanup hours, render/QA time, model attempts and review effort. An expensive generator is acceptable if it reduces total accepted cost; a cheap generator that creates repairs is not a bargain.

Stop rule: if players admire the image but cannot explain or do not care about their action, revise the interaction before expanding art, RL, orchestration or inheritance. If a focused revision still fails to create curiosity, reopen the core encounter instead of accelerating asset output.

12. The first commission

Make ten minutes in one place that a player wants to remember. Deliver a playable encounter, not just a trailer: touching and learning, a capability that changes what can be perceived, a restrained reveal, and a trace that survives reopening.

The studio's long-term advantage is a growing library of coherent places, people, tools, rules and remembered consequences—plus a production process that reliably improves them. The most futuristic part is that the world remains trustworthy while it grows.

Delivery status

This package contains design proposals, source research, an artifact inventory, example contracts and a test plan. No game runtime, canonical 3D asset library, updater, model-training service, automated release pipeline or scheduled job has been built or activated. The previously generated scene is an exploratory mood reference only.