SOVANN / Puzzle

Word Shuffle

1. The Hook & The Concept

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

In one day, we built Word Shuffle, a browser-based word puzzle game where players arrange scrambled letters into the correct English word. The game is simple: look at the letter tiles, tap them in the right order, win the level, and move to the next word.

The app is designed for casual players, beginners learning English words, and anyone who enjoys quick mobile-friendly puzzle games. We chose this idea for a one-day sprint because it had the right balance: small enough to finish in a day, but rich enough to include real gameplay, scoring, popups, settings, sound, and UI polish.

The goal was not just to create a basic demo. The goal was to see how far an AI-assisted workflow could take a small game idea in a single focused build session.

  1. The Tech Stack & AI Co-Pilots

#

The Stack

This stack was chosen because the app needed to be easy to open, easy to share, and easy for beginners to modify. The game can run directly in a browser without installation.

#

The AI Assist

The main AI assistant used for the build was Codex.

Codex handled:

The human role was very important too: the user provided direction, screenshots, design corrections, and feature requests. The AI did the coding, but the product shape came from the user’s feedback.

  1. The 2 Day Sprint: How It Went Down

#

Morning (Hours 1-3): Idea, Scope, and First Build

The sprint started with a Markdown handoff document describing the idea: a simple English word shuffle game. The initial scope was clear:

The first implementation focused on making the game playable. Codex created a complete index.html file with word data, game state, rendering functions, letter selection, answer checking, score logic, high score saving, and restart behavior.

At this stage, the UI was clean and functional, but it still looked like a standard web card interface rather than a game.

#

Afternoon (Hours 4-6): Game UI, Popups, and Iteration

The next phase focused on transforming the app into something that looked closer to a mobile puzzle game. The user provided reference screenshots with a wooden game board, top HUD, score pill, letter tiles, and rounded controls.

Codex updated the interface step by step:

This phase involved a lot of visual iteration. Several details changed based on feedback:

After the main game screen felt right, the result flow was added:

#

The Finish Line (Hours 7-8): Settings, Audio, and Documentation

The final stretch added polish and supporting features.

A settings popup was added when the player clicks the gear icon beside the level label. The popup includes:

Then sound was added using the browser Web Audio API. No external audio files were needed. The app now has generated sounds for:

Music was also added as a simple looping melody. Both sound settings are saved in the browser.

Finally, a README.md was written to explain the project, features, installation, and how to play. The app was not pushed to GitHub during this sprint, but it was prepared as a clean local project that can be shared or committed later.

  1. The AI Plot Twist: Roadblocks & Pivots

The biggest roadblock was not the game logic. The hardest part was visual precision.

The AI could build a working version quickly, but matching the exact design from screenshots required many small corrections. For example:

Another pivot was audio. At first, the settings popup only toggled values. Later, the user asked to add real sound effects and music, so Codex implemented generated browser audio using JavaScript instead of adding audio files.

There was also a tooling limitation: direct file:// preview was blocked in the browser automation environment, so testing used a temporary local server when needed. The final app still works by opening index.html directly in a browser.

  1. Key Takeaways & Lessons Learned

#

What Worked Best

The best part of the AI-driven workflow was speed.

Requests like “create the game,” “add win popup,” “add settings popup,” and “write README” produced strong results quickly. Codex was especially useful for:

The workflow worked best when the user gave clear, specific instructions with screenshots. Visual references made the iteration much more accurate.

#

What Worked Worst

The weakest part was exact visual matching.

When the request was broad, the AI made reasonable design choices, but they were not always the choices the user wanted. For example, the AI added icons, decorations, and button layouts that later needed to be changed. The lesson is clear: for UI-heavy tasks, screenshots and precise feedback are extremely important.

Audio was another area where expectations needed to be clarified. A settings toggle alone is not the same as real sound. The feature became complete only after the user explicitly asked for sound effects and music.

#

Final Thought

If we had one more day, the next improvements would be:

If we restarted the project, the main change would be to define the visual style earlier. The game logic was easy to build quickly, but the UI took many rounds of refinement. Starting with a clear design reference from the beginning would make the one-day sprint smoother.

Overall, this sprint showed that AI can build a complete small game very quickly, especially when the human provides strong product direction and fast feedback. The AI was not just a code generator; it acted like a rapid implementation partner that could turn each correction into a working update.

  1. The 1 Day Sprint: How It Went Down

#

Morning: Hours 1-3

The day started with a handoff file, markdown.md, that described a basic Tic Tac Toe game. The original requirement was simple: two players on the same device, a 3x3 board, a scoreboard, reset behavior, and winner detection.

The setup was intentionally light. There was no framework decision, no dependency installation, and no project scaffolding. The only real target was:

``text index.html ``

That constraint helped keep the project focused. Instead of spending time configuring tools, we could immediately build the game interface and logic.

The first version included:

#

Afternoon: Hours 4-6

The project direction changed from two-player mode to Player vs AI. This was the most important pivot of the day.

The app was updated so:

The AI logic was kept beginner-friendly but useful. It follows a simple priority order:

  1. Win if it has a winning move.
  2. Block the human if the human is about to win.
  3. Take the center if available.
  4. Take a corner if available.
  5. Take a side cell if needed.

This was enough to make the app feel like a real Player vs AI game without turning the project into a complex AI experiment.

After that, the user requested a more polished round-ending experience. Instead of only changing the status text, the app now shows a popup when the round ends:

** when the board fills with no winner

The popup includes two actions:

#

The Finish Line: Hours 7-8

The final part of the sprint was polish and verification.

The UI was cleaned up so the labels matched the game mode:

The result modal was styled to feel like part of the app instead of a browser alert. The README was also written so someone else can understand the project, run it, and play it without needing extra explanation.

Testing covered:

The project was not pushed to GitHub during this workspace session, but it is structured and documented so it is ready to be committed.

  1. The AI Plot Twist: Roadblocks & Pivots

The biggest pivot was changing the project from local two-player gameplay to Player vs AI. This affected the game logic, the status text, the scoreboard labels, and the documentation.

There were also a few practical roadblocks:

The AI did not create a bizarre visual bug, but it did need careful checking around game state. The difference between Resume and New Game was especially important:

That behavior had to be tested directly, not just assumed from the code.

  1. Key Takeaways & Lessons Learned

The best part of AI-driven development was how quickly a feature request could become a working interaction. Clear requests produced strong results. For example, the request for a result popup with Resume and New Game mapped directly into a clean modal, score handling, and browser tests.

The part that worked worst was ambiguity. A short request like “the player is AI and player(human)” was understandable, but it needed interpretation. Did it mean update only the documentation, or also change the actual app behavior? In this sprint, the better decision was to update both, because the product direction had clearly shifted to Player vs AI.

The biggest lesson is that AI works best when the human gives product intent and then reviews behavior, not just code. The app improved because each request clarified the user experience:

If we had one more day, the next improvements would be:

If we could redo the app, the main change would be to decide the Player vs AI direction at the very beginning. The first two-player version was useful as a foundation, but starting with AI mode from the first plan would have made the state design cleaner.

Overall, this was a good example of a one-day AI-assisted build: small scope, fast iteration, honest testing, and a final result that is simple enough to understand but complete enough to use.