Designing touch combat without overloading the player

ROADFORGE started with a control problem that appears simple on paper: a tank needs to move, steer, aim, fire, use special weapons and respond to threats. On a phone, those actions compete for two thumbs and a limited screen.

Our goal was not to fit a desktop control scheme onto a touchscreen. It was to decide which actions should demand the player's attention and which actions could be handled by the combat system.

## Let routine fire become automatic

The primary weapon fires automatically when its combat conditions are met. This leaves the player responsible for steering, acceleration, braking, positioning and the timing of limited abilities.

That split preserves meaningful control. The player still chooses the lane, decides whether to leave the road, reacts to marked danger and spends scarce support or special weapons. Automatic fire removes repeated tapping; it does not remove the decisions that shape the run.

## Treat every control as part of one screen

Individual controls can work correctly and still fail when they share a device. During physical Android testing, a support-aiming region overlapped the pause control. The fix was to reduce the input region and then test pause, aiming and return-to-tank through real touch paths on the phone.

The useful lesson was to validate the whole control surface, not just isolated callbacks. Touch regions, safe areas, camera movement and changing combat views all have to coexist.

## Make threats ask different questions

ROADFORGE uses readable categories of pressure instead of filling the screen with identical targets. Road hazards challenge steering. Enemy fire creates positioning pressure. Airstrike zones demand a quick route decision. Limited abilities help, but their scarcity prevents every encounter from being solved by the same button.

The interface gives priority to health, the current objective and immediate controls. Threat markers are there to support a decision, not to decorate the battlefield.

## Keep support weapons consistent at lower frame rates

Train and drone support introduced another mobile-specific issue. A weapon cadence that looked correct in the editor slowed on the target phone because the scheduling path effectively waited for an extra rendered frame.

We changed the timing logic so the intended cadence was not tied to a particular render rate. We did not increase damage to hide the problem. Timing, feedback and damage remained separate concerns.

## Validate the loop in the Android build

Focused device checks covered tank combat, train and drone aiming, repeated support use, return-to-tank behavior, coins, workshop progression and enemy attack paths. A one-hour same-process stability run loaded stages 1, 5, 10, 15 and 20 repeatedly for 29 total stage loads.

The run is useful evidence for the tested device and build, but it is not a universal 30 or 60 FPS promise and it is not store-certification evidence. The point of recording the limitation is to make the result useful instead of turning one successful session into a broad claim.

The complete ROADFORGE case study covers the 20-stage campaign, support systems, workshop progression and Android validation: https://uploadforsoftware.com/projects/roadforge/