The Question That Started This
Two puzzle games sit side by side on a The Weekly Report test phone. Same genre, same rough visual complexity, same session length. One of them costs us a tenth of the battery in half an hour. The other costs us a fifth. Nothing on either store listing explains the gap, and nothing in the first ten minutes of play makes it obvious.
That gap is the subject of this article. It is not mysterious once you know where to look, and most of the causes are choices a development desk made rather than accidents of hardware. Below is what our testing has taught us about where a phone's power actually goes during a game, what network activity a game legitimately needs, and how a reader can check any of it without special equipment.
The Screen Is the Baseline, Not the Explanation
Start with the honest part: on a modern phone the display is usually the single largest consumer during a game, and a bright screen held for thirty minutes costs roughly what a bright screen costs regardless of what is on it. That is the baseline both of our puzzle games pay.
Where games separate is in what they ask of the processor and the graphics hardware behind that screen, and in how much of that work is wasted. A game that draws a static board once and then sits still until the player touches it is doing almost nothing between taps. A game that redraws the same static board sixty times a second because it never stopped its render loop is doing the same visible work at many times the cost. Neither looks different to the player. Only one shows up in the battery panel.
Frame Rate Is a Choice
The single biggest lever most games have is how often they redraw. A few patterns we see repeatedly:
Uncapped rendering. The game draws as fast as the hardware allows, which on a capable phone can be far beyond what the display shows. The extra frames are discarded. The heat is not.
High refresh rates by default. Some phones offer 90 or 120 Hz panels. A fast action game may genuinely benefit. A word game almost never does, and a game that opts into the high rate without asking is spending the player's afternoon on something they cannot see.
No idle state. Well-built mobile games drop their frame rate hard when nothing is moving — on a menu, on a paused board, during a text screen. Games that do not are the most common cause of the gap in our opening example.
Physics running when it need not. A simulation that keeps solving after everything has come to rest is invisible work. A good engine puts sleeping bodies to sleep.
What Background Data a Game Legitimately Needs
Network activity matters for battery as well as for a data allowance, because waking a radio is expensive and a game that wakes it every few seconds pays for that repeatedly. Our desk does not treat network use as suspicious in itself. We ask what it is for, and whether it is batched.
| Activity | Legitimate reason | What we look for |
|---|---|---|
| Save synchronisation | Progress that survives a lost phone | Batched at session end, not continuous |
| Content updates | New levels, seasonal boards, event schedules | Fetched on launch, cached afterwards |
| Advertising | The game is free and funded that way | Prefetched in blocks; no chatter while idle |
| Analytics | Understanding where players stop playing | Small, batched, and stated in the listing |
| Leaderboards | Comparing scores between players | On demand, not on a loop |
| Live services | Genuinely shared, simultaneous play | Constant traffic is expected here and fine |
The pattern that concerns us is not volume but rhythm. A game that transfers a few megabytes once at launch has done something sensible. A game that transfers the same total in hundreds of small requests spread across an hour has kept the radio awake for that hour, and the player pays for it twice — in power and in a data allowance that a commute can exhaust.
Three Checks You Can Run Yourself
- Read the battery panel your phone already keeps. Android maintains a per-app breakdown in the system settings, usually under battery usage. Play one game for a measured half hour, then check the figure. Do the same with the other. The comparison is more useful than either number alone, because it cancels out your screen brightness and your phone's age.
- Check the data figure with the game closed. The same settings area records mobile and Wi-Fi data per app. Note a game's total, then leave the phone alone for a few hours without opening the game, and look again. A game that has moved a meaningful amount of data while you were not playing is doing something it should be able to explain.
- Watch the phone's temperature during a menu. Sit on the main menu — not in a level — for five minutes and feel the back of the device. A phone that warms up while nothing is happening on screen is telling you the render loop never idled. This is a crude test and it works.
How This Enters Our Reviews
We run each candidate on more than one handset, including older hardware, because a game that behaves well only on a recent phone is a narrower recommendation than it appears. Power behaviour and background traffic are noted in the review body and they feed the score, which is our own editorial judgement and is deliberately not the store's star average. The weighting is set out on our methodology page.
None of this means a demanding game is a badly made one. A rich three-dimensional game that warms a phone is being honest about what it does. What we mark down is disproportion: a game whose visible ambition is modest and whose power cost is not. That is nearly always a loop left running, and it is nearly always fixable.
The current ranking is on the front page, and the rest of our technical writing sits in the article index.