# Sim Sim: engine, Blender and platform research Research checked **15 September 2026** against official product documentation and release announcements. This is a decision brief, not an engine benchmark. No engine was installed or changed, and no scene was rendered during this research. ## Recommendation **Use Blender as the source of authored 3D assets; provisionally choose Unity 6.3 LTS for the native Mac/PC game, with Unreal 5.8 as the one serious comparison before committing.** The recommendation is a production judgment: a small, persistent, highly interactive place needs excellent iteration, readable state, maintainable code and repeatable releases as much as advanced lighting. The user has clarified that the first product is a cinematic Mac/PC game, and that “Render” meant Blender / 3D rendering. Browser and mobile parity are therefore **not acceptance requirements for the first chapter**. A native-first decision gives Unreal a stronger case than a browser-first brief would. Do not choose on a demo reel alone. Use one identical rainy-room scene, one human character, one tactile interaction, one save/resume journey and one camera route to compare Unity and Unreal on the actual Mac plus a representative Windows PC. Freeze the winning engine, renderer, packages and importer versions for the chapter. Do not let routine AI update jobs upgrade them. ## Current versions: verified, not guessed | Tool | Official evidence available today | Implication | | --- | --- | --- | | Unity | Unity **6.6** officially announced September 1, 2026. Unity **6.3 LTS** is supported through December 2027. | 6.6 is a supported update worth testing if a specific feature solves a measured problem; 6.3 LTS is the proposed production baseline. [6.6 announcement](https://discussions.unity.com/t/unity-6-6-is-now-available/1735357), [support policy](https://unity.com/releases/unity-6/support). | | Unreal | Unreal **5.8** release announcement is dated June 23, 2026. Epic calls it the last planned major UE5 release, with continued bug/regression support. | Test 5.8; do not plan around an unreleased UE6. [Official announcement](https://www.unrealengine.com/news/unreal-engine-5-8-is-now-available). | | Godot | The official archive lists **4.7.2 stable**, August 18, 2026. | A real current option; a 4.8 development snapshot is not the production baseline. [Release archive](https://godotengine.org/download/archive/). | | Blender | **5.2 LTS** released July 14, 2026, supported until July 2028; current release index lists **5.2.1**, August 25, 2026. Blender 4.5.13 LTS remains supported. | Propose 5.2 LTS for a new pipeline, unless existing studio add-ons/assets are proven only on 4.5 LTS. Do an inventory first. [Release announcement](https://www.blender.org/releases/5-2/), [active releases](https://www.blender.org/releases/). | Unity's general guidance prefers supported updates during new/mid-cycle production and LTS near production lock. Choosing 6.3 here is a deliberate stability tradeoff for an automatically maintained game, not a claim that 6.6 is unsupported or unsuitable. ## Engine choice These are engineering assessments informed by the linked capabilities, not measured rankings. | Choice | Why it could fit Sim Sim | Main decision risk | | --- | --- | --- | | **Unity 6.3 LTS** | Strong fit for a compact simulation with separate C# state logic, authored camera work and controlled asset updates. Cinemachine and Timeline provide established camera/sequencing workflows. | The renderer still needs real art direction; enabling a pipeline does not produce cinematic quality. Editor automation must use appropriate supported access. | | **Unreal 5.8** | Strong candidate when high-end native cinematic presentation and integrated character/world/lighting workflows dominate. Its current release emphasizes worldbuilding, vegetation, lighting and performance capture. | Do not assume Windows flagship rendering features have equivalent Mac readiness or performance. Larger content/build/iteration costs must be measured locally. | | **Godot 4.7.2** | Strongest case when an open, inspectable engine and long-term ownership outweigh turnkey cinematic workflow breadth. It has straightforward command-line/headless workflows. | Expect the studio to own more of the camera, presentation, asset pipeline and visual regression integration. This is a workload estimate, not a claim that Godot cannot make a beautiful 3D game. | Sources: [Cinemachine](https://docs.unity3d.com/6000.3/Documentation/Manual/com.unity.cinemachine.html), [Timeline](https://docs.unity3d.com/6000.3/Documentation/Manual/com.unity.timeline.html), [Unreal 5.8](https://www.unrealengine.com/news/unreal-engine-5-8-is-now-available), [Godot ownership/license](https://github.com/godotengine/godot/blob/master/README.md), [Godot headless execution](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_dedicated_servers.html). ### The Mac check matters Epic's current macOS requirements mark software Lumen available on Apple Silicon M1+, hardware ray tracing/MegaLights on M2+ as **experimental**, and Nanite/Virtual Shadow Maps on M2+ as **beta**. Its UE5.8 toolchain table specifies macOS Sonoma 14.5 minimum, Xcode 26.0 minimum, and says Xcode 26.4 is incompatible. The page also contains a conflicting OS label in its general recommended-hardware section, so verify the exact version table against the installed toolchain before setup. [Epic macOS requirements](https://dev.epicgames.com/documentation/en-us/unreal-engine/macos-development-requirements-for-unreal-engine). **Practical conclusion:** an Unreal beauty prototype must show the Mac-supported production path, not only a Windows ray-traced showcase. Keep experimental features outside the minimum experience until proven. No local hardware benchmark was performed here. ### Unity renderer decision Start the comparison with **URP** if the desired look is atmospheric, art-directed realism: carefully authored materials, controlled indirect light, good shadows, restrained fog, wet surfaces, animation and sound. Unity documents URP as covering mobile through high-end consoles/PC. [URP overview](https://docs.unity3d.com/6000.3/Documentation/Manual/urp/urp-introduction.html). Because the user chose native first, HDRP is a legitimate alternative if the approved look demonstrably needs it; do not promise that URP and HDRP are interchangeable. Select **one** renderer after the room test. A later mobile edition is a separate quality/performance adaptation, not an excuse to weaken the first native slice or promise costless ports. ## Blender's role: authored source, repeatable publishing Blender is the modeling, material, rigging, animation and offline-rendering workbench. Its EEVEE/Cycles outputs can establish reference images; the selected game engine remains responsible for interactive frames. Blender supports these production disciplines and Python/command-line scripting. [Blender 5.2 manual](https://docs.blender.org/manual/en/5.2/index.html). Proposed publishing contract: 1. Keep the editable `.blend`, textures, references, license/consent evidence and generation provenance together under a stable asset ID. 2. Produce approved asset families: one human identity, one anatomy/scale guide, one material library, one lighting/color reference and reusable environment modules. 3. Export a frozen, tested interchange format appropriate to the selected engine/importer. Bake unsupported procedural materials or geometry; do not assume a Blender shader graph transfers intact. 4. Validate dimensions, origin/pivot, orientation, topology, UVs, texture color space, skeleton, animation contacts, collision and performance budgets on import. 5. Render the same asset under a neutral inspection light and the actual game light. An attractive Blender render is not in-game acceptance. 6. Keep originals immutable. Changes create new revisions, and an asset manifest records exactly what each shipped content pack used. Avoid direct production dependence on a changing generative service. A generated model is an incoming candidate until cleaned, rigged, lit, tested and accepted into this pipeline. ## AI and Unity: the current nuance Unity's AI tools remain **beta**. The current official page describes an in-editor assistant, AI gateway and MCP server. It says its MCP server is free, has no concurrency limits and consumes no Unity credits; third-party-agent gateway use also consumes no Unity credits. External model subscriptions and costs remain separate. The setup still requires Unity 6+, the package, relevant terms and a linked cloud project. [Unity AI tools](https://unity.com/features/ai). The June 30, 2026 Terms restrict automated/agentic interaction with Unity Offerings to authorized access and restrict training on Unity's Offerings/proprietary data. This should **not** be summarized as “you cannot use AI or RL on your game.” [Unity Terms, §17.2](https://unity.com/legal/terms-of-service). Unity Principal Advocate Mike Geig clarified in July that AI editing one's own files is fine, and that own-project RL/simulation/testing and synthetic data are permitted. Driving the Editor engages the access requirements. He explicitly called his posts informal clarification, and said in July that third-party restrictions would not be enforced until vetting; that is not proof of a blanket exemption in September. [Staff clarification, posts 9, 12 and 21](https://discussions.unity.com/t/new-terms-of-service-is-unity-restricting-local-ai-tools-and-ai-training/1724661). **Proposed implementation:** ordinary repository coding for owned source, documented CI build/test interfaces, and the official Unity MCP/gateway for direct agent control of the Editor. Keep training datasets limited to the studio's own game/materials and permitted assets. Verify chosen third-party integrations and beta click-through terms at adoption; do not state the beta is categorically production-approved or categorically forbidden. ## What makes a self-updating game technically viable These are proposed architecture requirements, independent of engine selection: - **Separate the simulation from presentation.** Persist semantic events such as `neighbor_helped`, `device_repaired` and `morning_advanced`; do not store an accidental arrangement of scene objects as the only truth. - **Deterministic where it matters.** Version the state schema, rules, random seed and event order. Keep ambient particles, cloth and cosmetic physics out of authoritative progression. A fixed frame rate alone is not a determinism contract. - **AI proposes; state logic validates.** Generated dialogue/world suggestions are bounded data, with stable IDs and validators. A runtime model cannot arbitrarily modify saves, economy rules or executable code. - **Version executable and content separately.** Retain engine/package lockfiles, content manifests, hashes, compatibility requirements and migrations. Download a complete compatible content pack, verify it, then activate atomically at a safe boundary. - **Make updates reversible.** Retain a known-good executable/content pair, backed-up saves and tested migration paths. Old clients must not consume incompatible new assets. A rollback of code alone may not reverse a migrated save. - **Use a build pipeline, not a cron script with production keys.** Scheduled jobs can collect evidence and create bounded proposals. Work happens in isolated branches/builds; release promotion consumes a reviewable artifact plus test evidence. - **Test the player-visible result.** Replays and state tests prove rules; screenshot routes, animation/audio inspection and frame-time captures prove presentation. Human playtests judge clarity, delight and whether the experience is worth sharing. Unity Addressables supports remote content updates and retaining the prior build's content-state file; engine/Addressables changes require a new player/content build. This is useful infrastructure, not permission for arbitrary executable hot-patching. [Addressables update workflow](https://docs.unity3d.com/Packages/com.unity.addressables@2.7/manual/content-update-builds-overview.html), [Build Automation integration](https://docs.unity.com/en-us/build-automation/advanced-build-configuration/build-addressables-using-build-automation). All three engines can participate in automation. Unity documents batch-mode/command-line workflows; Unreal provides Gauntlet session automation and screenshot comparison; Godot has headless export/runtime workflows. The studio still needs to implement its own acceptance scenarios. [Unity CLI](https://docs.unity3d.com/6000.3/Documentation/Manual/EditorCommandLineArguments.html), [Unreal Gauntlet](https://dev.epicgames.com/documentation/unreal-engine/gauntlet-automation-framework-overview-in-unreal-engine), [Unreal screenshot comparison](https://dev.epicgames.com/documentation/unreal-engine/screenshot-comparison-tool-in-unreal-engine?lang=en-US), [Godot headless](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_dedicated_servers.html). ## The bounded engine decision artifact Before expanding production, capture the same 60–90 second route in the two candidate engines, using the same assets and target hardware. Include free movement, an object inspection, a character exchange, rain/interior transition, save, quit and resume. Compare: - continuous beauty while moving, not just selected frames; - stable human identity and believable hands/contacts; - legibility and camera comfort during interaction; - frame-time distribution and visible stutters after warmup and on first traversal; - startup/build size, memory use, import/build time and change-to-preview time; - clean-machine reproducibility and one successful update/rollback rehearsal. Use an explicit target-device list and a proposed 60 fps quality target with a deliberate 30 fps fallback mode if needed. These are budgets to validate, not performance promises. Choose once the slice provides evidence; engine indecision should not become a parallel three-engine production. ## Optional later platforms Godot's current web documentation limits Godot 4 exports to WebGL2/Compatibility rendering and says C# projects cannot currently export to web. Unity 6.3 documents desktop/mobile browser support. These facts matter only if a browser edition becomes an approved goal; they do not require native visual parity with the browser now. [Godot web export](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html), [Unity web compatibility](https://docs.unity3d.com/6000.3/Documentation/Manual/webgl-browsercompatibility.html). Render.com is a hosting service, not the intended 3D creation tool. If online services are later needed, it offers APIs/workers/databases/scheduled jobs. Its cron jobs cannot access persistent disks. Persistent world state would belong in an explicit database/object store, not a cron job's filesystem. No hosting purchase or setup is part of this recommendation. [Render service types](https://render.com/docs/service-types), [cron jobs](https://render.com/docs/cronjobs).