Google Play @ G-Star 2025: Pixel art game with generative avatars.
01 - The Challenge
Google Play Points runs a game to engage members at GStar every year — Korea's largest gaming convention, drawing around 200,000 attendees. The brief was to improve on the previous year's version. The pitch: a pixel art world where players hunt for hidden gems using a wizard's staff, collect them, and alchemise them into real prizes.
The client loved the concept. The team wasn't sure what made it a game, or how to start building one. That's where the prototype began.
02 - The System
The initial proof of concept was built in p5.js — fast to prototype, easy to show. The production game was built in vanilla JavaScript: no engine, partly by team preference, partly because Google's server constraints and Vue compatibility requirements made third-party frameworks harder to justify.
The game runs across four stages — Market, Forest, Cloud Temple, Castle — each built using Tiled, with tilemap assets produced by a dedicated pixel artist. Each stage is a layered tile map: walkable areas, blocked zones, foreground objects the player can pass behind.
The hot/cold mechanic drives the hunt: a wizard's staff glows brighter as the player moves closer to a hidden gem, dimmer as they move away. Gem collection feeds into an alchemisation system where players combine items for real prizes.
Player avatars were generated using the Androidify engine — seven character classes (druid, bard, paladin, fighter, gamer, rogue, ranger), each animated across four directional movement states using Veo, and implemented as sprite-controlled characters responding to keyboard and mouse input. The client initially rejected a pixelised version of the outputs — the style didn't hold at low resolution — so the characters were kept clean, which also avoided any brand team concerns about modifying the Android mascot.
Avatars generated by Androidify, used to generate videos in Veo
03 - The Decisions
The initial tilemap architecture used seven layers — designed to keep the system manageable at prototype scale. As the game evolved, players needed to pass in front of and behind whole objects: trees, buildings, foreground elements with depth. The layer plan didn't account for that complexity at production scale.
Rather than defend the initial architecture, I asked Oliver Dooley — a more senior developer on the team — to rework it. I told him I wasn't precious about the code. He improved the tilemap system and made broader performance improvements across the codebase. The right call was recognising where the problem exceeded the initial design, and making space for someone better positioned to solve it.
The honest note: a more thorough design pass on depth and foreground behaviour before building would have caught it earlier. It's the same lesson as the PlayCanvas reflection probe gap on Moncler — capability evaluation upfront saves critical-path rework later.
04 - The Complexity
The pitch succeeded, but the team came into production without a clear answer to a fundamental question: what makes this a game rather than an interactive experience? The prototype had to answer that — not by defining game design theory, but by demonstrating mechanics compelling enough to build on.
The avatar work bridged two projects: outputs from the Androidify engine, animated using Veo, gave the game characters that carried Google's visual language without requiring a separate asset pipeline. The connection wasn't incidental — it was a deliberate reuse of work already done, applied in a new context.
The game shipped for a live event at BEXCO, Busan, in front of approximately 200,000 attendees over four days. The constraint wasn't a demo — it was a live product in the hands of a gaming convention crowd.
05 - The Evidence
Hot-cold mechanic
Tour of the market level
Tour of the castle level
06 - My Contribution
Prototyped the core game mechanics in p5.js — movement, inventory system, hot/cold gem detection — and built the initial production version in vanilla JavaScript. Implemented the avatar system using Androidify engine outputs animated with Veo, and built the directional sprite control. Designed and built two of the four stages — Royal Castle and Market — in Tiled, in close collaboration with pixel artist Anett Jaschke, who designed all the tile maps, pixel UIs and built Forest and Cloud Temple levels. Handed off the avatar animation system to the team for the remaining character classes and directions.
Worked alongside Oliver Dooley, who made significant architectural improvements to the tilemap system and broader codebase, and a junior developer who handled the UI. Associate and senior tech directors oversaw the wider event site build and client relationship.