Museum Heist Puzzle Project Report
1. The Concept
Museum Heist Puzzle is a lightweight, web-based 2D stealth logic game built for a mobile-first 9:16 screen. The player controls Kai, a clever young thief exploring a mysterious museum, rescuing cursed artifacts, avoiding guards, cameras, lasers, locked rooms, alarms, and using gadgets to escape.
I chose this game idea because it is more ambitious than a simple utility app but still possible as a focused web sprint. It tests several important areas at once: UI polish, responsive layout, canvas-based gameplay, level design, state management, onboarding, sound, and progression logic.
2. The Stack
The Stack: HTML5, Vanilla CSS, and Vanilla JavaScript.
The AI Assist: ChatGPT/Codex was used for both planning and development. The early planning phase defined the game concept, target user, chapters, story, gadgets, win ratings, and visual direction. Codex then handled the implementation phase: building the screens, generating and integrating assets, writing the gameplay logic, adding levels, adding sound, testing responsive layouts, debugging progression issues, and optimizing the final project.
3. The 1 Day Sprint
Morning (Hours 1-3): We started by planning the game identity and player experience. The original idea was a stealth puzzle game set inside a mysterious museum. We defined Kai as the protagonist, added an AI flashlight companion, chose a cartoon mystery style, and planned four chapters: Ancient Egypt, Khmer Gallery, Modern Art, and Gem Vault. The first target was a complete responsive web game, not just a static mockup.
Afternoon (Hours 4-6): The coding phase focused on building the 9:16 interface, home screen, level map, gameplay screen, settings, collection, gadgets, daily heist, pause, win, and lose screens. The biggest effort was making the UI feel premium instead of like a compressed web page. Gameplay systems were added step by step: grid movement, guard patrols, camera vision, lasers, locked doors, keys, gadgets, alarm, undo, restart, route planning, and 24 levels.
The Finish Line (Hour 7-8): The final phase was heavy polish and QA. We added real PNG/WebP assets, chapter-specific board art, sound effects, first-play guide, map ratings, contextual gameplay hints, and chapter-specific mechanics. We also cleaned the project by removing QA screenshots and unused files, converting large images to WebP, and shrinking the runtime project to under 4 MB excluding Git history.
4. The Roadblocks
Roadblocks: The hardest roadblock was visual quality. Early versions looked cramped, unbalanced, and too much like a generic web layout instead of a premium mobile game. The home screen, toolbar, buttons, and gameplay layout needed many polish passes before they felt acceptable.
The second major roadblock was gameplay logic. Several systems worked independently but created bad player experiences when combined. For example, guards originally felt like they moved because Kai moved, which made security feel unfair. Later, a serious progression bug appeared: Kai could lose but still press Next and unlock the next level. That had to be fixed by centralizing level-start permissions and hiding/disabling Next unless the result was a real win.
Another roadblock was asset management. The game required real assets, not CSS drawings or cropped screenshots. That made the project look better, but it also created many temporary QA images and large PNG files. A cleanup and optimization pass was needed to remove useless files and convert large backgrounds to WebP.
5. Key Takeaways
What worked best? The iterative QA loop. Every major upgrade was tested at mobile and desktop sizes, and bugs were caught quickly by checking screenshots, browser metrics, console errors, missing assets, and gameplay state. This helped the project move from rough prototype to polished playable build.
What worked worst? Trying to make a polished game UI with only HTML, CSS, vanilla JavaScript, and generated assets under tight time pressure. The gameplay logic could be implemented quickly, but making it feel premium, balanced, readable, and responsive took much longer than expected.
My final thought: If I had one more day, I would improve the level design depth even more. The next upgrades should be smarter guard AI, better chapter mechanics, richer win/reward animations, and a more cinematic final puzzle. If I could redo the project, I would separate the JavaScript earlier into smaller files like levels.js, audio.js, render.js, ui.js, and gameplay.js so the project would be easier to expand.