SOPHEA / Board Games

Apong

Apong 2026 is a lightweight, web-based Khmer Apong game built for fun-only play with no real-money gambling. The goal was to turn a simple browser game into a...

8/14/2026Views: 0Launches: 0

Apong 2026 Project Report

1. The Concept

Apong 2026 is a lightweight, web-based Khmer Apong game built for fun-only play with no real-money gambling. The goal was to turn a simple browser game into a premium cinematic game experience inspired by Khmer/Angkor visual culture, with a polished home screen, loading screen, gameplay screen, betting panel, recent results panel, sound controls, language support, and responsive landscape gameplay.

I chose Apong for this sprint because it is small enough to build quickly, but complex enough to test real game-state handling: betting, balance updates, result history, spin/reveal animation, audio toggles, responsive UI, and asset optimization.

2. The Stack

The Stack: HTML5, Vanilla CSS, JavaScript, WebP image assets, and MP3 audio.

The AI Assist: ChatGPT helped shape the product direction and visual requirements through detailed prompts and reference images. OpenAI Codex was used for implementation, debugging, UI refinement, responsive testing, asset conversion, and gameplay verification.

3. The 1 Day Sprint

Morning (Hours 1-3): We started by defining the Apong concept and analyzing the required game flow. The early focus was on building the core structure: loading page, home screen, gameplay screen, betting controls, recent results, balance display, and fun-only disclaimer. We also established the premium Khmer visual direction: Angkor sunset background, gold/bronze panels, red/gold action buttons, and a ceramic bowl/plate hero object.

Afternoon (Hours 4-6): The main work shifted into UI polish and responsive fixes. The first versions looked too much like a normal website, so we rebuilt the screens to feel more like a premium game HUD. The biggest effort was stabilizing layout across desktop, tablet, and mobile landscape sizes. We fixed the home screen, betting panel, recent results panel, gameplay layout, number cards, Place Bet/Clear buttons, and bottom controls so sections no longer overlapped.

The Finish Line (Hour 7-8): The final stretch was focused on gameplay polish and cleanup. We repeatedly tuned the die, plate, pedestal, and bowl positioning so the die spins on the plate across device sizes. We converted PNG assets to WebP, removed the old PNG files, wired assets/audio/bg-home.mp3 into the music system, fixed corrupted title/font text, and ran smoke tests to confirm betting, spin, history, and return-to-betting flow still worked.

4. The Roadblocks

Roadblocks: The biggest roadblock was responsive positioning for a layered game scene. The bowl, plate, pedestal, and spinning die all had to feel like one physical object, but early CSS used too many separate absolute offsets. This caused the die to float above the plate or the plate to drift away from the pedestal on some screen sizes.

Another roadblock was asset and text cleanup. After converting images from PNG to WebP, every runtime reference had to be updated carefully so no broken images remained. We also hit corrupted text rendering in the title area, where symbols and Khmer text appeared as mojibake. That required cleaning the fallback HTML strings and cache-busting the updated files.

The final roadblock was browser verification. Most visual QA worked, but one later local browser check was blocked by the browser security policy. When that happened, we avoided unsafe workarounds and relied on static checks plus previous successful gameplay smoke tests.

5. Key Takeaways

What worked best? The iterative visual QA process. Using screenshots and targeted fixes made the game steadily more premium without rewriting the core logic. The final UI feels much closer to a real game: cinematic background, polished panels, WebP assets, smooth betting flow, and responsive layout.

What worked worst? Layered positioning across all devices. A game scene is harder than a normal responsive website because the objects must preserve a believable physical relationship. The die, plate, bowl, and pedestal needed multiple passes before they looked correct at desktop, tablet, and mobile landscape sizes.

My final thought: If I had one more day, I would add more professional sound design, improve the die animation with a dedicated 3D/canvas layer, and create additional theme skins. If I could redo the project, I would define the stage geometry system earlier so the plate, bowl, pedestal, and die all shared one layout model from the beginning.