Healthy Food Challenge Project Report
1. The Concept
Healthy Food Challenge is a lightweight, web-based educational game designed to help children learn the difference between healthy foods and less-healthy foods through short, visual mini-games. The core idea is simple: kids interact with food images, make quick choices, and receive immediate feedback.
I chose this project for the sprint because it is small enough to build quickly, but still complex enough to test real game design decisions: multiple screens, score tracking, image assets, animations, timers, drag-and-drop, and different play modes. It was also a good way to test how AI can help plan and build a child-friendly learning game instead of a normal business-style web app.
2. The Stack
The Stack: HTML5, Vanilla CSS, and JavaScript.
The project does not use React, Vue, Tailwind, Bootstrap, or any frontend framework. The game is built with separate files:
index.htmlfor the screen structurestyles.cssfor layout, visual design, responsive behavior, and animationsgame.jsfor game logic, scoring, timers, and interactionsassets/for UI images and food photos
The AI Assist: ChatGPT helped with early product planning, target user discussion, and design direction. OpenAI Codex was used for the development phase, including writing the HTML, CSS, JavaScript, creating the README, checking the project against the provided design rules, and improving bugs found during testing.
3. The 1 Day Sprint
Morning (Hours 1-3): We started by planning the app idea and target user. The original idea was a simple drag-and-drop food sorting game, but after reviewing the Sakurai-style game design notes, the plan became more focused: short sessions, instant feedback, clear player actions, and strong replay value. We chose children ages 7-9 as the main target users, with parents and teachers as secondary users.
During this stage, we also refined the language and tone. Instead of making the game feel like a strict nutrition test, we aimed for a clean school-app style with friendly feedback. The planning checklist helped clarify the reference apps, target user, reason to play, reason to continue, core value, and tester feedback goals.
Afternoon (Hours 4-6): The coding phase began. Codex built the first playable version using HTML, CSS, and JavaScript. The app started as a single-file prototype, then was split into index.html, styles.css, and game.js after the structure became larger.
The game expanded beyond the first sorting idea into multiple modes: Sort, Quiz, Open Box, Spin, Anagram, and Matching Pairs. Image assets were added for buttons, mode cards, icons, result screens, and food photos. The biggest focus during this phase was making the project feel more like a smartphone game than a plain web page.
The Finish Line (Hour 7-8): The final part of the sprint was bug fixing and polish. Several issues appeared during testing: some screens did not fit well on mobile, the Open Box mode did not scroll properly, and some interactions needed clearer animation. These were fixed by changing the Open Box layout to show 20 cards in a 4-column grid and adding pop, flip, shine, correct, and wrong animations.
We also created documentation files, including README.md and this project report. A final rules check was done against the provided rules/*.txt files to see how closely the project followed the required game UI direction.
4. The Roadblocks
Roadblocks: The biggest roadblock was balancing the project rules with the practical limits of a browser-based prototype. The rules required a commercial smartphone-game UI where buttons, icons, frames, and important UI elements should be image assets instead of simple CSS shapes. The project follows this direction in many places, but not perfectly.
Another issue was screen fitting. The design rules say each screen should fit inside a 9:16 mobile screen with no long vertical scrolling. However, some modes became more complex than expected, especially Open Box and Matching Pairs. The Open Box mode originally showed 20 cards in a way that cut off the bottom cards and did not scroll correctly. That required several layout changes before it became usable.
The third challenge was scope creep. The original MVP was only a drag-and-drop sorting game, but the project grew into six modes. This made the app more interesting, but it also made it harder to fully polish every screen within a one-day sprint.
5. Key Takeaways
What was the part that worked the best? The planning phase and fast prototyping. The AI was very useful for turning a simple educational idea into a clearer game concept with target users, replay reasons, and multiple playable modes. It also helped quickly generate the core files and connect the screens together.
What was the part that worked the worst? UI rule compliance and mobile layout polish. The project became playable quickly, but making every screen follow strict smartphone-game asset rules took more time than expected. Some UI elements are still CSS-based, such as progress counters, some card frames, and a few text buttons.
My final thought: If I had one more day, I would focus on making the project follow the UI asset rules more strictly. I would replace the remaining CSS-made UI parts with image assets, remove unnecessary scrolling, and polish each game mode one by one. If I could redo the sprint, I would keep the scope smaller at first: finish one or two modes perfectly before adding more mini-games.