Turn-based artillery looks like a simple genre until you put it on a phone. On desktop, Worms and Gunbound solved aiming with a mouse: a cursor with sub-pixel precision, a keyboard for the fine nudges, and a screen wide enough that the whole arc fits. On a phone you have one thumb, a glass panel, and a diagonal drag that has to encode two continuous values at once.

I build Cannon King, a turn-based artillery game for Android and iOS (a web build shipped inside a Capacitor shell). These are the tradeoffs I keep coming back to, written for anyone else building an aiming control for touch. They are design arguments, not a recipe.

The control problem is two axes and one thumb

A shot in this genre is at least two continuous values: angle and power. Both have to be readable before the player commits, because a turn-based game punishes a wrong input with a whole turn, not a missed shot.

Three shapes are possible:

  • Drag in the field. Aim by dragging away from the tank. It feels physical and it teaches the relationship between angle and direction, but the precision of a thumb at arm's length is far coarser than a mouse. At long range, one millimetre of thumb movement is metres of impact.
  • Two separate sliders. Precise and explicitly readable, but it turns a shot into a form. Players stop looking at the battlefield and start looking at numbers.
  • A coarse physical gesture plus a discrete fine control. The drag sets the direction, the fine control moves in fixed steps. Two surfaces, one thumb, and the player can feel both.

The third one is where I ended up, and the reason is not precision for its own sake: it is that a discrete step is the only thing that makes the second shot cheap. If a player can remember "two steps back", the game teaches correction. If every adjustment is a fresh drag, every turn starts over.

The preview can lie, and that is the interesting part

A trajectory preview is a promise. In artillery games the wind changes between turns, so any preview is only true for the wind at the moment of firing. Two failure modes follow:

  • Preview ignores the wind. Players conclude the game is cheating. They watch the shell drift and stop trusting the control.
  • Preview includes the wind perfectly. The game plays itself. Skill collapses into "wait for a small wind number".

What I want is the middle: the arc is drawn honestly under the current wind, and it visibly changes when the wind changes, so the player learns that wind is a variable rather than a constant. That is a harder design target than accuracy, because visible changes cost CPU and readability — a preview that flickers is worse than a preview that is slightly wrong.

The rule I keep: the preview should be honest about what it knows and quiet about what it does not.

A turn-based match over a bad network

The genre's netcode problem is not latency. It is disagreement. In real time you can hide a 120 ms mistake behind interpolation. In a turn-based game, two clients that disagree about the terrain after a shell are playing two different games.

The part that actually matters is reconnect. A player drops mid-match; the match has to continue rather than reset, and the state on reconnect has to be the same state the other player is looking at. That is a reconciliation problem, not a streaming problem: you do not need to send what happened continuously, you need both sides to end up with the same answer.

The case I still worry about is the narrow one: an item used in the same window as a drop. A shot is easy to arbitrate, because it either appears in the turn or it does not. An item can be spent and lost to the network in a way that feels, to the player, like the game stole a resource. Every design I have considered comes back to the same principle: an action should belong to exactly one turn, and that turn should be committed once, so a reconnect replays a decision rather than guessing one.

Tuning so the third shot decides the match

In a game where the first shot is a measurement, the second is a correction and the third is the hit, balance is not "how much damage does a shell do". It is how many turns of correction the player gets before losing. Tune that and the tank grades stop mattering as much as the tier list suggests.

If the first shot has to hit for a player to have a chance, the game is a coin flip with extra steps. If the fifth shot is still the first hit, the game is a physics exam. The range I aim for is that an average player finds the target around the third shot, and a good player forces a correction on the opponent every turn.

What I would like to hear from other developers

Two questions I have not fully answered:

  1. How do you show a player that a preview is conditional on wind, without a tutorial and without an accuracy loss?
  2. For turn-based games with items, where do you draw the line between server authority and client responsiveness so an item use never feels stolen?

If you have shipped either, I would rather hear the failure than the pattern.

Cannon King is a turn-based artillery game made by one person in Seoul: 48 tanks in five grades, 20 destructible maps, 53 stages, real-time 1v1 with reconnect, and a four-slot item loadout. English, Korean, Traditional Chinese.

The code POTANKING2027 in Settings gives 5,000 credits and 10 premium draw tickets (once per account, until 31 December 2027). Mail yyhak12345@gmail.com if you want to argue about the aiming control — that reaches me directly.