SOVANN / App

Whack-A-Mole

1. The Hook & The Concept

6/25/2026Views: 0Launches: 0
Back to indexLaunch app
  1. The Hook & The Concept

For this one-day sprint, we built a responsive Whack-A-Mole browser game using only HTML, CSS, and JavaScript. The app is a casual arcade-style game where players tap moles as they appear, avoid bomb moles, collect bonus points from golden moles, and try to beat their saved high score before the timer runs out.

The game is for anyone who wants a quick, lightweight, playful experience in the browser. We chose Whack-A-Mole because it is simple enough to complete in a one-day sprint, but still has enough interaction to test real product details: game state, timing, scoring, responsive layout, animation, sound, and polish.

The goal was not just to make something that technically works. The goal was to see how far AI-assisted development could take a small game from idea to playable product in a single focused day.

  1. The Tech Stack & AI Co-Pilots

#

The Stack

The full app lives in a single index.html file. This made the project simple to run, easy to inspect, and fast to iterate on.

#

The AI Assist

This workflow felt like pairing with a fast frontend engineer: the human gave taste and direction, while the AI handled implementation and iteration.

  1. The 1 Day Sprint: How It Went Down

#

Morning: Hours 1-2

The idea started with a simple target: build a small playable browser game in one day. Whack-A-Mole was a good fit because the rules are familiar, the interaction is easy to understand, and the visual direction can be playful without needing a large asset pipeline.

The first setup was intentionally minimal. Instead of creating a framework project, we kept everything in a single HTML file. That helped us move quickly and avoid spending time on tooling. The first version included the game board, mole holes, basic score tracking, timer logic, and start/game-over flow.

#

Afternoon: Hours 3-6

Most of the afternoon was spent iterating with AI on the real product feel.

The game evolved from a basic board into a polished arcade UI. We added:

The biggest part of the work was not the core game logic. It was visual tuning. We compared the layout against reference screenshots and adjusted spacing, board size, HUD positions, title placement, and mobile behavior. This required multiple rounds of testing in the browser.

#

The Finish Line: Hours 7-8

The final stage was polish and documentation. We refined the mobile layout so the HUD cards no longer overlapped, moved the board into a better position on narrow screens, and added clean spacing between the board and the legend.

We also added a README.md with setup instructions, game rules, feature overview, and customization notes. Finally, this report was written as the first blog-style summary of the sprint.

  1. The AI Plot Twist: Roadblocks & Pivots

The biggest roadblock was responsive layout. The desktop design looked good first, but the mobile version broke badly: the title was too large, HUD cards overlapped, and the board was pushed too far down the screen.

The fix was to stop treating mobile as a smaller desktop layout. We added dedicated mobile CSS rules so each section had its own space:

Another roadblock was precision. Some user requests were simply “add space like the image.” That sounds small, but spacing is visual and relative. The AI had to repeatedly measure the layout in the browser, compare element positions, and adjust CSS carefully. The first attempts sometimes changed too much or solved one spacing issue while creating another.

Sound also required care. Browser autoplay rules mean audio cannot start automatically. The solution was to initialize sound only after user interaction, then route all effects through a master gain with a mute button.

We did not add external art assets or a full build system because the one-day sprint favored speed and simplicity. That was the right tradeoff for this app.

  1. Key Takeaways & Lessons Learned

#

What Worked Best

The AI worked best when the request was specific and visual:

> “Add more space between the Score button and the green area.”

That kind of request produced a clear, focused change. The AI could inspect the current CSS, measure the gap, adjust one layout value, and verify the result.

The AI was also strong at turning small features into complete implementations. For example, “add sound” became sound effects, background music, a mute button, saved sound preference, and browser-safe audio behavior.

#

What Worked Worst

The hardest requests were broad visual requests without exact constraints:

> “Responsive not good please update.”

The result can still be good, but it requires more interpretation. The AI has to decide what “good” means: no overlap, better spacing, better hierarchy, readable text, board visibility, and mobile ergonomics. This works better when paired with a screenshot, which we had, but it still takes several rounds.

Another challenge was that visual design changes can accidentally affect other screen sizes. A spacing fix for desktop can make mobile worse unless the responsive rules are handled separately.

#

Final Thought

If we had one more day, I would add a proper difficulty system with levels, combo scoring, and a small settings panel for sound and speed. I would also split the code into separate files: index.html, styles.css, and game.js. For a one-day sprint, a single file was fast and practical. For a longer project, separating concerns would make the app easier to maintain.

If I could redo the app, I would start with responsive layout earlier. The gameplay came together quickly, but the UI needed more careful planning across desktop and mobile. The biggest lesson is that AI can build fast, but the best results still come from human taste, clear feedback, and tight iteration.

Overall, this sprint showed that AI-driven development is very effective for small interactive apps. The AI handled the implementation speed, while the human guided the product quality.