New sim underway; DA enthusiast advice sought

[Ivan Rapkinov]

Very interested in MOLE and Urban Ops at the moment.

Cheers

Rob

what fidelity? BN or BDE? As well as scale. We currently use VBS1 (for section level) and TacOps for Coy-BN level. I've never seen DA used, but I guess that's a staff college level tool. You say there's a gap, and I'm confident we could fill it, but need to have some parameters to design in.

I'm not really interested in doing it commercially (I've seen how much effort John Tiller and MajorH put in, and can't hope to match that while holding down a full-time job ), but as a side project it holds a lot of interest - just wondering whether or not it's worth doing.

As corny as it sounds, I'd love to be able to help my country - and if the Yanks want to use it too; all the better

Ideally, I'd like to be able to plug in force concept ideas and test them across a full spectrum, similar to waht I'm doing atm with the Aussie Armour DA scn

 

[MDFeingold]

ABCS isn't a simulation - it's the Army Battle Command Systems, of which MCS is a part.

Right, I understand that. But I believe that in MCS, for example, a subscriber can click on a unit icon and pull up various reports. I would assume that the unit's current posture/mission, for example, are not described only with free text, but that also subject to categorization (whether based on doctrinal terminology or otherwise). It would be neat to see the generalizations used in a real-world C4I system, because that would provide useful guidance in developing unit posture/mission states for a simulation. I've perused dozens of FM's, but the doctrinal mission categories described therein don't lend themselves to computerization quite so neatly. It would be nice to see what software design experts, working with subject matter experts, came up with.

 

[MDFeingold]

On that note, I'm not sure how complicated DA is under the hood. I don't know if Jim used some sort of C++ interface to do it, or if he coded it all by hand or what. I don't even know if it is a C++ program or is C like TacOps. TacOps is all C I believe, but it took MajorH years of programming to get it to its current state. I don't really know how difficult it would be to program something like DA from scratch.

Col. Lunsford may pop in and take my head off for saying this, but in my relatively inexpert opinion, putting aside the multiplayer and AAR code for a moment, the basic DA engine does not appear to me to be very complicated. If I had to take a guess, one might be able to replicate it in 4-6 months of full-time coding, assuming you 're already a competent Windows programmer (me...not so much ). But there may be a deceptive amount of sophistication. For example, the player is given an immense amount of very precise intel on every detected enemy unit. It *appears* to me that this is just an unrefined "dump" of state information from the enemy unit object ("object" used in the programming sense). However, I thought I saw someone mention in a thread somewhere that the intel information may not be entirely accurate, so there may be a significant amount of code for intel-distortion.

I know several of the game programmers use GUI C++ environments for their work as they insist it is a waste of time to code all of this stuff by hand. Unfortunately, I do not yet have enough skill in this area to speak intelligently about it.

I think I read somewhere that DA was programmed in MS Visual Basic, which is a language (somewhat simplified compared to C++) and an integrated development environment (IDE). I use Visual C++, which is Microsoft's C++ compiler and IDE for Windows app development (although you can write generic C++ apps too). I don't think there are very many Windows programmers who would code without an IDE. FWIW, Visual C++ comes with a utility called Spy++ that allows you to examine other programs at runtime to see the window structure and messaging. I ran it with DA, which appears to use a commercial class library, at least for the user interface, which may have sped development as well.

 

[James Sterrett]

Right, I understand that. But I believe that in MCS, for example, a subscriber can click on a unit icon and pull up various reports. I would assume that the unit's current posture/mission, for example, are not described only with free text, but that also subject to categorization (whether based on doctrinal terminology or otherwise). It would be neat to see the generalizations used in a real-world C4I system, because that would provide useful guidance in developing unit posture/mission states for a simulation. I've perused dozens of FM's, but the doctrinal mission categories described therein don't lend themselves to computerization quite so neatly. It would be nice to see what software design experts, working with subject matter experts, came up with.

Yep. This is one of the *huge* problems with making a two-way link between ABCS and a simulation.

 

[CPangracs]

Sorry to disappoint you, Marc, but MCS right now can ONLY give you unit name, type, and position. I have heard rumors that MCS will be going away soon in favor of C2PC anyway. I would look past MCS anyway, as C2PC has the links to CPOF, GCCS-A and many other systems.

PEO-STRI was formed to make heads and tails out of all of it, but they're not quite there yet!

 

[Dr Zaius]

For example, the player is given an immense amount of very precise intel on every detected enemy unit. It *appears* to me that this is just an unrefined "dump" of state information from the enemy unit object ("object" used in the programming sense). However, I thought I saw someone mention in a thread somewhere that the intel information may not be entirely accurate, so there may be a significant amount of code for intel-distortion.

Right. There is some FOW in DA, but once you get into a significant engagement with an enemy unit you usually have a tremendous amount of information on it--too much sometimes. In effect, you usually end up with almost as much info on enemy units as friendly ones. However that may be in a training environment, it is not desirable for wargaming.

Were I to program DA as a wargame from scratch I would include many factors that are common in commercial games of this scale. Bear in mind, the vast majority of these would probably be global force settings similar to what TOAW has. DA is an operational sim, so it would not be appropriate to model tactical factors:

1. An adjustable (by scenario author) force proficiency rating.
2. A force night fighting proficiency rating.
3. A force communications rating. A force with a low rating would not be able to separate its units as far from parent HQ without penalty.
4. A force supply rating--affects how efficiently supply convoys operate.
5. Combat resolved with results per individual formation, not a result simply substracted from the aggregate strength (this is actually one of Jim's ideas).
6. Vastly improved user interface including at least 2-3 zoom levels.
7. Totally restructure the way information is displayed for the player. Make it more like POA2 (i.e. information is avaliable via an S1, S2, S3, and S4 menu).
8. Event editor that allows the player to receive changes of mission in mid-scenario (FRAGO) if certain conditions are triggered.
9. Improved ability for both players and scenario authors to create and display operational graphics.
10. Amphibious assaults and large scale airborne landings.
11. Improve user interface for PBEM gaming. Prohibit players from viewing enemy OOB, etc.
12. Rework the transport helicopter routines. Currently, helicopters can only transport units of equal size. This is highly unrealisitic as no no light infantry brigade in the world has an entire brigade of rotary wing assets assigned to support it. Usually a battalion would be assigned to lift a brigade over a period of some hours.
13. FARP support for rotary wing aircraft. Currently, helicopters are incredibly limited due to the abstract way in which they are modeled.
14. Naval support (at least some abstract support).

 

[Secret Agent]

large scale airborne landings

Yes, include that!

 

[MDFeingold]

There are some earlier posts I need to address too, but let me respond to this one while I have a moment...

In effect, you usually end up with almost as much info on enemy units as friendly ones. However that may be in a training environment, it is not desirable for wargaming.

I'm not sure why this much intel would be desirable training environment, either. I always assumed the DA intel availability was done that way for temporary ease-of-programming reasons, and left for correction in a future version.

Were I to program DA as a wargame from scratch I would include many factors that are common in commercial games of this scale. Bear in mind, the vast majority of these would probably be global force settings similar to what TOAW has. DA is an operational sim, so it would not be appropriate to model tactical factors:

FWIW, DA is arguably "tactical" in scale, the way the military defines that term.

1. An adjustable (by scenario author) force proficiency rating.

1. 
   OPSIM (my temporary "public" working name for the project) will have similar settings.
   

   [*]A force night fighting proficiency rating.

   Check. Plus other things like mountain/high altitude proficiency, infiltration capability, COMSEC (the Soviets reportedly had good radio discipline and radio silence skills, for example), yada, yada...
   

   [*]A force communications rating. A force with a low rating would not be able to separate its units as far from parent HQ without penalty.

   Ultimately, I'm thinking of rating every horizontal and vertical comms link between units, but these are pure musings at this point in time.
   

   [*]Combat resolved with results per individual formation, not a result simply substracted from the aggregate strength (this is actually one of Jim's ideas).

   I have something like this in mind, plus flank and rear attacks will tend to inflict greater damage on attached CSS, C2 and indirect-fire units. Maneuver type units will bear the brunt in frontal attacks. (Units in a strongpoint-type defensive posture may not have an assailable flank).
   

   [*]Vastly improved user interface including at least 2-3 zoom levels.

   In addition to the normal view, I think I'm going to implement an overview/jump map and at least one zoom level. The "zoom" capability, however, will be limited to "stretching" the main map bitmap to achieve zoom, so there will be some pixelation. However, the simulation objects will be further apart (units, terrain symbols, etc), allowing easier manipulation in cluttered areas.
   

   [*]Totally restructure the way information is displayed for the player. Make it more like POA2 (i.e. information is avaliable via an S1, S2, S3, and S4 menu).

   Something along these lines is planned...eventually.
   

   [*]Event editor that allows the player to receive changes of mission in mid-scenario (FRAGO) if certain conditions are triggered.

   Event capability is planned, but only in the most vague sense right now. Unlikely to achieve the breadth of the TOAW system, but, yes, events outside of the player's scope of command will probably be implemented. Depending on how good/bad my AI programming skills turn out to be, I would also like to implement friendly forces to either flank, not controlled by the player.
   

   [*]Improved ability for both players and scenario authors to create and display operational graphics.

   Big check here. One of my primary design goals for an initial product is functional graphic control measures.
   

   [*]Amphibious assaults and large scale airborne landings.

   Yes, but....... There will be no maritime combat, other than abstract attrition based on air/sea superiority levels, which will be set at the scenario level. I'm going to take the same position that Norm Koger did with TOAW (and, actually, even more extreme). THis is a ground combat simulation, not Harpoon (or Rolling Thunder). It will be up to a scenario designer to decide whether/if the conditions exist for amphibious or large-scale airborne operations. Units slated for such ops will probably be held off-map until a player-specified time (perhaps the time will even be fixed at the scenario level). To sum up, you will not be able to simulate (in any satisfying way) Guadalcanal-type battles (which was atypical even in the Pacific War).
   

   [*]Improve user interface for PBEM gaming. Prohibit players from viewing enemy OOB, etc.

   Big check on the latter point. I'm even considering permitting the scenario designer to specify multiple OOB's per side, to be randomly selected at scenario startup.
   

   [*]Rework the transport helicopter routines. Currently, helicopters can only transport units of equal size. This is highly unrealisitic as no no light infantry brigade in the world has an entire brigade of rotary wing assets assigned to support it. Usually a battalion would be assigned to lift a brigade over a period of some hours.

   I think I will solve this problem by representing brigades/battalions as compositions of company/platoon size entities.
   

   [*]FARP support for rotary wing aircraft. Currently, helicopters are incredibly limited due to the abstract way in which they are modeled.

   Yeah, the rotary-wing aviation implementation of DA was one of the big things I didn't like. OPSIM will model the actual helicopter companies separately from ground elements of an aviaton battalion/Bde. FARP's are, as I understand them, an ad-hoc grouping, so I will probably leave it up to scenario designers how many to give per battalion. Additionally, players will be able to designate one (or perhaps more) waypoints as battle positions (tied to engagement areas), where the unit will halt and wait for a target to enter the EA. I may also implement Forward Operating Areas (I think that's the doctrinal term), which are holding areas, short of a battle position, with greater cover and concealment than a battle position, where the unit will land (conserve fuel) and wait for the enemy to approach an EA. The unit will then move to its battle position and engage.
   

   [*]Naval support (at least some abstract support).

   Yes, but see above. No explicit surf-surf, air-surf, etc combat.

[/QUOTE]

Having said all that, most of this is just a gleam in my eye right now.