### Summary I built two promotional **mini games** for Labatt that were fully integrated into the **Couche-Tard mobile app**. The first game is **Ride The Tide**, an infinite runner where the player surfs on a wave, dodging obstacles while collecting Coronas to increase their score and trigger power-ups. The second is **Drop The Lime**, a skill-based precision game where the player drops limes into moving Coronas. When a lime lands on an already capped Corona, it bounces, giving the player a chance to do a skill shot and earn bonus points. Both games needed to feel fun, lightweight, and responsive while running inside a webview of a mobile app. --- ### Result

--- ### Tech Stack - **Languages:** TypeScript, HTML, CSS - **Rendering Engine:** PixiJS (WebGL 2D) - **Build System:** Custom HTML and asset bundler with CLI built from scratch - **Deployment:** CDN-hosted single-file HTML games - **Graphics:** Custom-designed assets (placeholder during development) - **Physics:** Custom compound collider system using the Separating Axis Theorem (SAT) - **Audio:** Lightweight audio player using Web Audio API - **Compression:** Base64 asset embedding and minified inline JavaScript - **Environment:** Mobile webview within the Couche-Tard app (Android & iOS) This stack allowed me to achieve fast load times, smooth 60 FPS performance, and full control over rendering and logic, all while maintaining a small footprint suitable for mobile webviews. --- ### Challenges There were four major challenges in this project: **performance**, **modularity**, **content**, and **time**. #### 1. Performance The games had to run smoothly inside a mobile webview while keeping CPU and memory usage low. The frame rate needed to stay stable, load times had to be fast, and collisions had to be handled precisely and efficiently. #### 2. Modularity We weren’t allowed to push app updates to modify the games after launch. This meant the games had to be modular, easy to update externally, and able to share common components like tutorials, end screens, and settings popups without touching the main app code. #### 3. Content The client gave us full creative freedom, so we had to invent everything from the game mechanics to the art direction and level design. That was exciting but also challenging, as the games still had to fit Labatt’s and Couche-Tard’s brand identity. #### 4. Time I had exactly **one month** to research, design, develop, and deliver two production-ready games. And to make it even more interesting, I had zero prior experience in mobile game development. --- ### Solutions #### 1. Performance Since the games were running in a webview, the stack was naturally TypeScript, HTML, and CSS. To achieve high-performance 2D rendering, I used **PixiJS**, a WebGL-based rendering library that's fast, lightweight, and perfect for game-like experiences in the browser. I implemented the following optimizations and design choices to achieve smooth performance: - Each game was bundled into a **single HTML file**, minimizing network requests. - I wrote a **custom HTML bundler with CLI** that compressed JavaScript and assets, automatically inserted menus and logic depending on the selected game, and embedded everything into one file for easy deployment. - All game assets were **converted to base64** and embedded directly into the HTML to avoid multiple network requests. - I avoided all external libraries except PixiJS to keep bundle size and memory usage as low as possible. - I implemented a **compound collider system** based on the **Separating Axis Theorem (SAT)** for accurate and performant collision detection. You can read more about SAT [here](https://code.tutsplus.com/collision-detection-using-the-separating-axis-theorem--gamedev-169t). Here is a video of the collision detection in action:

- Additional optimizations included selectively disabling collision checks in specific inactive zones of the scene to reduce CPU load. These techniques made the games extremely fast and reliable, even inside a constrained webview environment. #### 2. Modularity To handle modularity, I built a small internal system of **shared UI components**. These included elements like tutorials, pause screens, end-game menus, and settings buttons. Each game reused these components, which had consistent behavior but adapted their visuals to fit each game’s style. Since we couldn’t update the app itself, both games were **served through a CDN**. This made it possible to instantly push updates, tweak visuals, or improve gameplay without resubmitting the app to the stores. The CDN approach also kept load times short and ensured users always received the latest version. #### 3. Content and Game Design Because the client gave us creative freedom, we came up with two distinct and complementary experiences: 1. **Ride The Tide:** an infinite runner where the player surfs through obstacles, collects Coronas, and uses power-ups to extend their run and gain more points. 2. **Drop The Lime:** a timing and precision game where the player drops limes into rotating Coronas, bouncing off capped bottles for combo shots and bonuses. To make the gameplay more engaging, I added plenty of **"game juice"** such as power-ups, camera shakes, particle effects, smooth animations, and sound effects that make every action feel satisfying. We also created all the graphics for the games. Since we only received the final art assets two weeks before launch, most of the development happened with placeholder graphics. The collision system had to be extremely flexible to adjust to new shapes and dimensions without breaking gameplay. That adaptability saved us when the final assets came in late. #### 4. Time and Workflow One month to build two polished games is tight. I managed my part of the project by defining clear milestones, starting with core systems such as rendering, collision handling, and state management, before moving on to game-specific logic and polish. AI was helpful in speeding up certain parts of development, especially when experimenting with new concepts or quickly generating boilerplate code. However, it often produced incomplete or inefficient results, so I relied on it primarily for guidance while maintaining full control over architecture and logic. In the end, the key to success is to **conduct proper research**, **guide the AI effectively**, **break large problems into smaller steps**, and **maintain a clear understanding of the target architecture**. Careful iteration and testing were the only way to hit the one-month deadline with stable, fun, and bug-free games. --- ### Simplified Architecture Here's a simplified diagram of the architecture for both games: ```mermaid graph TD C[Shared Components] --> D[Custom Bundler CLI] E[Game 1 Code] --> D F[Game 2 Code] --> D I[Game Assets
Graphics, Audio, Fonts] --> D D --> A[Game 1: Ride The Tide
bundled with UI components] D --> B[Game 2: Drop The Lime
bundled with UI components] A --> G[CDN] B --> G G --> H[End Users
in Couche-Tard App] ``` --- ### Conclusion The Labatt mini games were a great success. They were fully integrated into the Couche-Tard app and received positive feedback from users. The project was a great learning experience and allowed me to gain valuable experience in mobile game development. And yes before anyone asks, I could have used a html game engine like [Phaser](https://phaser.io/) or a bundler like [Vite](https://vitejs.dev/) with some plugins to build the games. In all honesty, I considered them, but I wanted to have full control over the architecture and the code and I thought it would be a good challenge and learning experience to build the games from scratch. I also got to learn how to make a simple bundler from scratch so I think it was worth it. Was it the most optimized solution? Probably not, but I'm proud of the results. Enough so that the client came back and asked to build a third game. The games were **played over 400k times in 3 months**. Thanks for reading!