OrigamiVerse — One origami engine, two Android apps

Inspiration

Skeleton Crew asks for a skeleton that is lean enough to be clear and flexible enough for more than one use. Origami is a good test of that idea: the same crease pattern, hinge and paper simulation can be a puzzle world you walk across, or a studio where you design and export a fold. We wanted both, from one core, running on a mid-range phone, fully offline.

What it does

OrigamiVerse Core is a Godot 4 addon. It loads FOLD 1.2 files, planarizes crease patterns, runs a rigid hinge solver and a compliant XPBD bar-and-hinge simulator, renders the paper, and provides timeline, undo, atomic saves, FOLD/OBJ/GLB export, gestures, camera, surface navigation, synthesized paper audio and a small UI kit. The core never references an app.

Two different Android applications are built from that foundation, in two separate repository folders:

Everything you see folding is computed live, never a prerecorded animation. Both apps are offline: no account, no server, no ads, no analytics. Saves stay in app-private storage.

How we built it

• Godot 4.7 and GDScript, one shared addon plus two standalone app projects. A tools/sync_core.py copy-and-drift-check keeps each app's addons/origamiverse_core/ identical to shared-core/addons/origamiverse_core/.
• Phone-friendly physics: the compliant solver is Origami Simulator's bar-and-hinge model reformulated as XPBD, about 12 iterations per frame on a mid-range CPU, with an OpenGL ES 3 fallback (no compute shaders).
• Tests: headless core tests (solvers, FOLD IO, rendering, timeline, undo, saves, navigation, audio, gestures), FoldShift level proofs (every level is solved by a BFS solver; par is the solver's minimum fold count), and PaperVerse template fold/round-trip checks.
• Android: signed APK and AAB via tools/build_android.ps1. Keystores are not in git. All 3D props are generated in Blender at build time; no third-party meshes ship in the APKs. Paper sounds are synthesized at runtime.

How Kiro was used

The project was built spec-first with Kiro. Everything Kiro used lives in .kiro/ and is committed (it is not in .gitignore).

• Specs (.kiro/specs/): origamiverse-core, foldshift and paperverse, each with EARS-style requirements.md, design.md and tasks.md. The core spec came first, so both app specs build on its classes.
• Steering (.kiro/steering/): product.md, tech.md and structure.md — product non-negotiables, toolchain and performance rules, and the repository layout.
• Hooks (.kiro/hooks/): sync the core when a core file is saved, run the core tests after core changes, and re-run the FoldShift level proofs when levels change.

A longer account is in docs/kiro-usage.md. This write-up claims only the specs, steering and hooks that are in the repo.

Challenges we ran into

• One simulator had to feel good both as a puzzle mechanism and as a freeform studio tool, without the core knowing about either app.
• Keeping a continuously simulated sheet of paper inside a phone frame budget, including dynamic 3D resolution and sleeping the solver when the paper is still.
• Rigid-foldable patterns vs. patterns that need a compliant solver, and explaining that difference in PaperVerse instead of failing silently.
• Making every FoldShift par a proof, not a guess: the automated BFS solver is part of the test suite.

Accomplishments that we're proud of

• A reusable origami core with two genuinely different products on top, in the two folders the Skeleton Crew rules ask for.
• Live folding on a mid-range Android phone, with no prerecorded animation.
• Solver-proven FoldShift levels, and a documented path to add a third app (docs/reusability.md).
• A Kiro process that is visible in the repo: three specs, three steering files, three hooks.

What we learned

A core that never imports an app is easier to keep honest than a "shared" folder that slowly fills with game code. Steering and hooks mattered as much as the spec: the sync-and-test hooks caught drift before a release build did. Device QA still found things unit tests could not, such as a solver that never slept on some templates, and a camera that clipped tall folded bases.

What's next for OrigamiVerse

Play Store releases of the signed AABs, more FoldShift chapters, and more PaperVerse templates that the solvers can actually fold. We will not add accounts or cloud sync.

Links and known limits today: the public GitHub Release with the signed APKs is live at https://github.com/fareza777/origamiverse-kiro/releases/tag/v1.0.0 (FoldShift: https://github.com/fareza777/origamiverse-kiro/releases/download/v1.0.0/FoldShift-1.0.0.apk, PaperVerse: https://github.com/fareza777/origamiverse-kiro/releases/download/v1.0.0/PaperVerse-1.0.0.apk). The release APKs were built from current main on 12 November 2026; the on-disk AABs are older (10 November 2026) and should be rebuilt before a Play upload. The 1080p demonstration video (filmed on a Redmi Note 11) is on YouTube: https://youtu.be/vn2RSiNDK4c. The phone cannot AVC-encode a full 1080×2400 screenrecord, so the footage is a 720×1280 screenrecord (content cropped from 9:16 letterbox to the phone's 9:20 picture, then pillarboxed). Scrcpy was used to try to capture app audio and recorded only silence, so the cut is voice-over only; paper sounds are synthesized by the apps but are not in this video. FoldShift 1-3 is shown only as the Continue pointer, not completed. PaperVerse's status and navigation bars stay visible because that app is not immersive.

Built With

• android
• blender
• fold
• gdscript
• godot
• kiro
• origami
• powershell
• xpbd