Kun Khmer Shadow Warrior Project Report
1. The Concept
Kun Khmer Shadow Warrior is a mobile-first, web-based 2D fighting game inspired by Cambodian Kun Khmer. The goal was to create a premium 9:16 fighting-game prototype with dark Khmer temple atmosphere, real image assets, career progression, level-based enemies, touch controls, audio, and real-time combat logic.
I chose this game idea because it tests much more than a simple static website. It needs responsive UI, animation, asset loading, game state, AI behavior, hit detection, stamina, health, rewards, and screen-to-screen flow. It also has a strong cultural identity, so the visual style had to feel specific to Kun Khmer instead of looking like a generic fighting game.
2. The Stack
The Stack: HTML5, CSS, and Vanilla JavaScript.
The project uses real PNG/WebP image assets for fighters, arenas, portraits, icons, UI frames, effects, and equipment. CSS is used only for layout, spacing, animation, responsiveness, shadows, borders, and positioning. JavaScript handles screen navigation, career levels, combat state, AI behavior, asset validation, save progress, audio management, rewards, and gameplay logic.
The AI Assist: ChatGPT helped shape the initial product idea, target audience, and feature plan. OpenAI Codex was then used for the development phase, turning the idea into a playable browser prototype and repeatedly fixing broken UI, asset, and gameplay issues.
3. The Development Sprint
Planning Phase: We started by reading the project notes and defining the target: a mobile-first web fighting game for Cambodian and international fighting-game fans. The first plan focused on Kun Khmer identity, 1v1 combat, story/career progression, tournament mode, equipment, daily challenges, and optional monetization through ads or cosmetic items.
Build Phase: The first implementation created the main screens: home, career, fight, profile, world tour, equipment, tournament, daily challenge, and settings. The game also gained touch controls, keyboard controls, health bars, stamina bars, timer, AI movement, combo feedback, rewards, and level progression.
Polish Phase: A lot of time went into fixing visual and gameplay problems. The UI had clipped buttons, duplicated HUD elements, bad spacing, and broken fighter rendering. We replaced placeholder objects, removed CSS-drawn artwork, regenerated icons and equipment assets, improved home-screen PC ambience, added multiple arenas, created unique level opponent sheets, and added a hidden dev/debug screen.
Final Safety Phase: The most important improvement was the asset validation and loading system. Before a fight starts, the game now validates player sprite, enemy sprite, portraits, arena, and HUD assets. If anything fails, the match is blocked instead of rendering placeholders. A loading screen now shows per-asset progress and clearer error details.
4. The Roadblocks
Roadblocks: The biggest roadblock was asset quality and consistency. Fighting-game sprites must have identical frame size, transparent padding, correct baseline, and no cropped body parts. Early sprite sheets had cropped hands, feet, knees, or effects, which caused broken-looking combat.
Another major issue was placeholder rendering. When an enemy asset failed, the game displayed a debug placeholder object, which looked completely wrong. This forced a rebuild of the rendering pipeline so missing assets stop the match instead of showing fake graphics.
Responsive UI was also difficult. The game had to work at 360x800, 390x844, and 430x932 while keeping HUD, controls, fighters, and text inside the screen. Several passes were needed to fix clipping, duplicated headers, crowded controls, and text overflow.
The final roadblock was variety. At first, all levels felt too similar because they reused the same arena and fighter visuals. We added multiple arena variants and unique level opponent sprite sheets, but the next major visual upgrade should be truly different arena artwork, not only color variations.
5. Key Takeaways
What worked best was the strict asset validation approach. Once the game stopped accepting missing or invalid assets, it became much easier to protect the build from placeholder objects and broken matches.
What worked worst was trying to improve visuals before the rendering pipeline was stable. Fighting games depend heavily on correct sprite bounds, anchors, hitboxes, and loading logic. When those systems are weak, even good UI polish breaks quickly.
My final thought: If I had one more development day, I would generate truly different high-quality arena backgrounds first, then upgrade the fighter animation system from 6-frame sheets to dedicated animation rows for idle, walk, punch, kick, elbow, knee, block, hit, and KO. The safest next step is to keep improving visuals one system at a time while preserving the current asset validation and loading flow.