From: Mike Kolar Newsgroups: comp.sys.ibm.pc.games.naval Subject: Doctrine Spec (and more) Date: Mon, 17 May 1999 20:57:27 -0400 Organization: Sonalysts, Inc. First, the teaser: The doctrine spec is attached. There's been a lot of questions about Fleet Command and our design decisions. For the record, Fleet Command behaves exactly as we intended. We purposefully left it up to the player to order platforms to engage incoming missiles and aircraft, because we felt that without that, the player could too often have nothing to do. We opted to load-out aircraft for multiple roles instead of allowing the user to select a specific one in the interest of simplicity for the interface and our simulation and database design (we never imagined the extent of offense that would be taken at that decision). We started some scenarios hot because we didn't want the user to sit around watching ships steam along for 20 minutes before the action began. We felt comfortable with these decisions knowing that we were trying to include appeal to the broader RTS market with a new slant on naval simulation. But we also tried to consider at every step how the game would appeal to the hardcore sim market that liked 688i (don't bother commenting if that excludes you). For example, we expanded on the same realistic sensor detection models and object dynamics, when a normal RTS game could have got by with much less sophisticated modeling. Certainly we didn't expect the ferocity of discontent that flared up in some circles. But we've also seen plenty of positive replies that make us think maybe we achieved what we were hoping for. The doctrine files some of you have begun to investigate were intended from the start to let you customize the AI's behavior (they could have more easily been hardcoded instead of editable). Time and scope prohibited even thinking about the ability to provide an effective interface to manipulate them from within the program. Providing multiple sets might have been nice, but we decided to concentrate on a single implementation with the broadest appeal. Besides, read just a few messages in this newsgroup, and it's apparent that in some cases you guys know best what you're going to like (and nobody else). I hope you'll be able to use this tool to customize behavior to your satisfaction. As for custom load-outs, ideally that would require an interface change and the simulation of some relatively complicated timing- not the sort of thing we would patch lightly. "Realistic" load-outs in several cases have been argued back and forth for the past week- with the possible exception of the Phoenix (another decision we're standing by), nobody seems to have reached a consensus on any of them, and how much difference would it make to gameplay, really? Still, we are considering what might be done about these issues, but are not ready to commit to anything. Note that neither Sonalysts nor EA/Jane’s will support editing of doctrine files- Fleet Command was intended to run with the files as shipped. What you do with them after that is at your own risk. Having said that, the doctrine spec is attached as a text file. Happy Commanding to all! Regards, Mike Kolar First a little about how doctrines work: Every platform has a default doctrine assigned by the object database. It can also be specified per platform in the scenario file by the DOCTRINE command. FC will evaluate this doctrine at regular intervals. Whenever a platform detects a new contact, the platform doctrine is evaluated with NEW_TRACK equal to 1. Platform doctrine can chose to assign a particular doctrine file to that contact using the TACTIC command. Thereafter, the original platform doctrine continues to be evaluated as before, plus the assigned tactic doctrine is evaluated every time the contact is updated. It's important to understand the distinction: the original platform doctrine is routinely evaluated without a reference solution, except when a new contact is detected. When a new contact is detected, the platform doctrine is called only once referring to the new solution. This is the only opportunity to set a tactic doctrine for that contact. Note that doctrine priority is by default higher than user commands. You can test against the user order currently being executed using the ORDER term. In this way all user commands could be overridden and redefined in doctrine. Following are some syntax specifications. Note that neither Sonalysts nor EA/Jane's will support editing of doctrine files- Fleet Command was intended to run with the files as shipped. What you do with them after that is at your own risk. Rules = Rules consist of expressions and commands in the following form: RULE IF THEN END Expressions Expressions consist of values and operators in the following form: Expressions can be joined by AND or OR, and support nested sub-expressions, for example: ( BRG < 90 OR BRG >270 ) AND SPD > 400 Fleet Command is capable of following sub-expressions recursively to any depth. Possible terms for are "=3D", "!=3D" (not equal), "<", ">". Possible terms for are: real Any real number {real1,real2} A real number of random value from real1 to real2 "string" Any character string enclosed in quotes BRG Solution bearing RNG Solution range CRS Solution course SPD Solution speed ALT Solution alt/depth PERIDEPTH Platform's periscope depth ID Solution classification (see below) CPA Solution projected closest point of approach CLASS Contact object class (see below) SILOS Solution speed in the line-of-sight (approach speed) AOB Angle-on-bow of contact bearing LAYER Acoustic Layer Depth ATTACKRNG Max attack range of best available weapon SOURCE Source of reporting sensor (see below) MISSILE_CLASS Class of contact missile: AAM or ASM AGE Time since last new position CONF Solution confidence, 0-100 TIME Simulation time INIT Boolean, TRUE first time doctrine is evaluated NEWTRACK Boolean, TRUE first time solution is evaluated TIMERx 1-8, timer remaining or -1 VARx 1-8, user variable WEAPON_AWAY Boolean, TRUE whenever weapon is fired WEAPON_CLASS Object class of weapon fired (see below) EXPR indicates a mathematical expression will follow, e.g. {1,10} > 5, which evaluates truth of a random draw from 1 to 10 being > 5. ORDER Current user order being executed Commands Commands consist of commands and values in the following form: [value1] [value2] Supported terms for are (so far): SETCRS Set own course to value1 STEER_ABEAM Set course to put contact abeam STEER_AWAY Set course to put contact astern STEER_TO Set course toward contact STEER_OBLIQUE Set course toward contact with given AOB INTERCEPT Set intercept course TERMINAL_HOME Set collision course STEER_EVASIVE Steer contact off rear quarter SETPITCH (A/C or Sub only) Set pitch SETSPD Set own speed to value1 MIN_SPD Set own speed to minimum speed LOITER_SPD Set own speed to loiter speed TRANSIT_SPD Set own speed to transit speed MAX_SPD Set own speed to max speed SETALT Set own alt/depth to value1 IDENTIFY Set solution classification to value1 (see below) SENSOR Turn sensor value1 on or off dependent on value2 ATTACK Attack contact using weapon value1 ATTACK_BEST Attack contact using best weapon FIRE_BEST Fire best weapon immediately, no range considerations TACTIC Apply doctrine value1 to contact ENABLE Set weapon enable COUNTERMEASURE Launch specified countermeasure DETONATE Detonate now SHUTDOWN Shutdown SET_TIMER Set timer value1 (1-8) to value2 seconds VAR_SET Set user variable value1 (1-8) to value2 VAR_ADD Add value2 to user variable value1 = VAR_SUB Subtract value2 from user variable value1 VAR_MUL Multiply user variable value1 by value2 VAR_DIV Divide user variable value1 by value2 CLEAR_TIMER Clear timer value1 (1-8) LAUNCH Launch aircraft of type value1 LAND Instruct an aircraft to return to base TACTIC_CENTER Recenter the platform's original scenario tactic at its current location PRIORITY Set commands in the current scope to priority value1 (1-255). Doctrine commands default to 250. Other defaults are: Scenario orders, 1; AI orders, 100; User orders, 225. PERSIST Set commands in the current scope to persist for value1 seconds. Default persistence is 10 seconds. String constants: Object Class: SUB,SURF,AIR,HELO,LAND,MINE,WEAP,MISSILE,PROJECTILE,DOWNED_PILOT Classification: UPD,UEV,UAF,UAE,HOSTILE,FRIEND UPD = Unknown, pending UEV = Unknown, evaluated UAF = Unknown, assumed friend UAE = Unknown, assumed enemy (you'll often get this after missile separation from an unknown) HOSTILE = Positively ID'd as hostile FRIEND = Positively ID'd as friendly Sensor Class: Active Sonar,Active Intercept,ESM,Visual,MAD,Infrared,Passive Sonar, Sonobuoy,Radar,FCRadar User Orders: NONE,VID,ENGAGE,RETURNTOBASE,COVER,SCRAM,MOVE,RESCUE,SEARCH