Multi-step turns and the combat interface
How a soldier’s plan for a round became a chain of actions: an order queue, the cost of turning, a planning cursor and an interface built around time.
In the first version of combat a soldier got one order per round: move to a cell, or fire. Having arrived, he stood there until the round ended, with time left for half another job. That is when the idea came to give a soldier a plan for the whole round: run to the corner, crouch, turn, fire. It turned out this meant reworking not only the interface, but also how a soldier turns, how a path is found, and what happens when a runner gets hit.
A round is five seconds
Terminal Leave has no action points. A round is five seconds of a shared timeline, and every action has a duration. Today the numbers are: a walking step takes half a second per cell, running a third, crawling a second and a half. A change of posture takes 0.4 seconds. A single shot 0.6, an aimed shot two, a reload a second and a half. A soldier’s Endurance makes his step a little faster or slower.
The arithmetic follows. Running seven cells, crouching and taking an aimed shot fills almost the whole round. Run twelve and there is no time left for an aimed shot, only a single one. The player chooses not “how many points to spend” but what to get done before the five seconds run out — knowing that the opponent is carrying out a plan at the same time.
The server sets the time of every action. The client can show the player a forecast, but when the round resolves the server works everything out again by its own rules and its own map.
The order queue
Every soldier has a queue of orders. Actions are added in order and carried out one after another: each starts where and when the previous one ended. The queue can be long, but whatever doesn’t fit into the round doesn’t live on into the next.
A shot in the queue is aimed at a soldier, not a cell. If the target moved during the run, the shot goes to where it stands at that moment. If it left the line of sight, the shot doesn’t happen, and no time is wasted on it.
Actions can only be cancelled from the end. That limit isn’t arbitrary: each next action counts from where the previous one ended, and pulling a step out of the middle would start everything after it from the wrong cell.
The planning cursor
The first version of the queue was built wrong. Every move was counted from where the soldier stood at the start of the round. A plan of “run three cells, crouch, run two more to the right” didn’t add up: the second run started again from the original cell, and the soldier ran it upright, even though he had crouched before it.
So a planning cursor appeared. It sits not on the soldier but at the end of the chain already given — in the cell, the posture and the facing the soldier will have after all the previous actions. The next order counts from there. The “walk” and “run” buttons set only the speed; the way of moving comes from the posture at the cursor. A crouched soldier sent running runs bent low. A prone one crawls, fast or slow.
The cursor works from what the player knows. If the route holds an obstacle that wasn’t visible, the server stops the soldier in front of it, and the rest of the plan simply doesn’t happen. The client doesn’t learn about the hidden thing in advance — that is part of the same rule by which the server gives the client nothing the soldier can’t see.
Turning costs time
Before this stage facing was only a picture: the client turned the soldier the way he moved, and for the simulation turning was free. Now facing is part of a soldier’s state. It carries over between rounds, the soldier sees in a cone in front of him, and to look the other way he has to turn. Today every 45° costs 80 ms. A full about-face is a third of a second, about one cell at a run.
That changed pathfinding. The shortest route in cells isn’t always the fastest: a path with an extra turn can take longer than one a cell longer. A route is now searched over pairs of “cell and facing”, at the same cost as in the simulation. So the route the player sees while planning is the one the soldier then runs.
A soldier can also turn on the spot, without moving: the right mouse button turns him toward the cell under the pointer. The turn spends round time, like a change of posture.
Hit on the run
If a runner is hit by an aimed shot, he loses his stride: he stops at the nearest cell, loses about a third of a second and runs on. He doesn’t drop the plan, but by the end of the round he covers less ground than he counted on. An overwatch shot is stronger — it cuts the move off entirely.
A similar pause happens when two soldiers want to pass through one cell. The one who wasn’t given way waits and tries again, and if the cell never frees up, he stops. Two soldiers swapping neighbouring cells simply pass through each other.
The interface
The combat interface was built from a mock-up drawn in advance: the battlefield across the whole screen, panels around it — the soldier’s status, the squad, the turn plan, weapon, actions, the minimap. Time is the centre of it. Every action in the plan shows its cost, and the bar under the portrait shows how much of the round is already taken. When it empties, the plan for this round is full.
Control is by mouse. A click on the ground lays a route from the planning cursor. A click on a visible enemy adds a shot in the chosen mode, and hovering over him shows an approximate hit chance. The right button turns the soldier, Backspace cancels the last action. For touch screens the same actions are repeated as buttons.
The route is built on a click, not as the mouse moves. In the first version it was recalculated on every pixel, and the battlefield stuttered noticeably.
What is still rough
The hit chance on hover is approximate and marked with “~”. The client doesn’t know the enemy’s Agility or everything cover gives, so it counts only what it can see.
Only movement can be planned several rounds ahead. The client remembers a long route and in each new round sends its next leg itself, recalculated from where the soldier actually ended up. For that the client has to be in the battle every round. Fire and watching have to be set again.
And in dense buildings a route doesn’t always fall the way the player wanted: the fastest path may round a corner on the wrong side. Then it has to be led through waypoints, with several clicks.
How a round resolves once plans are locked is covered in the article on simultaneous turns.