Concurrent Action Tactical Simulation
Andrew ‘Fulby’ Campbell
Last updated: 2006-07-15
Criteria Of The Concurrent Action Tactical Simulation
Features Of Sequential Action Turn Based Games
Disadvantages Of Sequential Action Turn Based Games
Problems To Be Overcome When Retaining Concurrent Actions
Time Taken For Player To Update Orders
Advantages Of A Concurrent Action System
|
TB |
Turn Based. In this document this abbreviation generally refers to game systems that only allow only sequential or serial actions in the game world. |
|
CA |
Concurrent Action |
|
AP / TU |
Action Point / Time Unit |
|
Game Time |
Time that elapses in the simulated game world when it is active |
|
Turn |
In a sequential TB game, the main phase (i.e. not Interrupts) where one player gives order to his units. |
|
Round |
One Round consists of each side having one Turn |
|
Human/Player Time
|
Time in the real world |
|
Visualised Game Time |
When the user is using the temporal visualisation tools to view the history of possible future of the game world, the visualised game time is the time that the user is currently viewing. |
|
Primary Assessment |
Initially assessing a unit’s history and current situation. |
|
Delta Assessment |
Assessing the change in a unit’s situation due to it performing an action. |
|
Focus |
A unit has focus in a TB game if it can perform the next action A set of units have focus if any one of them may perform the next action. |
|
Unit |
The player controls Units within the game world; they are usually soldiers of some kind. |
|
Event |
A localised change in the game world (barrel exploding, wall collapsing) or a unit action. |
|
CoS |
Change of Situation - A perceived change in the game world as observed by a unit. |
This document is a summary of methods that may enable detailed squad level tactical play in a game world which allows actions and events to occur concurrently and continuously. This type of game is designed to challenge the player’s intelligence and not their perception or reactions.
There is a lot of comparison to sequential TB games such as X-COM/UFO and Jagged Alliance 2 (JA2) because it is generally accepted that these currently provide the best squad level tactical play. The CA system is intended to capture the precision and depth of sequential TB tactical games without limiting the game world to a sequential action model where only one unit can be active at any point in game time.
An alternative description of this system would be “simultaneous turn-based with a dynamic turn length”, as it incorporates the more believable behaviour of simultaneous TB games without the limitations imposed by having a fixed turn length. In a CA system, the length of each team’s turn is determined by the events in the game world. When the combat situation changes, such a unit comes under attack or sees an enemy, the current turn for the unit’s team ends and the orders phase of a new turn begins. Each team starts and ends its turns independently as their own combat situations change. This avoids the problem in simultaneous TB where the player must plan out X seconds of actions for each unit, and then has no interaction with them regardless of what happens in the game world.
The sections of this document often refer to other sections either before or after them. Repeat reading of the document is advised to gain a full understanding of the concepts described.
Criteria Of The Concurrent Action Tactical Simulation
The following list describes the principles that the system is based on. These can be thought of as the minimum requirements for a CA style combat system.
Game Time
1. Changes in the game world are caused primarily by progression of game world time.
2. Progression of game world time is not dependent on units performing actions.
3. Physical actions of units require a period of game world time to complete.
4. Game world is not limited to one unit performing an action at a time.
Pausing
1. Game world can be paused without restriction on how long game world is paused.
2. Game world can be paused without restriction on game world state when a pause can occur.
3. The player does not have to observe every situation constantly; instead the game world should pause automatically when the player needs to examine a new situation.
Player Interaction
1. Player is limited to a defined set of interactions with the game world, such as updating unit orders.
2. The player may interact with the game world in this way while the game world is paused.
3. The game world is paused and the player prompted when a unit completes its order queue. Units will only be idle if the player specifically orders them to be.
4. The units in the game world have little or no autonomy, the exception being for game play reasons, such as a unit panicking.
5. Unit orders can be explicitly displayed to allow the player to confirm current orders.
Features Of Sequential Action Turn Based Games
These are some of the features of sequential turn based tactical games that I would like a concurrent action game to retain and improve upon.
One of the most common reasons stated for liking TB games is that they do not rely on the player’s reactions, only on his intelligence. The player only has to give orders to one unit at a time, and is not rushed into giving those orders. He has unlimited time to examine the known state of the game world and plan out his tactics and strategy. One of the consequences of this is that the game can be balanced to the player’s best strategy, rather than the one he came up with quickly and managed to enter before it became invalid.
Sequential TB games still rely on the player’s perception to an extent, for example in X-COM 1 the game did not allow you to replay the opponent’s move, so it was a case of carefully watching the screen in case one of your units spotted a projectile. It was then up to the player to work out where the projectile came from, even though it was the unit who saw the projectile. I would prefer that the unit’s perceptions or other statistics decided how well it could estimate where the projectile came from, and the player received that information instead of depending on his own perception and reactions.
The unhurried nature of TB games allows the player to consider his units individually and allows for many possible actions. In real time games without pause with orders where the player controls multiple unit – such a RTS games – the player is limited by how quickly he can think of a plan and issue orders before the situation changes.
The units in games such as RTSs have a few basic actions, such as attack and move, and tend to have little if any difference between units of a particular type. I class this type of unit as a simple unit. Even if they had more actions and individuality how would the player issue them specific orders while the game time is constantly progressing and therefore changing the combat situation? By contrast TB units have many possible actions and tend to be more distinct than RTS units. As the game world in a TB game only progresses when the player allows it to (with the exception of watching enemy turns) the player can consider each of his units carefully and without a time limit, allowing for complex units with individual statistics, inventory etc.
Each unit is important in squad level TB games, and the individual actions each unit performs are also important. The player must consider each action carefully because it will have a sizable impact on the player’s success in the game. A single missed shot can mean the difference between killing an enemy and that enemy killing a friendly unit. The player’s units are likely to be shot if not behind adequate cover, so the player must consider each unit’s movement to minimise the risk while maximising the benefit of the action.
The player is free to consider actions for any length of time and gives order to each unit individually, and thus the game does not have to make allowances for the player making a hurried decision or from being occupied with one unit while another needs new orders.
Being able to give orders individually means each unit is given orders tailored to its unique situation. The unit’s situation is still dependant on the state of the squad, and the player must take this into account when giving orders.
This feature is heavily dependent on the game’s content. Consider two weapons, one which once every five seconds and does 100 damage, and another which fires twice a second doing 10 damage each shot. These two weapons have the same rate of damage but with the second the individual shots are not as important. The player does not have the same inclination to watch ten shots as he does one shot.
Comparing real time with pause games such as X-COM: Apocalypse and UFO: Aftermath to the original X-COM, one can see that in X-COM individual shots mattered far more. In the other games the player would order a unit to attack an enemy and not be concerned with individual shots because they were not important enough. In the game Brigade E5 on the other hand a single shot can kill a unit so the player has far more reason to carefully consider every shot.
Disadvantages Of Sequential Action Turn Based Games
These are some of the disadvantages of sequential turn based tactical games that the concurrent action tactical simulation should lessen or remove.
The player cannot control units unless the game system gives you focus. While each unit will act only as the player orders it to (except for gameplay reasons such as panicking), the player has little control over whether a unit is available for control at a particular moment.
Another way of putting it is that the game world does not change for the duration of action. So even if action 1 takes many more APs than action 2, as long as the unit with focus has enough APs for action 1 he can perform that action, regardless of the current combat situation. This can be demonstrated with the “Unit running past a doorway/window” scenario:
This example assumes:
Unit A intends to run past a one square wide window outside a room which has enemy unit B inside. If it takes 1 AP to run from one square to an adjacent one, then A will be visible from inside the room for at most 2 APs, 1 AP to move to the square in front of the window and 1 AP to move out of it to the next square.
When A becomes visible from within the room B may get an Interrupt (as in JA2) or Opportunity Fire (as in X-COM) if it has enough APs; in this example it does. B now has focus, and because of the sequential model of the game world nothing will change until B’s next action is complete. Firing B’s weapon takes 5 APs for a snap shot and 10 APs for an aimed shot. B may fire a snap shot at A using 5 APs, or may fire an aimed shot (10 APs) because A is moving, which lowers B’s chance to hit it. B fires a shot at A, which takes 5 or 10 APs. Focus is passed back to A (with opportunity fire this happens automatically, with an interrupt B may have enough APs for more shots or to move himself). A then chooses to continue on his original plan and runs to the square beyond the window.
The point is not whether B hits or misses A, or that B had more than 5 APs or 10 APs because it hadn’t moved that turn, it is that the game disregards how many APs B uses against A. A was only visible for at most 2 APs yet B used 5 or 10 APs against A, or more if it had them available and B could perform more than one action, as happens often with JA2 Interrupts. Using JA2’s timing system, A was visible to B for approximately 0.5 of a second, but B used at least 2.5 seconds worth of actions against A.
The sequential TB model in this example does not correctly account for the current combat situation. The abstract timing model used in TB fails and this decreases the tactical depth of the game. In this case the depth that is removed is the ability for a unit to only be visible for a short period of time, thereby reducing the chance of it being shot.
The difference between one of the player’s units having focus or not is enormous, because that unit is guaranteed to complete its next action, no matter how many APs that action takes or the current situation. All other units are frozen within the game world. The result is that obtaining focus is overly critical to success or failure, yet the player has very little control over this aspect of the system.
The main aspect of sequential action TB games that I would like to remove is that the tactics are more do to with using the AP/turn/round system than with the game world scenario. A poster on the Laser Squad Nemesis forums referred to this style of playing as using gameics. The difference between gameics and tactics is that gameics are not related to the game world and are instead a result of the control system. Unfortunately gameics cannot just be ignored in favour of tactics as they are critical to playing the game well.
The main gameic in sequential TB games is to get your units in position while having enough APs to attack the enemy in their turn when they come into view. The advantage of this method is that the player’s units are normally well protected and/or hidden while the enemy is often in a walking posture and clearly visible. This creates the effect of making APs “worth more” in the enemy’s turn than the player’s because the combat situations that arise will be in the player’s favour.
The turn/round system removes the gameplay further from the combat situation because of the need to have APs available to perform actions which then occur instantaneously with respect to the rest of the units in the game world, rather than how real time worlds work where an order is given which then takes time in the game world to complete during which other units are also active. The practical result of this is that the two combat situations with unit locations, inventory, skills etc all identical will be dramatically different depending solely on the number of APs each unit has.
In many players’ opinions the sequential nature of the game world breaks the suspension of disbelief by creating bizarre situations. The “Running past a doorway/window” scenario above is one such example but most “RT vs TB” threads contain them. Many of the unusual behaviours are caused by the need to use gameics rather than tactics.
Some argue the realism has no place in games, but whether you’re fighting off an alien invasion, liberating a third world country or battling goblins and ogres, the player implicitly assumes at least an approximation of real world physics and behaviour. If the player orders a unit to fire a rifle he expects the rifle to fire a bullet or jam or be out of ammo, because that is how the real world works. Realism is what you start with and work away from for reasons of technology, development time and gameplay, not something that is added in small portions.
The limit I would place on realism is when it would interfere with the desired gameplay. For instance plasma weapons and gravity control are currently unrealistic, but in a sci-fi game removing these could decrease enjoyment of the game. It is deciding which aspects of the real world should be or need to be ignored – not which should be included – that is important, not a blanket ban on all things realistic.
Problems To Be Overcome When Retaining Concurrent Actions
If the game world isn’t to be limited to one action per game moment then there are problems which need to be resolved to the make the system as enjoyable as possible.
In a TB game only one event occurs at a time, so the player almost certainly witnesses it as it occurs, although most TB games still challenge player perception as they do not have replay controls. In a CA game each unit performs actions concurrently in game time, so a unit cannot complete an action without the other units also performing their actions.
As multiple actions can occur simultaneously in game time in separate locations in a CA game, some form of ‘temporal visualisation’ is needed so the player can examine past events he has not witnessed. When this is combined with a method of automatically pausing the game when important events occur – such as already happens in sequential TB games – the CA system removes or lessens the requirement for the player to observe every event as it happens. The player can watch the actions leading up to an important event in full after the game has automatically paused.
A more subtle problem may arise due to using a concurrent action model of the game world. In a game where the game world is paused much of the time, the player may experience a lack of continuity during play. In sequential TB games, the player normally concentrates on one unit and orders that unit to perform up to a turn’s worth of actions, watches the result, then moves onto the next unit. With a CA game, the player will be moving from unit to unit as each one requires new orders, and as such will not be able to watch each unit perform its actions uninterrupted.
However players of sequential TB already have to deal with similar disruptions. A unit may be interrupted by an enemy, in which case the enemy performs his actions and then the player regains control, or the player may perform an action with a second unit (and third, fourth and so on) before continuing on with the first. The same effect occurs in CA. The player issues orders to unit A and continues time in the game world. While observing unit A perform his action unit B interrupts the player with a request for more orders, automatically pausing the game world. The player assigns unit B his new orders then continues observing unit A.
By automatically pausing the game world when a unit completes all assigned orders (or cannot complete them for some reason), the player does not have to continually check each unit to ensure they are performing actions. This also has implications for game balance, because the game does not have to account for the delay between a unit needing orders and the player noticing/remembering that unit and then manually pausing the game world.
An important issue to remember is that the CA system should negate or lessen the requirement that the player observes every action as it initially occurs; the player should ideally be able to watch any part of the game world without loosing control. While this may not be possible (no TB game has provided this, yet they are still popular with players who regard this as a positive feature), the design should aim to lessen the requirement for the player to continually check each combat situation every moment for fear that something is happening that the game world won’t automatically pause for.
Using the temporal visualisation tools to replay past events automatically in movie-style scenes and create “bullet time” style scenes may offset the loss of continuity. How much different players are affected by this is dependent on the player.
My current solution is three-fold:
The purpose of these is to lower to time taken by the player to assess the current situation and make informed tactical decisions.
(Not in order of importance)
I’ve seen in many discussions in which participants assume many things about what they are discussing, and the other participants do not use the same assumptions. This can lead to a great deal of confusion. This section lists my assumptions about the type of game I am dealing with in the hopes of limiting or avoiding such problems.
This system allows the player to set a sequence of actions for a unit to perform. The unit will perform the actions, using the autopause system to notify the player when an unexpected Change of Situation (CoS) occurs. The player can change which CoSs he wants to be notified of, to minimize unwanted interruptions from CoSs he expects to occur.
In most situations the order queue would contain 1-5 actions. Units in combat would most likely only have 1-2, whilst units performing plans unlikely to be changed (such as searching an office or taking a long route across the map) could expand to as many actions as necessary. This would remove them from the assessment process for the duration of the activity, making the player’s management of his units easier.
It is important to stress that the player should not spend too much time creating the best order queue for a predicted situation. The order queue is only for actions which are going to be performed barring an unexpected change of situation, and should not be used to try and plan for what might/should happen over a significant period of time. For example in a combat situation order queues such as:
should be used, not:
because the combat situation will have probably changed significantly after the first or second action; the subsequent actions will very likely not agree with the player’s new plan at that point.
A few none-action orders could be included, such as a synchronisation order. The player assigns multiple units a Sync order with the same number (Sync1, Sync2, etc) and each will suspend their order queue when they reach it and act as if given a Wait order. Once every unit with that Sync number reaches the Sync order it is considered complete, and they all continue with the next order in their respective order queues. Units may not start their next order at precisely the same time for gameplay reasons and to preserve immersion in the game, instead it could depend upon each unit’s reaction statistic.
Another none-action order may be the “Cancel Order” order. This cancels the order which the unit is currently performing. Planned orders are simply deleted from the queue but the active order may not stop immediately. The unit may not be ready for a new order instantly, in which case it will take some time to stop the action as it was obviously not prepared for the cancellation. Cancelling an order may instead set the Order to call it’s Cancel stage when the game world continues, which will determine how long it takes for the Order to cancel and what effects that has.
The order queue list should incorporate as much functionality in as few mouse clicks or key presses as possible. It is vital that the player can create, modify and remove orders quickly. The process of modifying the order queue could be simplified by only allowing addition or removal of orders at the end of the queue.
The order queue as seen by the player would be similar to a list box and contain:
The list of orders would be items such as Walk To, Quick Shot, Aimed Shot, Pick Lock, Crouch, etc. Selecting an order while the temporal visualisation subsystem is showing plans should highlight the order in the game world. If the plan is not shown it may still be useful to display just that order.
The displayed time would be relative to the current game time rather than being an absolute time, though being able to switch between relative and absolute timings via an interface button may be useful. Before an order is performed the order queue displays the probable time for completion, and afterwards displays the exact time the action took. The start time for an order is the same as the end time for the previous order.
While displaying the probable time, an icon similar to a tilde (~) would show how stable the predicted time is. An action which is almost certainly going to take the displayed amount of time would display an icon which is nearly a straight line (--), while an uncertain time would result in a very curved icon (/\/). This is a way of showing the player that predicted times are not guaranteed, while also providing information about how reliable the displayed time is likely to be in an intuitive way.
There are two important pieces of information to display regarding the status of each order: whether the order has been attempted and its result. This could be done by colour-coding the order text into the following groups:
|
Not Attempted Yet |
Grey |
|
Attempting Now |
White |
|
Completed-Failed |
Red |
|
Completed-Succeeded |
Green |
|
Could Not Attempt |
Yellow |
Colour-coding the order queue allows the player to see the status of the unit at a glance. He can tell which order is currently being performed and how successful the previous orders were. This may lessen or remove the need to use temporal visualisation to learn the unit’s recent history a lot of the time. If the player still needs to review the history he will have a better idea of what happened before watching it.
Completed-Failed occurs when the order was carried out but the desired result was not achieved, such as missing the enemy the unit shot at. Being able to colour-code the order queue like this requires that the game engine can determine whether an order was successful or not. If this proves too difficult within the development time for the game then a single Completed status could be used. The Failed/Succeeded status would aid the player but is not an essential part of the combat system.
A Could Not Attempt is for instance not firing due to running out of ammo or a weapon jam. It would also cover not firing because the enemy is already dead or not being able to reach a location when ordered there. A “Could Not Attempt Order” CoS would be useful for alerting the player, though more specific CoSs such as “Weapon Jammed” or “Out of Ammo” would be more informative.
The autopause should be configurable for the global observer and each unit/group so they only cause an autopause when an unexpected CoS happens (like having a CoS "Seen by Enemy" which is useful when a unit is using stealth but may not be needed or reliable enough at all times or for all units).
Changing autopause settings on any of the categories should be streamlined. If the player cannot quickly set the events he wants to be notified of, he will most likely either leave them all on causing frustration as the game autopauses for insignificant events, or leave them all off and have to manually pause frequently and examine every unit’s situation in minute detail to determine if anything significant has happened. Neither method creates an enjoyable game. On the other hand very few sequential TB games even have the option of changing autopause settings and it doesn’t appear to be an issue. The effectiveness of this system also has consequences for multiplayer CA games, where players would not be able to manually pause but instead rely on autopauses to end each turn.
Automatically changing autopause/CoS settings may be possible by using the order currently being performed, orders in the queue and the current combat situation as a guide. For instance the “Seen by Enemy” CoS would automatically deactivate after being triggered, and activate again when the unit thinks it is out of view of the enemy. The Seen by Enemy CoS would only work on visible enemies and probably only at close range as it would rely on what the player’s units could see of the enemy.
As an initial system I suggest a large pop-up dialog box with checkboxes for each CoS, so the player can easily toggle them. The window should be available with a single key press or mouse click from the main interface. The CoS list only needs to be set and then hidden, so placing it in a small list box on the main interface would be counterproductive. It would take up space all the time and only provide a small area to list the CoSs, causing the player to scroll through them at length. Neither should it be buried deep within the game options dialog alongside video and audio settings.
Further possibilities:
If changing the CoS selection for a group of units, player may be able expand a single CoS to change individual unit settings. This would display a list of unit names and their setting for the single CoS, but could switch to smaller pop-up window and overlay game world with Yes/No on the selected units for better relating the settings to the game world situation.
The CoS system is the basis of the autopause system for notifying the player of important changes regarding his units and the game world. It also forms part of the AI because it can notify the AI of CoSs as well, lessening the need for the AI to poll the game world to find important events. A CoS can be best thought of as a change in the world from the point of view of an observer. The observer is either a unit or the global observer that represents the sum of everything observed by the player’s units in the game world.
The CoSs for units should encompass every change that may be important for a particular plan by the player to succeed, such as an enemy entering or leaving its field of view, being shot at, being hit etc.
CoS settings may fall into a hierarchy: Global, Group/Unit and Order/Item. An option as to whether changes should be passed down to the next level should allow the player to set the CoS selections of a large number of units or orders easily when necessary.
The global observer would be used for higher level events, such as a new enemy appearing rather than a known enemy moving into a unit’s field of view.
Unit/Group level CoSs would consist of changes which affect individual units, such as a unit which is sneaking and is spotted by the enemy (this would depend upon a friendly unit seeing the enemy spot the sneaking unit). Unit/Group CoS settings may be more detrimental than useful as it complicated the system. The player must understand how global CoS settings interact with Group and Unit settings and there is much room for ambiguity here.
Order level CoSs would only be used for specific orders where an autopause on CoS would be appropriate. This level of the hierarchy may not be needed as a CA game should autopause after the last order in the queue just as sequential TB does. One possible order level CoS could be for firing ranged weapons. If a unit is ordered to fire at a mobile target, that target may have moved by the time the unit is ready to fire. An order level CoS specifying a minimum chance to hit would activate if the unit’s chance to hit the target lowered significantly. Presets at 90%, 60%, 30% and 10% would provide a range of options without slowing down the interface by requiring the player to type in the amount each time. Alternatively, the CoS could be “Chance to Hit Has Halved”, for example an 82% chance to hit is now below 41%. This takes different weapon usage patterns into account, as a sniper needs far better change to hit than a machine gunner causing suppression fire.
There could also be item specific CoSs. One such CoS could be a warning that a machine gun barrel temperature is too high. The player could set the level at which the warning is given from a few presets and if the temperature rises above that level a warning is given in the form of a CoS autopause. The war game Titans of Steel: Warring Suns uses such CoSs. CoSs like this should obviously be set to a reasonable setting by default so that players get the benefit without having to determine a good value themselves. This is important because novice players must see the benefits of such a CoS and they will not know what the best setting is until they have played the game for a while.
Order and Item level CoSs may be better listed on the main game window, as there will be only a few of them for any order and the player may change them more often than Global CoS settings. In this case when a machine gunner is given a fire order the “Chance to Hit Has Halved” and “Barrel Overheating” CoSs would appear in the list.
It is important to be aware that there is no "master list" of autopauses that can be used for every game. Instead the autopauses for a game must be based upon which changes of situation are considered important. Even though some Changes of Situation such as Enemy Sighted can be applied to most if not all games, others depend on specifics of the game world.
For example, in the AD&D role-playing game Baldur’s Gate 2 the player battles trolls, which can only be killed by fire or acid based attacks, and only after they have been knocked down from taking enough damage. Fire and acid based weapons and spells are generally rarer or less effective than other attacks, so are not used all the time. A good tactic is to attack normally, damaging the troll enough to knock it down and then switch to fire or acid based attacks to kill it. In this game world a “Troll Knocked Down” Change of Situation would be useful. Adding a “Troll Knocked Down” CoS gives the game designers two advantages. The first is the assumption that the player will order his units to switch to acid or fire based attacks as soon as a unit sees that the troll is knocked down, rather than after the player realises that the troll has been knocked down and presses the interface buttons/leys to switch attacks. In the latter case the game must allow for the unknown and unpredictable delay between the game event and the player’s reaction to it (after first noticing and observing it) as well as the unit’s time to change weapons; with TB-style autopauses only the unit’s reactions when ordered to change attacks affect the outcome, and not the player’s reactions.
The second advantage is that the player does not have to be watching the encounter continually, waiting for the troll to be knocked down. This allows for multiple combat encounters to take place simultaneously. Without CoS autopauses the player must try to watch every encounter constantly, which may mean that during development the game world will be designed to restrict combat to only one location at a time to avoid player frustration. While this wouldn’t be as great a problem in an RPG such as Baldur’s Gate 2, in a tactical game it could be a severe limitation to using diversionary attacks and other well established tactics.
This system provides methods which are used by the player to examine past and planned (future) events in the game world.
Temporal Visualisation adds complexity to the design of the game engine, specifically that not just the current state of the game world but the state at each moment must be available. Storing the complete state for every moment is far too expensive in terms of memory so a better solution is needed. I currently consider the best (and only viable) option to be where the engine records the changes to the game state over time as well as a small number of complete states, and can generate other states from these as needed.
The following are possible visualisations. While only Playback is required, the others could provide more efficient means to inform the player.
Visual replay of game world with VCR style controls, which can display either past events or an estimated version of future events based on current plans.
Include a quick button to go to previous time when the player gave orders to the unit, so the player can play back only events which he hasn’t witnessed yet. Playback gives an accurate account of the game world history, but may be cumbersome if the player has to keep “replaying” a particular time period to understand all the happened.
The problem with merely playing back the game world is that the player can really only concentrate on one unit or a closely placed group at a time, requiring the player to repeatedly playback the same section of time while watching different units and in that way build up a mental picture of what happened.
A time slider control would increase the usefulness, so the player could quickly set the displayed time. This would be better for moving to a specific time than using VCR style controls to move forward and backwards.
Display transparent single colour “ghosts” of unit’s prior movements, increasing transparency with age. Ghosts should be placed every X squares of movement, where direction changed or when orders changed. Age limit could be set manually by player, since last change of orders or show a fixed number of unit actions. The interface can display future movement in similar fashion, but in different colour to avoid confusion.
Display a line through each unit’s path or highlight map squares/cubes traversed, increasing transparency with time difference from current game time. A unit’s recent actions are visible and fade out the longer ago they were. Add glyphs to show unit stance (running, prone etc) at appropriate points. Same age limits and future movement options as Ghosts method.
With a Chaser visualisation, the past/future movement and action paths are displayed as lines overlaid on the map. A glyph is moved along the path from past to future, as if it were travelling along a rail. Where the path splits, for instance where a unit fires then moves, an extra glyph is created, one following the movement of the unit and the other the movement of the bullet fired. All the glyphs represent their entities at the same moment in game time.
The user can control the position of the glyph in game time or let it progress automatically at various speeds. Multiple units can have Chasers active; this would probably be linked to the currently selected units to simplify the interface, or a button on the temporal visualisation interface panel which toggles between Selected or All units. The Chaser visualisation allows the user to see which events occur simultaneously at a certain game time by moving the glyphs to that time, while seeing what happened before and after that using the paths.
Pulse paths are similar to Chasers but instead of a glyph the paths change opacity, being completely opaque and therefore very visible around the user-selected visualisation time (not the current game time) and becoming more transparent the further away in game time they become. As the user moves the visualisation game time the paths at that time become more visible. On automatic time progression the unit’s history and then future would appear to pulse across the map.
Pulse and Chaser visualisations could be combined to give the accuracy of the Chaser glyph which appears at a specific game time while using the Pulse’s transparency to hide paths not close to the visualised game time, making the visualisation more readable.
This would be used mainly for bullet and grenade paths. Display the path taken, with glyph traversing path to show direction and type of trajectory. The glyph would be a bullet symbol for hit with bullet, crossed-out bullet for miss and so on when showing historic paths.
For showing planned shots and when targeting, an accuracy indicator would be useful. A percentage over the target may suffice, especially for targeting. Either a circle outline at the destination perpendicular to the trajectory or a semi-transparent cone showing the probable path of the projectile would be useful. The area of circle/cone-slice would be scaled to represent where the shot will go say 75% of the time. This would be a very intuitive way of showing accuracy as the circle could be compared to the size of the target.
These would need a minimum of 2 colours, for past and future. It could also have different colours for player’s units and enemies, possibly also for friendly units, neutrals and world events (paths taken by falling pieces of wall etc). 10 colours are needed for Own, Friend, Neutral, Enemy, and World in the past and future. The game could use 5 colours with brightness deciding past/future if that were clear enough.
The player should be able to quickly select which paths to view, such as a 5x2 set of buttons to toggle past and future paths of each group, plus All/None Future, All/None Past, All On/All Off.
Certain actions by a unit may be allowed to overlap. Being able to fire whilst moving is the most obvious example, also firing two single handed weapons simultaneously and so on. To implement this generically (so it automatically works with all viable combinations) every action has a set of appendages/senses it requires (examples shown below). Actions can be combined/compounded as long as they do not both require use of the same limb etc. Extending this to exclusive (Ex) or shared (Sh) requirements allows two weapons to be fired at once, but at an accuracy loss from using ‘shared resources’. Implementing shared components may make the system too complex however, in which case different actions should be defined, one with exclusive use and another with no use.
|
Walking |
Left Leg(Sh), Right Leg(Sh) |
|
Running |
Left Leg(Ex), Right Leg(Ex) |
|
Moving Shot (Rifle) |
Left Hand(Ex), Right Hand(Ex), Eyes(Sh) |
|
Quick Shot (Rifle) |
Left Hand(Ex), Right Hand(Ex), Left Leg(Sh), Right Leg(Sh), Eyes(Ex) |
|
Quick Shot (Left Pistol) |
Left Hand(Ex), Eyes(Sh) |
|
Quick Shot (Right Pistol) |
Right Hand(Ex), Eyes(Sh) |
|
Prime Grenade (Left Hand) |
Left Hand(Ex), Right Hand(Sh) |
|
Aimed Shot (Rifle) |
Left Hand(Ex), Right Hand(Ex), Left Leg(Ex), Right Leg(Ex), Eyes(Ex) |
A quick shot becomes less accurate whilst walking due to shared requirements. When running only a moving shot is possible which would have very low accuracy. The aimed shot needs exclusive use of most of the unit’s appendages/senses (full concentration, a steady stance and so on).
Priming a grenade held in the left hand needs shared use of the right hand (or maybe the teeth J). Extending the appendages/senses requirements to states as well as actions creates something like “Holding Pistol (Right Hand) - Right Hand(Sh)”, so the grenade could be primed whilst holding a weapon in the other hand but not when firing it.
The specifics of this system can be hidden from the player as long as the resulting combinations were logical. The player would only see whether the actions should overlap or be performed sequentially. The ability to selectively compound actions may not be given to the player. Instead of ordering a unit to shoot his left pistol then his right pistol and then compounding the actions, the user would choose a dual fire order. This order would internally act as the left and right firing orders compounded.
A possible implementation problem with this system would be how to deal with interruptions to the unit when both actions were being performed. In my design for such a tactical system the results of being interrupted (such as coming under fire, being hit or the order being cancelled) should be customisable depending on the order. For instance a unit being shot while running could stumble and fall, while a unit coming under fire while defusing a mine could set it off by mistake or have to start defusing it from scratch. This behaviour would be attached to the game code for the order, each custom behaviour tagged with the events which should activate it.
The problem comes when multiple orders are active at once, as an event may have two or more behaviours to choose from. Activating all the behaviours is one possibility but could difficult to implement. Consider a walking, shooting unit which is hit by enemy fire. Being hit while walking may cause the unit to drop what he is holding. Being hit while shooting can cause the unit to fire in an unexpected direction. The unit cannot drop the weapon and fire it at the same time so if this scheme were used the game would need some way of resolving such conflicts.
As an aside, behaviours from interrupted orders could replace a default set of behaviours for the unit so only those custom behaviours need to be added to the order code. Also multiple behaviours could be stored for the same event and one picked at random. X-COM demonstrates a specialised version of this - a unit with low morale may freeze to the spot, run away or fire indiscriminately. These could all be default behaviours for a “Low morale check” event. As soldiers improve they inherit the default behaviours for their rank, so a Captain has less chance of panicking then a Rookie.
Potential item creation/deletion/modification augments the order queuing system by allowing orders to be created which require items not yet in existence or not in the correct state. A simple example is when one unit passes an ammo clip to another. When the first unit receives the Pass Item order, a Receive Item order is added to the second unit’s order queue if it can accept the item, otherwise the Pass Item order is rejected. The second unit can use the ammo clip in orders subsequent to the Receive Item order and the clip is removed or greyed-out in the first unit’s inventory.
This raises a problem if the second unit already had a plan that would be busy when the first unit passes the item. If this is the case the game engine should add a Wait order to the first unit before the Pass Item order to make the Pass and Receive match, and notify the player of this extra order. This wouldn’t need anything as disruptive as a message box; instead displaying the time for the extra Wait order in a glowing font to highlight it would probably be sufficient.
Time Taken For Player To Update Orders
When the game world is active, it would advance mostly at 1/2, 1/4 or maybe even 1/10 of a game second per human second but with 1 game second per human second available and greater speeds for fast movement.
In a normal map, I would expect the game world to only be active from 5% to 15% of the time the game is played. The paused time would largely be spent deciding order queues for the units which need them, such as allowing for a new enemy or a change in the environment (like having the wall your unit is hiding behind fall down).
I tried to do some comparisons of the human time taken for Primary and Delta assessment in TB and CA systems. The difficulty is that there isn’t an exact match to the Primary and Delta assessment times. The closest would be assessing a group of units having just assessed others at a different location for the Primary assessment, and assessing a group without leaving them for the Delta assessment. It doesn’t allow for a direct comparison however because the Delta assessment is affected by multiple actions so would take longer even if somehow every other aspect of the game where the same.
I think the best measurement for how ‘tedious’ a CA game would be depends on:
1. The time taken to produce an order queue starting from a blank queue
2. The time taken to change an existing order queue
3. The ratio of situations when a queue works to when it needs changing
The production time (1) is broadly equivalent in meaning to Primary assessment in TB where you plan the AP usage for the turn. Delta assessment is when the player has to change a plan (2), but the total time spent in Delta assessment in a game would be multiplied by the percentage of changed plans compared to all plans.
It strikes me as being similar to the CPU pipelining with branch prediction problem, where the CPU gains speed as you add more stages to the pipeline, but that increases the “down time” when the wrong branch is taken because the pipeline contents have to be “rewound” through the pipeline to correct the mistake. If a long order queue works it saves the player from the Delta assessment time, but the longer the queue the lower the probability it will complete without changes needing to be made.
Also none of that is strictly true because the Delta assessment time is different from the Delta correction time. Simply reviewing a queue to check it is still acceptable takes less time than changing it, the same as continuing with a plan in a TB game takes less time than changing it.
The best way of combating the order pipeline problem requires that the player be able to change order queues very quickly, and the queue needs a certain resilience so adding an extra order in the middle will not require the whole queue to be recreated. Also the player should be encouraged to use short queues or single orders in volatile situations.
Advantages Of A Concurrent Action System
Apart from creating a deep tactical game of its own merit while avoiding the discrepancies involved with sequential action TB games, a concurrent action system could provide various advantages things over a TB one. Some of these are listed below.
One of the most important differences between sequential TB and CA game systems is a CA system’s ability to implement temporal or time-based tactics. As an example of a tactic possible in CA but not in sequential TB, the following describes minimising a unit’s temporal profile to the enemy and how that aids in distraction tactics.
Even beginner players are aware of the concept of minimising a unit’s (spatial) profile to the enemy. Crouching behind a low wall causes less of the unit to be visible to the enemy or the enemy’s assumed direction is an example of minimising a unit’s spatial profile. Both sequential and CA systems can implement this tactical ability, though its importance and effectiveness in individual implementations varies.
Minimising a unit’s temporal profile is the same concept but deals with the time a unit is visible to the enemy. Reducing the time a unit is in the enemy’s sight means the enemy has less time to react to the unit and take offensive action against it. In a CA system the player always has control over his units (unless control is removed for game play reasons such as a unit panicking). This means the player can order a unit to step out from behind cover to view an area and step back after a short amount of game time. By only being visible a short time the player lessens the risk to the unit: enemies seeing it require time to bring their weapons to bear and fire, which may allow the friendly unit to step back behind cover before it is attacked. It also reduces risk even if the enemy fires because the enemy may only have time for a quick shot and not a longer, better aimed one.
This concept provides tactical depth in many situations, such as a unit distracting a group of enemies just before an attack by an assault group. In this scenario the distracting unit moves to a position away from the assault group and makes itself visible to the enemy group, trying to provoke them to attack. Each enemy then either ignores the unit or turns and fires upon it. The distracting unit steps back after a short time, working on the assumption that the enemy will not have enough time to attack or only attack with inaccurate shots. This is by no means certain – an enemy which is already covering that location will require far less time to fire than an enemy facing a different direction. Also the distracting unit may panic at the sight of the enemies and be unable to move, which allows extra time for attacks against it.
At this point a number of the enemies (hopefully all of them) will be turning to face the distracting unit and preparing to open fire. The player’s main assault group is at a different location, so the enemies will be turned away from the direction the assault force will attack from. The player orders the assault force to break cover and attack the enemy, while the distracting unit should now be moving back behind cover. The distraction performed by the unit has made the enemy less well prepared for an attack from the direction of the assault group, resulting in a higher chance of a successful assault with only a small risk to the distracting unit.
This tactic is not supported properly in any existing sequential TB system. Once the distracting unit steps out from cover the game system determines whether it or an enemy performs the next action. If the distracting unit gains focus, then the enemy has spent no APs and thus the distraction will not have helped the assault group. If one or more of the enemies get to act, then those actions will complete regardless of how long they take. Neither result allows for the tactic of minimising his unit’s temporal profile in anything other than in the crudest terms.
The only outcome where the enemies use up APs but do not fire upon the friendly unit is where the enemy gains focus, turns to face the unit then looses focus. This result is the best a sequential TB system can provide for the scenario but is poor in a number of ways:
More importantly in the long term view of tactical games, changing a sequential TB system to allow time-based tactics to work as consistently and authentically as they do in a multiple action system results in a multiple action system instead of a sequential one. The basis of sequential TB is that one action is performed at a time and in its entirety, while time-based tactics rely on multiple units acting at the same time. Some solutions to solve the problem with sequential TB suggest having every unit gain one AP simultaneously and “save up” for actions while every other unit also saves up. This way the distracting unit steps out using 1 AP, at which point the enemies start saving up for a fire action of for instance 4 APs (perhaps first spending 1-2 APs on turning). This allows the distracting unit to step back before those APs have been issued by the game system. Such a system may use the terminology of sequential TB but it is a multiple action system at its core simply counting in APs instead of seconds.
Distractions are by no means the only scenario dependent on temporal tactics. A scout unit can duck back behind cover before being fired upon or only risk inaccurate snap shots from enemies. A fast unit can outdraw an enemy, knocking his aim off before he can fire, or fire a snap shot and move behind cover while the enemy is still making an aimed shot. Defenders could cover a particular location on the assumption an enemy will appear there, lowering their time to fire. This would greatly increase their chance to successfully attack a target appearing there, but at the cost of being less aware of their surroundings and growing tired from holding the weapon in firing position.
Sequential TB systems provide for minimising a unit’s spatial profile but not its temporal one, yet both these abilities are among the most important in combat. It’s not that sequential TB is missing the single tactic of minimising a unit’s temporal profile - it’s that sequential TB is missing a fundamental tactical element from which tactics themselves are built.
A CA system can have more depth than a sequential action system due to the player having to account for enemy actions while planning his own side’s actions. In a sequential action game the player’s choice of next action is decided by the state of the game world at that instant, the amount of APs left and what the enemy may be able to do after the action is complete. It does not include what the enemy may do while the unit is performing the action because the enemy is not allowed to do anything until the action is complete.
Reloading a weapon in a sequential system costs APs and possibly the chance of an interrupt afterwards, but in a CA system the player has to consider what the enemy will be doing during the reloading time – they could be storming the unit’s location, setting up better firing positions or preparing to throw a grenade. In a sequential system the enemy cannot do any of these things unless they interrupt after the reloading action is complete, and in every existing system they cannot interrupt unless they can see the reloading unit. This feature of a CA system brings much more tension to the game world as simply being out of sight does not limit the enemy’s ability to act.
A CA game avoids the dependence on gaining focus as every unit can be given new orders at any time. The time length (AP cost) of orders is also more important than just determining how many APs will remain after the order. These combined means the player must deal with what the enemy is doing while his own units are performing actions and plan accordingly, something that is missing from sequential action TB games.
Combined unit actions are another tactical element that can be better simulated in a multiple action system. This could allow for things such as confusing the enemy by storming a room from every direction. In programming terms this could be done by making the units aware of Points of Interest (PoI), such as seeing movement or hearing a door opening. A single PoI attracts the attention of the unit, but when confronted with multiple PoIs they get confused and react slower, fire less accurately and so on, which can give that side the advantage needed to be successful. Units with better reactions and perception would be less affected by multiple PoIs.
In sequential TB this sort of tactic relies on the interrupt or opportunity fire system, which the player has no control over. If the first friendly unit moving into the room is interrupted then the enemy acts as if he were being attacked by a single unit and not a group. Due to the sequential action system he will always complete his next action. In most sequential systems there will be no limit to the number of APs he can spend on his next action except his internal AP count. In CA he can always perform actions but that does not prevent other units from acting, so they can enter the room and affect the enemy before he completes his action.
In a sequential TB game, although the AP cost of an action varies, this is internal to the unit. In game world terms the length of the action is limited to a small number of options. These are Instantaneous, End of Turn and End of Round.
The majority of actions are Instantaneous in the sense that the game world changes from one state before the action to another state after the action and no other units can act during this period. Although the player may watch an animation of the action this is just for his benefit. No time passes for the non-acting units in the game world (they don’t expend APs) so on their personal time-lines the acting unit’s action is instantaneous.
See the Definitions section for this document’s usage of the terms Turn and Round. An End of Turn action is Instantaneous but causes an effect at the end of that side’s turn (but before the next side’s turn). The grenades in X–COM 1 are an example of this – when used with a timer of 0 they explode after the player ends his turn but before the alien turn begins. An End of Round action occurs after all the sides in the game world have had their turn for that round.
In contrast, the length of an action in a CA system has a far greater range of choices. An action may take any non-negative time as its length (or be classed as infinite) instead of the three possibilities in sequential TB. Units act concurrently – if an action takes 3.6 seconds for one unit all other units can act during this time, so unlike AP cost in sequential TB, the time for an action has an effect beyond how many APs remain after the action.
Whilst environmental effects can be used in a TB system, the CA system with its independent game time could allow for better continuous incremental changes to the environment. Whether it would add anything tactical to the game would depend on the designers. Effects such as fire, moving elevators/lifts, conveyor belts, etc can be approximated in TB but have to either update instantly or at the end of a turn/round.
I hope you have found this analysis interesting. It hopefully shows some ways to make a detailed tactical simulation which avoids the disadvantages of a sequential action game world.
Please e-mail me at fulby 69 at hotmail if there is something you would like expanded on in the next version or could be explained more clearly.