Turn Lifecycle (Part 1)
Last month on Article #9 1st Class Mod Support , we explain how integral mods are to the SteelPinion engine and ecosystem. A self imposed word count limit prevented me from explaining some of the mechanics that currently exist. Therefore, I think it high time to talk about "the man engine behind the yellow curtain".
What is a turn?
At risk of sounding condescending, we need to define what a turn is. As humans, we know almost innately what that is as part of being raised in community. If you've ever had siblings, you've certainly been told to "take turns".
To a machine, however, "a turn" isn't so obvious. When does "it" start or end? What are the signals? What should the machine do when it is time to act? Indeed, even in actual life, when one "takes turns" with someone else, the rules differ on the context we find ourselves in.
From waiting in line at the water faucet to playing a game of chess, "a turn" can be various shapes.
In the SteelPinion context, we'll say that "a turn" is a set of instructions to be executed at a specific time.
Two Phases (sub-turns)
We must further break down what those instructions can be specifically, since there are two types of actions units can perform.
A phase in SteelPinion is an abstract division of a single turn. A single turn can be divided into movement and assault. We call these the maneuver phase, and combat phase.
To illustrate subtle differences in player inputs; we may compare maneuver and combat respectively below.
These player inputs are instructions that the engine will resolve once everyone has submitted orders to their units.
Let's hone in on the movement of units. In SteelPinion, all movement happens at once!
Most turn based strategy games have each individual unit perform all its actions before the next one can act; taking turns somewhat politely... Well screw that, this is battle! All units move at once, and if they should bump into each other something very nasty should happen!
The engine will receive instructions from players for their turn input for every unit. Then the maneuver solver will step through all the units bit by bit, gradually "teleporting" them into a final position.
Maneuver Phase Algorithm
This concept of "teleporting" is important, because it is the way computers actually handle position changes.
The top brown ship represents what we experience as players, while the red bottom ship better expresses what the game engine (computer) actually does under the hood! This "skipping" effect can cause glitches and bugs in the game engine, which we are most careful to avoid.
Maneuver Phase Events
Here is a table of the events that can be produced by the maneuver solver, where ship collisions are the most sophisticated EVENT; since it can trigger extra combat subsolvers and has more RULEs to process.
As we "teleport" ships, obstacles, and missiles around the map. They can bump into each other creating an EVENT.COLLISION.
The kind of entities crashing determines what can happen in the downstream RULES.
title: vessel risks crash
condition: ship vs ship
apply(event) => ...
title: hidden by vapor
condition: ship vs cloud
apply(event) => ...
title: crash into structure
condition: ship vs building
apply(event) => ...
Player Modding Collisions
Ships crashing into other ships or obstacles can currently trigger either a stealth EFFECT or a damage/harm EFFECT.
Mod files mentioned in Article #9 1st Class Mod Support , can arbitrarily add more rules to this list!
As mentioned earlier, there are two types of commands per turn. We've covered the maneuver phase, almost entirely.
There is still the matter of collision triggered combat subsolves for things like bombs. We'll cover explosions and other combat stuff in the next article.
We'll continue talking about the turn lifecycle, and hopefully round out with a little diagram expressing the full journey of player turn input clearly.