Targeting vectors of weapons reveal the true positions of enemies.
Posted: Wed Oct 04, 2023 6:48 pm
Procedure to reproduce
Run the attached scenario as side "aaa".
Make sure that the "targeting vectors" map option is set to "all".
When the submarine's position becomes known with adequate accuracy, command the ship to attack the submarine using an ASROC.
Optionally, perform this procedure in the mission editor and toggle god's eye view on and off to verify that the position being revealed by this issue is in fact the true position of the submarine.
This procedure is not intended to produce the most tactically dramatic manifestation of this issue; it is intended to illustrate the concept with relative simplicity and reliability.
Expected behaviour
No feature of the game should reveal to the player the positions of units not detected by sensors whose output should, by the rules of the game, be available to the player.
Similarly, no feature of the game should reveal to the player enemy positions of greater accuracy than is available from such sensors.
There exists no datalink between the ship and the torpedo dropped by the ASROC through which any information from the torpedo may be delivered to the player.
Actual behaviour
When the torpedo delivered by the ASROC detects the submarine, a targeting vector from the torpedo to the submarine is displayed. This targeting vector does not point toward the approximate position of the submarine as determined by sensors available to the player. (See figure 1.)
To make things worse, the true position of the submarine continues to be revealed in this way even when the submarine is no longer detected by the torpedo. If the torpedo misses, re-attacks, and is unable to reacquire the target, its targeting vector continues to reveal the true position of the submarine. This is, as shown in figure 2, despite the submarine being far outside the detection range of the torpedo's seeker.
This strongly suggests that this targeting vector does not even point to the position of the submarine as determined by the torpedo using its seeker. It points to the true position of the submarine.
Commentary and opinions
It is of course possible, and indeed probably not too difficult, to specifically fix this issue. For example, targeting vectors of non-datalinked weapons may be hidden regardless of settings, and those of datalinked weapons may be modified to point to estimated positions of targets instead of true ones.
However, in my opinion, the behaviour described in this report suggests a deeper architectural issue in Command. The fact that such behaviour is possible at all shows that there is no systematic decoupling between the components of the game which present information to the player and those which contain information about underlying reality. I do not write this with any bad feelings: this trait is arguably an unsurprising consequence of Command's developmental history; as far as I understand, Command is distantly descended from a mission editor, an application in which there was no need for such decoupling.
However, in Command as it exists today, exactly what information is and is not available to the player is of central importance. What is shown to the player about detected objects should strictly be a function of the data generated by sensors available to the player; any exception to this[1] is, by definition, a breach of realism and of the game's design intent. I cautiously propose that, in the longer term, the architecture of the game should explicitly reflect this.
One way to do this is to present tactical information to the player through a software component which is only supplied with information which should be available to the player. For example, the game may be explicitly subdivided into several modules with limited and explicitly defined forms of allowed interaction between them; let us consider, in a very simplified example, four modules: a kinematic model which determines and maintains information about the true positions and states of objects, a sensor model which determines information about what every sensor perceives, a communication and sensor fusion model which determines what cumulative information is available to the player, and a display module which visually presents that information to the player. The kinematic model sends information about reality to the sensor model. The sensor model converts this into sensor output messages, which are sent to the communication and sensor fusion model. The communication and sensor fusion model determines what kinds of fused tracks should be presented to the player and sends messages describing these to the display module. Finally, the display module, which sees and knows nothing except the contents of the fused track description messages it receives from the communication and sensor fusion model, draws representations of these fused tracks to the screen.[2] In such an architecture, the kind of behaviour displayed in this issue would be architecturally impossible.
I remark with optimism and hope that what I am proposing does not seem too difficult or too divergent from the recent developmental direction[3] of Command. Considering the features and general excellence of Command in its current form, it would not be necessary to implement any new simulation or user interface functionality to accomplish any of this. Instead, the excellent functionality which already exists may be rearranged and adjusted according to explicit specifications of information flows between software components. The software would thus better reflect the concerns of the problem domain it simulates: emphasizing explicit representations of information flows would better model tactical situations in which what information flows do and do not contain is a central issue of interest.
[1] with the obvious exception of deliberate exceptions such as "automatic detection"
[2] I have much more to say about this. However, because this document is ultimately a bug report, I use a simplified example and avoid extensive elaboration.
[3] For example, I was quite delighted by the recently announced (https://www.matrixgames.com/forums/view ... 1&t=395516) plans for a communication model which situates the player on a specific unit and accounts for the quality of communication links instead of giving the player immediate perfect access to all information the player's side can perceive. This clearly consistent with the kind of architecture I propose and the spirit in which I propose it; such work would form what I call here the "communication and sensor fusion model". More loosely, I appreciate the tendency toward preventing the player from seeing what the player should not see.
Figures
Run the attached scenario as side "aaa".
Make sure that the "targeting vectors" map option is set to "all".
When the submarine's position becomes known with adequate accuracy, command the ship to attack the submarine using an ASROC.
Optionally, perform this procedure in the mission editor and toggle god's eye view on and off to verify that the position being revealed by this issue is in fact the true position of the submarine.
This procedure is not intended to produce the most tactically dramatic manifestation of this issue; it is intended to illustrate the concept with relative simplicity and reliability.
Expected behaviour
No feature of the game should reveal to the player the positions of units not detected by sensors whose output should, by the rules of the game, be available to the player.
Similarly, no feature of the game should reveal to the player enemy positions of greater accuracy than is available from such sensors.
There exists no datalink between the ship and the torpedo dropped by the ASROC through which any information from the torpedo may be delivered to the player.
Actual behaviour
When the torpedo delivered by the ASROC detects the submarine, a targeting vector from the torpedo to the submarine is displayed. This targeting vector does not point toward the approximate position of the submarine as determined by sensors available to the player. (See figure 1.)
To make things worse, the true position of the submarine continues to be revealed in this way even when the submarine is no longer detected by the torpedo. If the torpedo misses, re-attacks, and is unable to reacquire the target, its targeting vector continues to reveal the true position of the submarine. This is, as shown in figure 2, despite the submarine being far outside the detection range of the torpedo's seeker.
This strongly suggests that this targeting vector does not even point to the position of the submarine as determined by the torpedo using its seeker. It points to the true position of the submarine.
Commentary and opinions
It is of course possible, and indeed probably not too difficult, to specifically fix this issue. For example, targeting vectors of non-datalinked weapons may be hidden regardless of settings, and those of datalinked weapons may be modified to point to estimated positions of targets instead of true ones.
However, in my opinion, the behaviour described in this report suggests a deeper architectural issue in Command. The fact that such behaviour is possible at all shows that there is no systematic decoupling between the components of the game which present information to the player and those which contain information about underlying reality. I do not write this with any bad feelings: this trait is arguably an unsurprising consequence of Command's developmental history; as far as I understand, Command is distantly descended from a mission editor, an application in which there was no need for such decoupling.
However, in Command as it exists today, exactly what information is and is not available to the player is of central importance. What is shown to the player about detected objects should strictly be a function of the data generated by sensors available to the player; any exception to this[1] is, by definition, a breach of realism and of the game's design intent. I cautiously propose that, in the longer term, the architecture of the game should explicitly reflect this.
One way to do this is to present tactical information to the player through a software component which is only supplied with information which should be available to the player. For example, the game may be explicitly subdivided into several modules with limited and explicitly defined forms of allowed interaction between them; let us consider, in a very simplified example, four modules: a kinematic model which determines and maintains information about the true positions and states of objects, a sensor model which determines information about what every sensor perceives, a communication and sensor fusion model which determines what cumulative information is available to the player, and a display module which visually presents that information to the player. The kinematic model sends information about reality to the sensor model. The sensor model converts this into sensor output messages, which are sent to the communication and sensor fusion model. The communication and sensor fusion model determines what kinds of fused tracks should be presented to the player and sends messages describing these to the display module. Finally, the display module, which sees and knows nothing except the contents of the fused track description messages it receives from the communication and sensor fusion model, draws representations of these fused tracks to the screen.[2] In such an architecture, the kind of behaviour displayed in this issue would be architecturally impossible.
I remark with optimism and hope that what I am proposing does not seem too difficult or too divergent from the recent developmental direction[3] of Command. Considering the features and general excellence of Command in its current form, it would not be necessary to implement any new simulation or user interface functionality to accomplish any of this. Instead, the excellent functionality which already exists may be rearranged and adjusted according to explicit specifications of information flows between software components. The software would thus better reflect the concerns of the problem domain it simulates: emphasizing explicit representations of information flows would better model tactical situations in which what information flows do and do not contain is a central issue of interest.
[1] with the obvious exception of deliberate exceptions such as "automatic detection"
[2] I have much more to say about this. However, because this document is ultimately a bug report, I use a simplified example and avoid extensive elaboration.
[3] For example, I was quite delighted by the recently announced (https://www.matrixgames.com/forums/view ... 1&t=395516) plans for a communication model which situates the player on a specific unit and accounts for the quality of communication links instead of giving the player immediate perfect access to all information the player's side can perceive. This clearly consistent with the kind of architecture I propose and the spirit in which I propose it; such work would form what I call here the "communication and sensor fusion model". More loosely, I appreciate the tendency toward preventing the player from seeing what the player should not see.
Figures
- figure 1.png (44.55 KiB) Viewed 287 times
- figure 2.png (141.41 KiB) Viewed 287 times