Desk Defense 2D Project Report
1. The Concept
Desk Defense 2D is a lightweight, web-based tower-defense style game where the player protects an expensive desk setup from cute crawling baby chaos. The desk, mechanical keyboard, dual monitors, tablet, mouse, and other tech gear act as the base. Babies crawl down the lanes, and the player uses baby gates, snack bowls, and plush toys to delay or stop them before they reach the desk safety line.
I chose this game idea because it has a funny, meme-friendly concept that is easy to understand quickly. It also gave the sprint a good mix of product planning, game logic, UI design, asset generation, animation, sound, and playtesting.
2. The Stack
The Stack: HTML5 Canvas, Vanilla CSS, and JavaScript.
The project is built as a single-page browser game with no framework and no build step. The main game code lives in index.html, while generated PNG artwork is stored in the assets folder. The game also uses the browser Web Audio API for sound effects, so no separate audio files are required.
The AI Assist: ChatGPT helped shape the initial concept, target user, and design direction. OpenAI Codex was then used for the coding phase, gameplay implementation, asset integration, animation work, sound effects, README writing, and project reporting.
3. The 1 Day Sprint
Morning (Hours 1-3): We started by reading the project notes, design rules, and Sakurai-inspired game content. The first goal was to turn the rough idea into a clear web game direction. The concept became a funny casual defense game for tech people and parents: protect your pristine desk setup from toddlers with sticky fingers, crayons, drool, and snacks.
Afternoon (Hours 4-6): The coding phase started with a simple canvas game. The first version had a title screen, gameplay screen, babies, defenses, waves, and basic interactions. After that, the focus shifted heavily toward matching the provided reference images. We replaced early placeholder drawing with generated bitmap assets, added premium cartoon PNG sprites, and rebuilt the gameplay screen around real artwork instead of simple canvas shapes. This phase also introduced the 20-level structure, lane patterns, defense costs, calm points, desk health, and boss-level progression.
The Finish Line (Hour 7-8): The final phase was polish and QA. We added a level unlock popup, sound effects, title screen animation, working feature buttons, cleaner button feedback, smoother crawling motion for enemies, and stronger wave/level-clear transitions. We also fixed layout problems where text overflowed inside small gameplay panels. The final sprint ended with documentation: a README and this project report.
4. The Roadblocks
Roadblocks: The biggest roadblock was visual accuracy. The user wanted the UI to closely match reference images, but also wanted the game to be functional, animated, and built with real image assets instead of placeholder shapes. Balancing a static high-quality reference image with live gameplay was difficult.
Another roadblock was asset quality and integration. The game needed babies, props, UI icons, defenses, and hardware objects in a consistent premium cartoon style. Generated image sheets had to be copied into the project, converted to transparent PNGs, sliced into individual assets, then wired back into the canvas renderer.
The last major roadblock was text layout. The gameplay UI uses small mobile-game panels, so fixed-size text easily overflowed. We had to add fit-to-box text helpers and tune the HUD so labels stayed centered and readable.
Another late-stage roadblock was animation polish. The first title animation pass made the START and HOW TO PLAY buttons feel like they had extra translucent boxes around them. We had to reduce the animation to internal shine and subtle highlights so the buttons still matched the reference design.
5. Key Takeaways
What worked the best? The concept and visual direction. Desk Defense 2D has a clear joke, a clear target audience, and a gameplay loop that matches the theme. The generated art also helped the game feel much more like a real casual mobile game instead of a prototype.
What worked the worst? Matching a static reference while adding real gameplay. A reference image can look perfect as a mockup, but when enemies move, buttons work, panels update, levels unlock, sounds play, and transitions animate, the UI needs extra structure that the image does not provide. That made alignment, hitboxes, text sizing, animation polish, and gameplay balance slower than expected.
My final thought: If I had one more day, I would add true multi-frame crawling sprite sheets, more enemy types, and a better upgrade system with meaningful choices between waves. If I could redo this project, I would generate the artwork as separate production-ready assets from the beginning instead of first building around static reference screenshots.