I'm not sure how much fire control support measures will add to the game, which will only appeal to players who want that kind of control/realism. NAI/TAIs are more or less implemented, seeing as how the sensors, in this case, are actual units like scouts. When I was at CGSC, we used Decisive Action, which had a simple abstraction model for NAIs. The students always wanted to place them in areas they had no sensors.IronMikeGolf wrote: ↑Sun Nov 20, 2022 2:54 pm "One nearly impossible thing is preventing units from shooting across a boundary or assigning "sectors" in an engagement area. Of course, it's not a showstopper, and most players won't care about such things."
That's because we've not (yet) implemented any control measures for the human players. We sort of have a bit of that for the computer player with the Battle Plan mechanics, but that is largely limited to route/axis level control.
We did start down this path some time ago before coming up with Battle Plans. It isn't very easy, more so than we expected. Battle Plans was a more straightforward solution to the problem of making a smarter computer player than that in RS.
Another thing to consider is which control measures to implement. You mentioned sectors. That's a special case of inclusion/exclusion areas. So, you can add NAI, TAI, EA, time boxed RF and FFA. And the other "beyond this line" sorts of things like FCL.
Oh, PLs. Yes, PLs. Throw in BPs (Battle Positions, not Battle Plans). These are needed for synching multiple groups of units to cooperate (in an Attack, a Defense in Depth, and a Delay), but there is a raft of infrastructure to define and build to support those. I like a lot about doing this, but it's a big lift.
TacOps had a very good system for controlling direct fires. I suppose the simplest way to implement fire control in FPSC is to allocate specific hexes for which a unit is responsible. At a minimum, it keeps them shooting in the desired direction while not violating boundaries. Another way might be to use a "smart graphic" like a target reference point. If you assign a unit a TRP, it will shoot targets within a certain radius of the TRP. In TacOps, MajorH allowed you to place a TRP and specify its radius, but it was tied to a specific unit.
I think both methods would be nice. From an individual unit, specify the hexes they are responsible for. They will engage all enemy units who enter those hexes. Given the size of the hexes, you may limit this to no more than three, maybe even two. The other method would be to specify hexes and create a named EA. Now, you have to tell the unit what EA they are responsible for. I do realize that what I think is easy may not be when it comes to coding.
TacOps also allowed you to assign a unit a priority type to shoot at. For example, you could assign your tank units a high priority to engage other tanks. So, given a choice between an AFV and a tank, that unit would shoot at the tank first. I attached some screens of the TacOps interface for fire control.
As a contractor at CGSC, I considered using the first version of FP in the classroom. I can't remember who I spoke to, but we corresponded briefly. If I recall, the original program was coded using Delphi, although I could be mistaken. The map used squares instead of hexes and an excel spreadsheet to code the terrain type, with each cell in the spreadsheet corresponding to a piece of "dirt" on the map.
shoot me a private message.
