--- title: "Brick Scene Game Scanner" date: "2026-07-16" canonical: "https://raytally.com/en/ideas/2026-07-16-voxatron/" generator: "RayTally · dev-prompt-v4" signal: query: "Voxatron" observed_at: "2026-07-16T00:33:37.151Z" sources: - url: "https://news.ycombinator.com/item?id=48926053" boundary: "Published at 2026-07-15. Observed at 2026-07-16T00:33:37.151Z." - url: "https://developer.apple.com/videos/play/wwdc2023/10191/" boundary: "No publication timestamp is present in the source record." - url: "https://dev.epicgames.com/documentation/realityscan-mobile/realityscan-documentation?lang=en-US" boundary: "No publication timestamp is present in the source record." - url: "https://brickit.app/" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-16-voxatron/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea Brick Scene Game Scanner Turns a walk-around capture of a brick model into a destructible voxel level that users can set rules for and play immediately. ## Product concept Brick Scene Game Scanner is a mobile app for families and indie creators that turns tabletop brick models into destructible voxel levels. Users walk around a castle, spaceship, or maze and capture it from all sides; the first screen shows a walkable 3D scene and flags areas with unstable recognition that need another pass. They can then assign a few bricks as a door, enemy spawn point, or explosive and immediately test the level to see whether collapses and paths work as expected. After changing the model, they only need to rescan the affected area, while the app keeps the rules already set. It does not replace professional modeling; it turns a physical draft that children and designers have already built into a first playable level. ## Why now (backed by facts) On July 15, 2026, Voxatron returned to Hacker News; in the signal snapshot observed at July 16, 2026, 00:33 UTC, the post had 52 points, 16 comments, and ranked 17th, refocusing discussion on destructible voxel worlds and user-made games. Apple already provides walk-around capture guidance, missing-area prompts, and on-device 3D reconstruction in iOS, so the hardest scanning step in turning a physical model into a playable prototype can start from existing platform capabilities. ## Direction (model inference, not independently verified) Target user: Children or parents who have just built a castle, spaceship, or maze and want to turn it into a game right away. Indie creators can use it when a paper level is not worth formal modeling yet, but they need to test paths and destruction. Minimal entry point: Limit the first version to iOS and one tabletop model. Use RealityKit Object Capture for guided capture and 3D reconstruction, support only door, spawn point, and explosive markers after voxelization, then test whether a local rescan can retain rule anchors. The strongest case against: The strongest case against this is that scan stability may fail: bricks often have repeated studs, smooth reflective surfaces, and heavy occlusion. If local reconstruction drifts, existing doors, spawn points, and explosives will be hard to keep reliably in place. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) Record short before-and-after videos of a scanned tabletop castle collapsing, with a link to play the level. Share them in TikTok, YouTube, Reddit, and Discord communities used by brick MOC, voxel-game, and indie-game creators. The process itself is the demo, so no content media needs to be built first. ## Competitors & gaps (model inference) - RealityScan Mobile: RealityScan Mobile can generate high-fidelity 3D models with a phone, but stops at general scan outputs. It does not turn models into destructible levels or manage the link between game rules and local rescans. - Brickit: Brickit identifies loose bricks and recommends builds, serving the question of what can be built from available parts. This product focuses on digitizing completed models, placing rules, and testing them immediately. ## How it makes money (model inference) Offer one project free, then charge a monthly subscription for multiple projects, local rescan history, and shareable level exports. ## Source context Theme: Voxatron voxel game engine Trigger Hacker News post (original English): Voxatron Heat at capture: ~52 points, 16 comments (point-in-time values) Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers. ## Sources - Voxatron (https://news.ycombinator.com/item?id=48926053) - Meet Object Capture for iOS (https://developer.apple.com/videos/play/wwdc2023/10191/) - RealityScan Mobile Documentation (https://dev.epicgames.com/documentation/realityscan-mobile/realityscan-documentation?lang=en-US) - Brickit — Build new creations from your good old bricks (https://brickit.app/) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.