Magical Kingdoms Project Report
1. The Concept
Magical Kingdoms is a lightweight, web-based fantasy RPG prototype designed as a premium 9:16 mobile game experience. The concept is an enchanting adventure game where players guide Aria through magical realms, fight mystical enemies, collect rewards, train pets, upgrade spells, and unlock new levels.
I chose this project for the sprint because it was more demanding than a static landing page or simple tool. It tested whether a web prototype could feel like a real mobile RPG using only HTML5, CSS, and vanilla JavaScript, while still keeping separate image assets, responsive layout rules, gameplay logic, HUD systems, and progression flow.
2. The Stack
The Stack: HTML5, Vanilla CSS, and JavaScript.
The game uses separate PNG/WebP-style visual assets for backgrounds, characters, enemies, bosses, pets, spells, HUD frames, buttons, icons, and effects. The gameplay is built directly in the DOM with JavaScript-driven state, collision checks, cooldowns, hit reactions, damage numbers, particles, camera shake, and simple Web Audio feedback.
The AI Assist: ChatGPT helped shape the initial Magical Kingdoms game concept and feature direction. OpenAI Codex was then used for the coding phase, rebuilding the project into a playable browser game with home screen, level selection, combat, upgrades, rewards, victory/defeat flow, and responsive testing.
3. The 1 Day Sprint:
Morning (Hours 1-3): We started with the fantasy RPG concept and reference screens. The first goal was to match the premium magical kingdom visual direction: a full-screen home map, Aria as the main character, pets, spell crafting, quests, and an adventure loop. Early work focused on building the basic structure: home screen, level select, battle screen, HUD, spell buttons, pets, enemies, and boss encounters.
Afternoon (Hours 4-6): The first playable versions had major layout and polish problems. UI elements overlapped, text was too small, buttons redirected incorrectly, and some images looked pasted, cropped, or broken. The gameplay also felt too static. We spent this phase rebuilding the logic into a real game flow: player movement, enemy chasing, boss attack patterns, spell cooldowns, pet assists, hit detection, damage numbers, potions, dodge, combo, timer, rewards, and three playable levels.
The Finish Line (Hour 7-8): The final stretch focused heavily on visual QA and responsive fixes. Popups were rebuilt so text stayed inside ornate panel artwork. The home screen was adjusted for mobile and desktop. A first-play guide was added for new users. The PC layout broke when the stage was forced to full viewport, so it was fixed with a centered 9:16 stage on desktop and full-screen behavior on mobile. Final testing was run at 360x800, 390x844, 430x932, 1366x768, and 1920x831.
4. The Roadblocks
Roadblocks: The biggest roadblock was visual consistency. Fantasy RPG UI depends heavily on image composition, spacing, scale, and readable hierarchy. Early builds had assets that looked cropped or stretched, popup text that did not match the panel artwork, and controls that covered the gameplay area.
Another major issue was responsive behavior. A fix that worked on mobile caused the PC version to stretch the whole game across a wide screen, breaking the 9:16 composition. The final solution was to treat the game as a mobile-first stage: full viewport on mobile, but centered and constrained to a 9:16 frame on desktop.
Gameplay balance was also difficult. The game needed to feel active without becoming unreadable. Enemies, boss attacks, spell effects, pet attacks, damage numbers, and HUD feedback all had to work together without cluttering the battle zone.
5. Key Takeaways
What was the part that worked the best? The gameplay systems came together well once the project moved beyond a static mockup. The final prototype has a real playable loop: home screen, level selection, combat, victory/defeat, rewards, upgrades, and progression.
What was the part that worked the worst? UI polish took the most iteration. The first versions looked like pasted assets and had broken spacing. Popups, buttons, and responsive scaling needed multiple rebuilds before they started to feel like a real mobile RPG interface.
My final thought: If I had one more day, I would regenerate the full HUD and character animation asset set with consistent transparent padding from the start, then add richer animation variants for boss attacks, enemy deaths, pet attacks, and player casting. If I could redo this project, I would lock the 9:16 layout system first before adding gameplay features, because most of the later visual problems came from inconsistent scale rules.