Case study · Own product · Mobile game

Grow.io: a canvas game,
shipped to Google Play.

Grow.io is BBR’s own arcade game for Android. The player starts as a small star, absorbs matter and smaller opponents, and evolves through eight stages from Protostar to Black Hole. We designed, built and released it ourselves.

Product
Arcade game, BBR’s own title
Platform
Android, on Google Play
Rendering
HTML5 canvas, plain JavaScript
Packaging
Capacitor
Monetisation
AdMob ads, in-app purchases
Languages
English, Spanish, French, Turkish
Product concept

A familiar loop with its own progression.

The “grow by absorbing” genre is well understood by players, which makes it a good base for a small studio’s own title: the core loop needs no tutorial, so effort can go into feel and progression instead of explanation.

Grow.io sets that loop in space. Players collect stellar matter, absorb smaller stars, and pass through eight evolution stages. Abilities such as splitting, ejecting mass and a nova blast give skilled players options beyond steering. A talent system and unlockable skins provide longer-term goals, and a leaderboard gives each session a target.

Opponents are AI-controlled. That was a deliberate scope decision. Real-time multiplayer needs game servers, matchmaking, latency compensation and cheat prevention, which is a large, permanent operating cost for a first release. Bots that behave believably give the player the same moment-to-moment experience, work offline, and cost nothing to run.

Engineering approach

Why canvas and plain JavaScript.

The game is rendered on a single HTML5 canvas and written in plain JavaScript, with no game engine or front-end framework. For a 2D game with simple geometry, a full engine adds download size and startup time without removing much work. The pieces that matter here are a time-based game loop, a camera, collision checks between circles, and draw calls, all of which the platform already provides.

Rendering

Everything on screen is drawn procedurally: gradients for star surfaces and coronas, glow effects, particle trails. Premium skins combine image assets with canvas effects layered on top. Drawing procedurally keeps the install small and lets visual effects scale with the player’s size without extra art.

Opponent behaviour

Each bot evaluates what is nearby, flees larger bodies, chases smaller ones, and uses split and eject abilities under defined conditions. The aim is not optimal play. It is opponents that make recognisable decisions, make mistakes a human might make, and produce close calls.

Packaging for Android

The web build is wrapped with Capacitor, which hosts it in a native Android shell and exposes native features to JavaScript. That gave us one codebase that runs in a desktop browser during development and ships as a store app. Ads use the AdMob plugin; purchases go through Google Play Billing via a purchase plugin.

Localisation

All interface text runs through a small translation layer with English, Spanish, French and Turkish string tables, switchable in-game. Building this in from the start is cheap. Retrofitting it into a finished interface is not.

Challenges

What was harder than expected.

Performance inside a WebView

A canvas game that runs smoothly in desktop Chrome can struggle in an Android WebView on a mid-range phone. The fixes were unglamorous: drawing only what is inside the camera view, capping particle counts, avoiding per-frame allocations that trigger garbage collection, and reducing expensive gradient and shadow operations as the number of on-screen bodies rises.

Landscape-only layout

The game is designed for landscape. Menus, the shop and the HUD all had to work across very different aspect ratios and around display cut-outs, and the game shows a rotate prompt when held in portrait.

Store requirements

Releasing a game with ads and purchases means meeting Google Play’s policies on billing, ad placement, data safety declarations and content rating, and providing a privacy policy and an account-deletion route. None of it is difficult, but each item blocks release until it is done, so it belongs in the plan from the start rather than the final week.

What this shows

Relevance to client work.

Grow.io is a game, but the engineering carries over directly to client products:

  • Web technology can be the right choice for a store app. For many products a Capacitor or React Native build reaches both stores from one codebase at a fraction of the cost of two native apps. We set out when that holds in native vs cross-platform development.
  • Scope decisions decide budgets. Choosing AI opponents over live multiplayer removed an entire back end from the first release. The same thinking applies to any MVP.
  • Release work is real work. Billing, ads, store listings, policies and device testing are part of mobile app development, and we have taken our own products through all of it.

We do not publish download or revenue figures for our products. The game is live on Google Play and you are welcome to judge it directly.

Your next move

Building a game or app?
Let’s talk through it.

If you are weighing up web technology against a native build, or need someone to take a product through store release, tell us what you are planning.

Discuss your project