Skip to content

Latest commit

 

History

History
188 lines (155 loc) · 11 KB

File metadata and controls

188 lines (155 loc) · 11 KB

Squish World 3D — Unity Feasibility & Build Plan

Status: Draft v1. Companion doc to the original GAME_DESIGN_DOCUMENT.md in squish-world (Godot 4, 2D/2.5D, data-driven, developmental-stage design). This doc scopes a new, separate 3D prototype: Unity, iOS/iPadOS, Pokémon GO–flavored exploration with 3D Squish and 3D Lilyan.


1. TL;DR

Yes, this is buildable as a real "one level" vertical slice — a small 3D yard/meadow you walk around by tapping, with Squish following you and reacting to touch, and a couple of simple pickup/discovery interactions. It is not a weekend project, but it's very achievable as a focused side project, especially since you already have the character designs locked and you're comfortable shipping with AI-assisted coding (Claude Code).

Rough estimate for a solo dev, new to Unity/3D but experienced in software engineering generally, working part-time (evenings/weekends): 6–10 weeks to a polished, playable one-level vertical slice on a real iPhone/iPad.

The single biggest bottleneck isn't code — it's going from these 2D reference sheets to rigged, animated 3D models. That's where most of the calendar time goes.

2. Scoping "Pokémon GO style" (assumption made — flag if wrong)

"Pokémon GO style" can mean two very different things:

True AR (camera+GPS) 3D world exploration (what I'm scoping)
How it works Camera passthrough, real-world GPS anchoring, walk around outside A contained 3D scene (yard/meadow), tap-to-move like the Godot version, just in 3D
Engine complexity High — AR Foundation, ARKit world tracking, lighting estimation, occlusion Moderate — standard 3D game, well-trodden path
Fit for a toddler Poor — requires holding a phone up and walking around outdoors, no adult-supervised guardrails, motion sickness/safety concerns Good — same lap-play, no-fail-state, tap-to-move principles you already established
Build time for one level Add 3–5 weeks on top of everything below Baseline estimate below

I'm scoping this as the second one: a 3D world you explore by tapping to move (the "GO" feel — walking through a space, discovering things, companion at your side — without the AR/GPS machinery). This is consistent with the tap-to-move, no-fail-state, lap-play principles already locked into the Squish World design. True AR is listed as a Phase 2 stretch goal at the end — happy to scope it separately if that's actually what you want.

3. Engine: Unity vs. sticking with Godot 4

You already have a working Godot 4 repo (squish-world) with a data-driven content architecture. Unity is a legitimate, deliberate pivot — here's the honest trade-off:

Unity Godot 4 (existing repo)
3D tooling maturity Very mature — Cinemachine (camera), Timeline, Animator, huge Asset Store Capable 3D since Godot 4, smaller ecosystem, fewer character-animation shortcuts
iOS export First-class, well-documented, huge community Solid but smaller community for iOS-specific gotchas
Character pipeline (Mixamo etc.) Native, battle-tested workflow (see §5) Works, but more manual rig/import wrangling
Pricing Unity Personal is free under $200k revenue/funding, unlimited seats as of 2026, no more runtime fee (killed in 2024) Free, MIT license, no revenue threshold ever
Reuse of existing repo None — new project Full reuse of data schemas, dialogue system, progression design
Learning curve C#, new editor, new mental model You already have muscle memory from the existing repo

Recommendation: Unity is a fine choice and matches what you asked for — it's genuinely the stronger engine for this specific asset pipeline (Mixamo integration alone saves real weeks). Just go in eyes-open that it's a fresh project, not an extension of squish-world. The design philosophy (data-driven content, no-fail states, tap-to-move, growth-loop unlocks) carries over conceptually even though the code doesn't.

4. Subsystem-by-subsystem difficulty breakdown

Subsystem Difficulty Est. time (solo, new to Unity) Notes
Project setup, Xcode/TestFlight pipeline Easy 2–4 days One-time cost; Apple Developer account ($99/yr) needed for on-device testing beyond 7-day free provisioning
2D reference → 3D character models Hard — the bottleneck 2–4 weeks total (both characters) See §5
Rigging & animation Medium (Lilyan), Easy (Squish) Included above Mixamo solves 90% of this for Lilyan
Player movement + camera (tap-to-move, 3rd-person follow cam) Medium 3–5 days Cinemachine makes the camera part easy; NavMesh Agent handles pathing
Squish companion AI (follows Lilyan, reacts to tap) Medium 3–5 days Simple state machine: Idle → Follow → React
One environment/level (meadow/yard) Medium 1–2 weeks Depends on whether you build it from scratch in Blender or use stylized asset packs + retexture
Interactions (tap Squish for reaction, tap object to collect/discover) Easy–Medium 3–5 days Reuse the "no fail state, delight-first" pattern from the GDD
Toddler-appropriate UI (big touch targets, minimal text/menus) Easy 2–3 days You've already solved this design problem once
Audio, polish, lighting pass Medium 1 week URP mobile lighting + a handful of SFX
Device testing/perf tuning (iPhone + iPad, thermal/battery) Medium 3–5 days Mobile 3D perf tuning is real but well-documented

Total: ~6–10 weeks part-time, front-loaded by the character pipeline.

5. The real bottleneck: 2D sheets → game-ready 3D models

You have two very different character types, and they need different pipelines:

Squish (simple rounded-cube blob, no complex anatomy)

  • Good candidate for AI image-to-3D generation (Meshy, Tripo3D, Rodin) using your turnaround sheet (front/back/left/right/top/bottom) as multi-view reference — this is exactly the kind of simple, symmetric, soft-body shape those tools handle well.
  • Clean up topology and re-rig by hand in Blender (a squash/stretch bone rig is enough — Squish doesn't need a humanoid skeleton).
  • Realistic estimate: 1–2 weeks including cleanup, if the AI-generated base mesh is usable, worse if you end up modeling from scratch.

Lilyan (stylized human child, expressive face, clothing, hair)

  • Much harder for current image-to-3D AI tools — faces and hands are where they still struggle most, and a discrepancy here is exactly the kind of thing kids notice.
  • Realistic path: model in Blender referencing your "Project Lilyan" sheet directly (or commission a low-poly stylized character — there's a healthy market of freelance modelers who do exactly this "chibi mobile game character" style), then auto-rig and animate via Mixamo (upload your mesh → Mixamo auto-rigs it → drag-and-drop walk/idle/wave/react animations, FBX-for-Unity export, done in minutes per animation).
  • Realistic estimate: 2–3 weeks if modeled by hand, faster if you commission the base mesh and just handle Mixamo integration yourself.

Either way, Mixamo + Unity's Humanoid animation rig is the unlock — it turns "rig and animate a walk cycle" from a multi-week animation problem into an afternoon of importing FBX files.

6. Recommended stack

  • Unity 6 LTS, Universal Render Pipeline (URP) — built for mobile, good default for stylized/toon-ish look which matches your art direction.
  • Cinemachine for the follow camera (standard for exactly this third-person exploration genre).
  • NavMesh + NavMeshAgent for tap-to-move pathing (walks around obstacles automatically — same "tap-to-move" UX you already committed to).
  • Mixamo for Lilyan's rig + animation library (walk, idle, wave, sit, react) — free, Adobe account only.
  • Blender for model cleanup/retopology, whichever pipeline you use for the raw meshes.
  • C# — the only real new-skill cost here if you haven't used it before; straightforward for someone with your engineering background.
  • Xcode + TestFlight for on-device iPhone/iPad testing with your daughter without going through the App Store.

7. Phased plan

  1. Week 0 — Setup: Unity project, Git repo, Apple Developer account, confirm you can build-and-run an empty scene on your daughter's/your iPad over TestFlight. De-risks the whole pipeline early.
  2. Weeks 1–4 — Character pipeline: Get Squish and Lilyan into Unity as rigged, animated (idle + walk minimum), Humanoid-type characters. This is the make-or-break phase — everything else is comparatively easy once this is done.
  3. Weeks 3–5 (overlapping) — Movement & camera: Tap-to-move for Lilyan, Cinemachine follow cam, Squish's follow-AI state machine.
  4. Weeks 5–7 — The level: Build the one meadow/yard environment, populate with 2–3 simple interactions (tap Squish → reaction animation + sound; tap a flower/object → discovery pop-up, reusing the "delight, no fail state" pattern).
  5. Weeks 7–9 — Polish & test: Lighting pass, audio, UI cleanup, real playtesting with your daughter on an actual device, perf/battery check.
  6. Week 9–10 — Buffer: There's always a buffer.

8. What carries over from the Godot project

  • The developmental-stage philosophy (no fail states, delight-first, lap-play at the youngest stage, tap-to-move not joystick) — all directly applicable in 3D.
  • The data-driven content mindset — even in Unity, keep dialogue/interaction definitions in JSON/ScriptableObjects rather than hardcoded, so adding a new interaction later doesn't mean touching engine code.
  • Squish's character voice/personality from the board book — free continuity between the two projects.

The Godot repo doesn't get thrown away — it's a separate, still-valid track if you ever want the broader multi-stage platform vision from the original GDD. This Unity project is best framed as a focused 3D vertical-slice prototype, not a replacement.

9. Open questions worth nailing down before you start building

  • Interactions: what does "basic interactions" mean concretely for v1 — touch Squish for a reaction, collect 2–3 items, follow-the-leader? Pin down 2–3 specific interactions now; it bounds the level-design scope.
  • Devices: iPhone only, or iPhone + iPad both at launch? (Different aspect ratios/UI scaling — cheap to handle if planned for from day one, annoying to retrofit.)
  • Offline/local-first: keep the no-backend, privacy-first approach from the original GDD? (Recommend yes — no reason to change that for a 3D version.)

10. Stretch goal — true AR (Phase 2, not in this estimate)

If you do eventually want the literal "walk around your yard and Squish is really there" AR experience: AR Foundation (Unity's cross-platform AR layer over ARKit) is the path, and your existing 3D-rigged Squish/Lilyan models drop straight in — the character pipeline work above isn't wasted. Budget this as its own multi-week phase after the core 3D game is solid, not as part of the initial build.