There’s always a pull between creative vision and data in game development. Push too far towards intuition and you can ship a game that frustrates players in ways you never saw coming. Push too far towards metrics and you sand the character out of the experience.

The sensible middle ground is clear enough. Analytics should inform design decisions, not sit in the driving seat. At Relish Games, data works best as a diagnostic tool: it shows where the problems are, while the fix still comes from design judgement.

What to measure, and what to leave alone

The first mistake most developers make with analytics is trying to measure everything. Every click, every frame, every player action goes into a database, and nobody can explain what any of it means. That leads to paralysis, not insight.

High-value metrics

Session length distribution is useful because it shows how long players stay in one sitting. Short sessions can point to frustration or a natural stopping point. Very long sessions in a game built for shorter play can point to compulsion mechanics rather than enjoyment.

Level or area completion rates show where players stop progressing. A sudden drop at one level usually means a difficulty spike, an unclear objective, or a technical fault.

Feature discovery rates matter because they tell you whether players are finding the mechanics you spent months building. If 80% of players never discover a core ability, the tutorial or signposting has failed.

Return rate is another one worth watching. Do players come back after the first session? After the third? Retention curves show whether the game has staying power or just a strong opening.

Low-value metrics

Total play time, by itself, tells you very little. Time can mean enjoyment, but it can just as easily mean frustration.

Achievement completion rates mostly reflect achievement design, not game design.

Social sharing rates are heavily shaped by platform mechanics, which makes them a poor proxy for quality.

Setting up analytics for indie games

You do not need enterprise-grade infrastructure to get useful data out of a game. A pragmatic indie setup is usually enough.

Minimal viable analytics

Start with session tracking: start time, end time, platform, and device info. Add milestone events for level starts, level completes, deaths, boss encounters, and key item acquisitions. Track quit points so you know exactly where the player stopped. Error tracking matters as well, especially for crashes, soft-locks, and edge-case failures.

Implementation approaches

Local logging during development is a good first step. Before setting up any cloud analytics, log events to local files during playtesting. It is free, private, and gives you data straight away.

After that, a lightweight event system is often enough. A simple HTTP endpoint that receives JSON events does the job. You do not need a third-party analytics SDK with its own privacy baggage.

For 2D games where position matters - platformers, exploration games, action games - heatmaps are worth the effort. Recording player position and visualising it spatially reveals movement patterns that verbal feedback never catches.

Reading the data without talking yourself into circles

The funnel trap

It is tempting to treat every drop in the numbers as a problem to fix. That is not always correct. Some players are supposed to quit at certain points. A hard optional boss that only 15% of players beat may be working exactly as intended if it creates stories and encourages replay.

Context matters. A drop-off at a mandatory progression point is likely a problem. A drop-off at an optional challenge may be the intended difficulty curve. A drop in the first 10 minutes is critical, because first impressions drive retention. A drop after 20+ hours may just be natural content completion.

Player segments

Aggregate data hides individual stories. A level with a 60% completion rate might contain two very different groups: 70% who breeze through and 30% who are completely stuck, or 60% who finish in 5 minutes and 40% who take 30 minutes. Same metric. Different problem. Different fix.

A/B testing for indies

Full A/B testing needs more player volume than most indie games have at launch. Still, the principle is useful. Ship different difficulty curves in separate demo builds. Test two tutorial approaches with different playtester groups. Compare session metrics before and after a patch that changes a mechanic.

Practical examples from gameplay data

Example 1: The death map

In a 2D platformer, record every player death location and overlay the deaths on the level map. Clusters show where people struggle. A dense cluster around one jump may mean the jump is unfair, or the visual cues do not communicate the timing properly.

The data tells you where players die. Design judgement tells you why they die and what to change.

Example 2: The item usage matrix

Track which items or abilities players actually use. If a weapon is used by 3% of players, it is either underpowered, poorly signposted, or hidden somewhere nobody finds. The data flags the neglected item; playtesting tells you which problem applies.

Example 3: The pause-and-quit pattern

Players who pause and quit within 30 seconds are probably frustrated. Players who pause and quit after several minutes may just have been interrupted by real life. That difference matters when you interpret quit data.

Analytics and player trust

Analytics in games carry real ethical responsibilities.

Be transparent about what you collect and why. Minimise data collection to what you will actually use. Anonymise by default, because most analytics do not need to identify individual players. Respect opt-outs and let players disable analytics without penalty. Local processing is worth considering too, since aggregating data locally and sending summaries is better than spraying raw event streams everywhere.

A practical approach for 2D indie games

Based on our experience, the order matters.

Start with playtesting, not analytics. Watch real humans play the game before building any data pipeline. Instrument the critical path first, so you are tracking the journey through mandatory content before anything else. Add spatial data for 2D games, because position heatmaps are especially useful for level-based design. Review data weekly rather than daily, since daily checks tend to encourage reactive changes. And do not change a design that is already working just because the numbers are interesting. Interesting is not the same as broken.

The HGE engine provides the system state hooks and frame-level callbacks needed to integrate lightweight analytics without interrupting your game loop.

Keeping the balance

Good data-driven design shows up blind spots. It reveals the things players experience that you, as the developer, cannot see because you know the game too well. Bad data-driven design turns creative decisions into optimisation exercises.

Use data to find problems. Use craft to solve them.

Discuss analytics approaches with other developers in our forum, or explore how game systems are structured in the HGE documentation.