SOPHEA / Card Games

Khmer-Cards-Ka-Te

Khmer Cards: Ka Te is a lightweight, web-based interpretation of the traditional Ka Te card game. It presents a complete six-player match against five AI...

8/20/2026Views: 0Launches: 0

Khmer Cards: Ka Te Project Report

1. The Concept

Khmer Cards: Ka Te is a lightweight, web-based interpretation of the traditional Ka Te card game. It presents a complete six-player match against five AI personalities while preserving the core Catch, PASS, survival, Chưng, and Final Reveal rules. I chose Ka Te for this sprint because it combines strict state management with strategic AI, hidden information, responsive interaction, animation, sound, and culturally inspired visual design. This made it a strong test of whether an AI-assisted workflow could handle both complicated game rules and a polished player experience without relying on a framework.

2. The Stack

The Stack: HTML5, Vanilla CSS, JavaScript, Web Audio API, and localStorage. The AI Assist: Cursor's AI coding agent was used throughout the project to inspect the existing implementation, translate gameplay requirements into code, debug state and animation problems, refine the responsive interface, and run automated and browser-based QA. The process was iterative: each user review identified a focused issue, and the AI updated only the affected system while preserving the approved game rules and visual direction.

3. The 1 Day Sprint

Morning (Hours 1–3): We began by establishing the six-player Ka Te flow and correcting the most important gameplay rules. The work focused on stable card identity, dealing exactly six cards to each player, resolving Catch and PASS correctly, eliminating players who failed to survive the first four tricks, and defining Chưng and Final Reveal as separate phases. Automated match simulations were added so rule changes could be tested repeatedly instead of relying only on manual play. Afternoon (Hours 4–6): The project shifted toward interaction and presentation. We fixed card dealing so hands no longer appeared to reload, improved card movement and collection animations, added mouse and touch card reordering, preserved manual hand order, and refined the responsive six-player table. A complete Web Audio system was also introduced with synthesized sound effects, independent music and SFX controls, persistent settings, and safeguards against duplicated sounds. The Finish Line (Hours 7–8): The final phase concentrated on polish and QA. We added four fair AI difficulty levels, a premium difficulty selector, desktop ambient backgrounds, subtle Home and gameplay effects, sharper card presentation, and a cleaner automatic Round 6 reveal. Oversized visual effects and unused assets were removed, generated QA browser profiles were cleaned from the repository, and installation and gameplay documentation were added. Final verification included syntax checks, asset-reference auditing, responsive browser checks, difficulty tests, Final Reveal scenarios, and hundreds of simulated six-player matches.

4. The Roadblocks

Roadblocks: The largest challenge was keeping gameplay state, DOM state, and animation timing synchronized. Early versions re-rendered cards during dealing and play, which made cards appear to reload and could break the physical-card feeling. Round 6 was another major difficulty because it initially behaved too much like a normal playable trick instead of an automatic reveal controlled by the Chưng winner's remaining card. Responsive design also required repeated adjustment. The portrait table needed to remain intact on mobile, landscape, and desktop without cropping players, stretching artwork, hiding buttons, or allowing card indicators to drift outside the table. Browser-based drag testing presented an additional obstacle because automated drag tools did not emit the same pointer-move sequence as a real mouse or touch interaction. Custom pointer-event testing and direct layout measurements were used to verify the final behavior. The project also accumulated large browser-profile and screenshot folders during QA. These generated files were mistakenly tracked and greatly increased the repository size. A final asset audit removed more than 4,000 generated cache files, obsolete audio samples, unused icons, and retired visual effects while confirming that every remaining production asset was referenced.

5. Key Takeaways

**What was the part that worked the best?

Automated rule verification and narrowly scoped iteration. Separating the engine, AI, UI, effects, storage, and audio systems made it possible to improve one area without rewriting the complete game. Simulating hundreds of matches was especially valuable because it exposed illegal moves, invalid card counts, and Final Reveal edge cases much faster than manual testing. What was the part that worked the worst?

Visual refinement through text-only instructions. Small issues such as table alignment, button padding, card shadows, and seat positioning often required screenshots and several responsive measurements before the intended result was clear. Large visual effects also looked acceptable in isolation but became distracting when placed over actual cards and player information. My final thought:** If I had one more day, I would add a dedicated visual regression suite that captures every major screen and gameplay phase at all supported viewport sizes. I would also expand deterministic AI scenario tests for PASS, Catch, Trick 4 survival, and Chưng planning. If I could redo the project, I would establish the responsive table coordinate system and automated asset-cleanup rules at the beginning, reducing the amount of late-stage layout correction and repository cleanup.