Skip to content

Product engineering

Talk to us Discuss a Project

Case study · Game development

Polar Attack

A reflex game built to find out how a small team gets from an idea to a published title, and what an engine choice costs you either way.

Published on Play Store

Engagement
Internal innovation project
Platforms
Android application
Role
Concept, design and engineering
Stage
Published Verify before publishing
The Polar Attack game: the snowman dodging falling icicles with a coin to collect, the difficulty selection screen, and the high-score board.
Industry
Casual gaming
Users
Players across age groups
Control
Device tilt
Platforms
Android
Role
Innovation build
Status
Published

01The business situation

A small game is a complete product in miniature.

Our innovation team wanted a project that would run the whole distance (concept, art, engine selection, mechanics, tuning and a real store release) at a size one team could finish. A reflex game fits that exactly: simple to describe, unforgiving to get right, and impossible to fake, because a game that does not feel good is immediately obvious.

Core challenge

Make a tilt-controlled dodging game that feels fair across three difficulty levels, and ship it to a real store.

Before

An idea with no engine, art or mechanics

  • Concept Only
  • No Engine Chosen
  • Placeholder Art
  • Untuned Difficulty

After

A published, tuned and playable title

  • Player
  • Tilt Control
  • Difficulty
  • Score

Polar Attack

02The system at a glance

One game. Four connected parts.

  • Settings & Difficulty Three tuned levels
  • Gameplay View Tilt to dodge, tap to collect
  • Scoring High scores and progression
  • Audio & Feedback Music and event sounds
Core PlatformOpen-source Java game engine
  • Tilt Input
  • Collision Detection
  • Difficulty Tuning
  • Coin Collection
  • Score Board
  • Sound Design

03Workflow 01

Tilt to dodge. Tap to collect.

The player tilts the device to move a snowman out of the path of falling icicles, tapping to collect coins as they fall. Two inputs, and all the difficulty comes from tuning rather than complexity.

Image placeholder Gameplay: the snowman moving under tilt control as icicles fall, a golden coin mid-descent, and the current score. assets/portfolio/polar-attack/workflow-gameplay.png · 16 / 11
  • Two inputs, no buttonsTilt moves the character and a tap collects, which keeps the screen clear of controls.
  • Three named levelsCold, Colder and Coldest vary icicle frequency, so difficulty scales without changing the rules.
  • Scores worth chasingA board of recent high scores gives a reason to play the next round.

04Workflow 02

Collision is where a game becomes fair or unfair.

The technical problem that mattered was detecting overlap between the character and a falling icicle precisely. Get it slightly wrong and the game feels cheap, which no amount of art fixes.

  • Overlap detection tunedCalculating the collision between character and icicle precisely was the main technical obstacle.
  • Placeholder to finished artThe character began as a stick figure and became the snowman once the mechanics held.
  • Feedback carries the feelMusic, coin taps and game-over effects were treated as part of the mechanics rather than decoration.
Image placeholder The development progression: the early placeholder character, the finished snowman with movement animation, and the refined icicles, buttons and effects. assets/portfolio/polar-attack/development-progression.png · 16 / 10
Image placeholder The difficulty selection screen showing the three levels and the high-score board beneath. assets/portfolio/polar-attack/difficulty.png · 1 / 2.04

05Engineering behind the product

The system behind a game that feels fair.

Small games have nowhere to hide. Almost all the work is in the parts a player experiences as feel rather than as features.

  • Engine evaluation

    Several game frameworks were prototyped before settling on LibGDX, a free and open-source Java game engine.

  • Collision detection

    Calculating overlap between the character and falling objects accurately was the main technical challenge and governs whether the game feels fair.

  • Tilt input handling

    Device orientation drives character movement, which required smoothing to feel controlled rather than twitchy.

  • Three-tier difficulty

    Levels vary the frequency of falling objects, tuned so each is distinct without changing the rules.

  • Score persistence

    Recent high scores are retained locally to give progression between sessions.

  • Audio feedback

    Background music and event sounds were designed alongside the mechanics rather than added afterwards.

  • Published release

    The title was taken through store submission and released publicly.

06Technical architecture

Under the hood

Several game frameworks were prototyped before settling on LibGDX, an open-source Java engine well suited to the target platform.

Android

  • Java

Game engine

  • LibGDX

Mechanics

  • Tilt input
  • Collision detection
  • Local high-score persistence

07Delivery journey

How the game was delivered.

  1. Concept

    Innovation team frames the game

  2. Engine research

    Prototype across frameworks

  3. Prototype

    Placeholder character and mechanics

  4. Mechanics

    Icicles, coins and collision

  5. Art pass

    Final character, textures and effects

  6. Tuning

    Balance the three difficulty levels

  7. Play Store release

    Published and iterating

The game is published on the Play Store and the team continues to improve it toward a next version. Dates and durations are withheld until confirmed. Verify before publishing

08Where it stands today

What the game brings together

  • Tilt-controlled movement that feels controlled
  • Accurate collision detection between player and hazards
  • Three tuned difficulty levels
  • Coin collection layered onto the core mechanic
  • A high-score board driving repeat play
  • A published Android title