MechWarrior 2
Artificial Intelligence
Last updated: 10 Jan 1997
The original copy of this document is located at http://www.activision.com/mercnet/mercai.htm.
NOTE: These information is provided as is with no claims made as to accuracy or usefulness.
WE WILL NOT RESPOND TO ANY QUESTIONS REGARDING THE TOOL SET ON OUR
CUSTOMER SUPPORT LINES OR ON-LINE SUPPORT ACCOUNTS.
Table of Contents
Introduction
The Artificial Intelligence (AI) engine for Mechwarrior 2 is a
highly complex and versatile system for directing the actions of
computer-controlled adversaries. At the highest level, game AI starts
with the mission objective (MO) code which processes
the mission table, the table which scripts the main actions and outcomes
for each mission. Beneath the MO
code is the general level AI, discussed here, which controls behavior
of groups of gamepieces as well as individual gamepieces. This general
level AI is further split into non-combat and combat (tactical) AI.
The first discussion below covers the general, non-combat AI and is
followed by a discussion of the tactical AI.
Note: the only knobs available to the mission
designer are the old Gunnery Skill, Piloting Skill, Targeting
Range, Sleep Range and Rubberband Range fields in the
gp_spec line of the .wld file,
as well as the new Affiliation Type and Personality fields of the gp_spec
and the Disturb Level and Mechs Per Target fields of the
mission objective tables.
This document discusses the internals of the AI engine in greater
detail than the mission developer truly needs. However, the more a
mission developer knows about the AI, the more likely he or she will
be able to develop great single-player missions.
Note: the DOS sim has a -M commandline option which displays various
pieces of information about the current state of the AI on a monochrome
monitor. This is very helpful for debugging AI behavior. Do not use
the -M switch if you do not have a monochrome adapter and monitor.
The general AI implementation is based on a system
of "states". Gamepieces are always in one of many states,
and can be made to change state based on information about the
world around them. At the lowest level is a common state table
which is scripted as an ASCII text file and compiled using the
proprietary AIPARSER.EXE. Note: These tables are fixed, and
cannot be changed by the mission developer.
AI Tables
AI tables are created as individual text files,
then parsed using the AIPARSER tool which generates an AI specific
formatted binary file that is added to the project file. The
AI code is designed to handle up to three levels of tables, with
each level having the ability extend or override behavior in a
successive (lower) level. The lowest level table, the default
table, describes the default behavior for any gamepiece using
that set of tables and so should specify all states which that
gamepiece is capable of having. In fact, the tables can be structured
any way desired as long as every possible state for a gamepiece
is specified in at least one of the three tables. The intent
behind having the three table groups was originally as follows:
- Global Table
contains default behavior for all Gamepieces
- Group Table
defines special group behavior (probably based on Mech weight class or clan)
- Individual Tables
override default behavior for individual Gamepieces.
As implemented, only the Global (default) and Individual
tables are used, as it was possible to specify all necessary behavior
in just those two tables. Had we chosen to implement a greater
variety of AI based on other factors, such as gamepiece class,
mech type, or even clan, the Group table could have been used
as well.
Also as implemented, the global table is always initialized
to a single table called «DEFLT». The individual
tables are assigned based on two attributes: a gamepiece's
leader/follower classification, and the current star objective
(e.g. defend, recon, etc...). Hence, individual tables have names
like «LDESTROY» (Leader Destroy), and «FDEFEND»
(Follower Defend). Internally, all tables are loaded at world
loader time but are assigned dynamically during game play as a
star's objective changes and as an individual mech's
position within his star changes (i.e. going from follower to
leader).
The tables are searched from the individual up to
the global level. Whereas the global table should probably contain
the default behavior for all the states a Gamepiece is capable
of, a group or individual table will "override" that
intelligence by providing alternative behavior for the same states.
Thus, individual tables contain the least data with the bulk
of AI information being left to the group and global tables.
Group and individual tables can also «extend» the
functionality of the global table by including additional states,
but in practice, individual tables were used only to override.
Rather than base the AI on a distributive, message
based model where decision routines gather information and send
messages to the gamepieces, this model calls for each gamepiece
to poll a list of conditionals specified by its state and take
the appropriate action described in the table. Although this document
uses the term "messages" when referring to these state
change motivations they are, in fact, "conditions" which
each Gamepiece polls through his AI loop and acts upon should
any one of them evaluate to true.
Each line in a state table looks like this:
<stateName (optional)>
<msg.>
<obj. ref.>
<msg. param>
<trans. action>
<New state>
<state arg.>
Here's an example of a state with two transition specifications:
Target M_PROX, '@', 350, T_NULL, Attack, '%'
M_DESTROY, '@', 0, T_POP, follow, agp_myleader
This is read roughly as follows: When an AI-controlled character is in
Target state,
- if the current target is within 350 meters, jump to Attack
state
- else if the current target has been destroyed, pop the previous
state off the stack; if there was no state saved, jump to Follow state.
If the stateName is given, this is the first line of that state,
if no stateName is given, it is the next line of the current state.
Each of the lines is a "transition specification" which describes a conditional
test, along with a course of action should that test evaluate
to TRUE. Every state in a table has one or more lines; each line is
a transition specification. Each line consists of
- the state name (optional; only on first line of state),
- a message (the conditional),
- an object reference
and message parameter (the arguments to the conditional),
- a transition action (what should happen if the conditional is true;
can save or restore the previous state or defer the entire message).
- a transition state (what new state to jump to if the conditional is true
and the transition action allows it),
- and a state argument (the object of the new state),
Each time through an object's AI loop, the row corresponding
to the object's current state is traversed and each conditional
is tested. The object's proximity to an enemy, or whether or
not it has reached it's destination are two examples. When any
condition is found to be true, specified transition is performed
and AI processing for that gamepiece is ended for that cycle.
Since it is possible for more than one condition within a conditional
group to be true and since the first condition encountered which
evaluates to true ceases further evaluation, the ordering of these
conditions within their group provides an implicit priority which
adds an additional level of "intelligence" to the table
itself.
States
Each computer-controlled player is in one of the following ten
states at any time. The names of these states appear in two places
in the state table: as labels in the first column indicating the
beginning of a state table, and in the sixth column, indicating the
state to go to if the conditional is true.
- Target
Head toward a gamepiece or gamething, firing upon
it when in weapon range. When the target is reached, usually the
state is changed to attack, to add maneuvering capabilities.
- Attack
Use tactical maneuvers while firing at the targeted object.
- Follow
Usually used to follow the leader and keep the formation intact.
- Patrol
Guard an object by traversing between four navpoints.
- Godirect
Go toward a navpoint, gamepiece, of gamething.
- Flee
Retreat from a gamepiece to a safe distance away.
- Idle
Sit where you are and do nothing.
- Rest
Wait in a shutdown state until a gamepiece gets close
enough and then startup.
- Shutdown
Wait in a shutdown state.
- Dead
He's dead, Jim.
(There are other states defined, but not implemented.)
The conditional part of the state table is called
a Message. When a Message succeeds, the value of the object
(which can not be NULL) is returned, and table processing terminates.
If the Messages fails, NULL is returned, and table processing
continues.
The possible values are:
- M_PROX
Tests to see if the gamepiece is closer than Message
Parameter to the Object Reference. Used for many things, the AI
is often trying to get close to something.
- M_DIST
Tests to see if the gamepiece is farther than Message
Parameter from the Object Reference. Mostly useful for evasive
actions and fleeing.
- M_REACH
Tests to see if the gamepiece is within a radius
specified by the Object Reference. M_REACH is almost identical
to M_PROX, with a special case for gamepieces in patrol state
that advances the target to the next navpoint when the old one is reached.
For all other states, use M_PROX instead.
- M_DESTROY
Tests to see if the gamepiece's current target has
been destroyed..
- M_TGTABLE
Look for an enemy gamepiece to attack. The closest
one in range that is powered up will be returned.
- M_TRUE
Always returns the Object Reference, therefore is
never NULL.
- M_FALSE
Always returns NULL. Useful for looping forever in
a state, until an Objective change forces a new state.
Object Reference
Though any explicit reference to a gamepiece, gamething,
or navpoint may be entered here, more often this field is used
with a value that must be resolved upon entry to a state. This
resolution happens immediately upon entrance to the state, so
the gamepiece always has a valid target.
The possible values are:
- Any explicit reference to a world item.
A valid gamepiece, gamething, or navpoint.
- agp_enemy
Evaluates to any enemy gamepiece.
- agp_friendly
Evaluates to any friendly gamepiece in the same star.
- agp_user
Evaluates to the user's gamepiece.
- agp_myleader
Evaluates to the leader gamepiece of the star.
- agp_me
Evaluates to the gamepiece doing the test.
- agp_home
Evaluates to the navpoint that is specified as the
RETURN objective.
- agp_rbanchor
Evaluates to the "anchor" position, the
point where a gamepiece previously in "patrol" state
turned to fight.
- @
Evaluates to whatever value was passed in when entering
this state.
- *
Evaluates to the gamepiece's current target.
Message Parameter
Usually (always?) a distance value.
The possible values are:
- Any absolute numerical value
- &n
The internal Nav Radius of the Object Reference.
- &s
The Sleep Radius, which is passed in with the gamepiece
structure.
- &t
The Target Radius, which is passed in with the gamepiece
structure.
- &r
The Rubberband Radius, which is passed in with the
gamepiece structure.
- &l
Ten Million meters. Large enough to find anything
in the world.
Transition Action
If the Message evaluates to true, the specified function
is called before the state changes.
The possible values are:
- T_NULL
Do nothing; this returns FALSE, which allows the "new state" to take effect.
- T_PUSH
Push the current state onto the gamepiece's state
stack before entering the new one.
- T_POP
Pop the current state from the gamepiece's state stack. This
normally overrides the "new state" field of the transition specification.
But if the stack was empty, and there is no state to pop, the "new state"
field is obeyed.
- T_CLEAR_STACK
Clear the gamepiece's state stack.
- T_NOTIFY
Pass on the entire current table entry to the leader
of the star. When the leader is next processed he will evaluate
this message and decide if any action should be taken.
State Argument
This value will be passed along to the next state,
where it will appear if the Object Reference is '@'. The State
Argument is always some sort of reference to a world object, either
resolved or unresolved.
The possible values for state arg. are:
- All «agp» values (listed above)
- @
The current target specified in this line of the
table, potentially unresolved.
- %
The gamepiece's current primary target, always resolved.
- *
The gamepiece's current secondary target, which may
or may not be the primary target. This is because there are times
that the gamepiece sets up a temporary (secondary) navpoint to
go to, even though his primary target is something else entirely.
Either way, this is always resolved.
Multiple messages
The ability for each "state" to have
more than one "message" of the same type allows for
multiple specifications of the same message, with different arguments
and outcomes, within a given state. For example,
if a friendly Gamepiece is in proximity (M_PROX)
to a hostile Gamepiece, it might perform a combat related action.
However, if the same Gamepiece comes within M_PROX of the user's
Gamepiece, it might revert to a protective patrol mode.
To allow for a more flexible message specification
each "state" in the table can have a different number
of "messages" of any type; the total width of the table
being equal to the maximum number of messages in any state.
Transitions
When a state change is made using the table, a "Transition"
action is called prior to an actual state change. These functions
return a Boolean value which dictates whether the state change
is to take place or not. Transition actions always perform functions
directly related to the state table itself, never to anything
outside the table. Common applications of transition actions
include saving the current state, remembering a previous state,
passing the current message on to another Gamepiece, clearing
the AI stack, and doing nothing at all.
Message passing
Gamepieces have the ability to send messages directly
to other Gamepieces. Usually this will occur when a T_NOTIFY
message from the table returns TRUE. When this occurs the Gamepiece
will pass on the entire message to the leader, who will evaluate
it the next time he becomes active, and decide upon a proper course
of action.
State Table Examples
The following table snippet containing two states, "Target" and "Attack",
implements the default behavior for a gamepiece that allows it to handle
an order to target and attack an object.
Target M_PROX, '@', 350, T_NULL, Attack, '%'
M_DESTROY, '@', 0, T_POP, follow, agp_myleader
M_DIST, agp_rbanchor, &r, T_POP, godirect, '%'
Attack M_DESTROY, '@', 0, T_POP, follow, agp_myleader
M_DIST, agp_rbanchor, &r, T_POP, godirect, '%'
M_DIST, '@', 350, T_NULL, target, '%'
While in the "target" state, the AI code by default will try to go to
the current target; then the list of conditionals is traversed from top
to bottom starting with the M_PROX.
In this case, M_PROX evaluates to TRUE only if we
are 350 meters or less from our current target '@'. If we
are, then the transition function T_NULL is executed and, since
it does nothing but evaluate to FALSE, causes us to transition
to the Attack state using the '%' symbolic reference
to whatever argument was fed to the current conditional, namely
our current target.
If we haven't reached our target, the M_DESTROY
checks to see if we've destroyed our current target, and
attempts to POP back to our previous state if so. If we have
no previous state (thus T_POP returns FALSE), then we default
to following our leader.
The final conditional under Target is the M_DIST
which, in this case, checks to see that we haven't strayed
too far from our anchor position. The anchor position represents
a navpoint which we've placed at some point in the past
and it is used to keep a mech from being lured away from his star
(historically to prevent too many mechs from being on screen at
a time, but practically not really a big deal). If we have strayed
too far, we'll attempt to T_POP back to our previous state,
defaulting to a «godirect» back to our current target
if none.
If we wanted to override the behavior above to use
the standard target radius instead of the 350 meter value, the
following line in a higher level Attack state table would do the trick. Since
the first two tokens on the line (M_PROX and '@')
are the same as the M_PROX in the target state above, the parser
will substitute this transition specification instead.
M_PROX, '@', &t, T_NULL, attack, '%'
Interfacing AI with Mission Objectives
The Mission Objective (MO) code is in charge of notifying
the AI engine whenever there is a change in the
objective for
computer-controlled stars. Whenever a new objective is begun,
the MO code sends message to the AI code notifying it of this
fact. The AI code then loads new individual tables appropriate
to the objective and sends messages putting all Mechs in an initial
state appropriate for this objective. This will usually be 'idle'
for the leader and 'follow' for followers, with a couple of exceptions.
These are 'pushed' messages, so if a Mech is currently engaged
in battle he will continue fighting until he has successfully
destroyed his target, or is destroyed himself.
Each time a leader Mech is the current gamepiece
being processed, he will look at all of the unfinished targets
within the current objective and see if he can send someone out
of the star to accomplish it. Each objective specifies the number
of Mechs to be sent out to any target; the leader will send as
many Mechs as he can up to this limit to the first target, and
any remaining ones will be sent to the next target, etc. The follower
Mech will be put in a state appropriate to the objective and given
a new target to operate on.
If the user has Starmates, he is given the opportunity to
- Attack My Target
Tell a Starmate to break formation and attack the
user's target, returning to the formation when finished.
Sets starmate's state to Attack.
- Defend Target
Tell a Starmate to defend user's target against attacking
enemies, returning to the formation when finished
Sets starmate's state to Patrol.
- Join Formation
Tell a Starmate to stop what he is doing and join the star. The Starmate
may not do this immediately if he is currently engaged.
Sets starmate's state to Follow.
- Shutdown
Tell a Starmate to shutdown, so he cannot be seen
with enemy radar (though he can be visually acquired).
Sets starmate's state to Shutdown.
- Fire At Will
Tell a Starmate to attack any enemy Gamepiece in
proximity, without waiting for instructions from the user.
Sets starmate's state to Attack, without setting a target.
Designer-specified AI Values
In addition to the tables, AI Gamepieces are influenced
by values passed in through the gp_spec (see the section on
the world loader). These values are:
- Gunnery Skill
Determines the Gamepiece's accuracy and firing frequency.
This value should be from one to six, with one being the best
shot and six the worst. See 'Firing Decisions', below.
- Piloting Skill
Determines the type and accuracy of maneuvers a Gamepiece
will use. See 'Piloting Skills', below.
- Targeting Range
Determines the distance a Gamepiece will fire at
his target, regardless of weapon range. This value is in meters.
- Sleep Range
Determines the distance a mech in 'rest' state will
start up and begin to attack. This value is in meters.
- Rubberband Range
Determines the distance a Gamepiece will stray from
an object he is defending. This value is in meters.
- the new Affiliation Type and Personality Type
fields implemented for Mechwarrior 2: Mercenaries.
Other values are passed in through the objective table:
- Disturb Level
Determines how the Gamepiece will react to enemy
behavior. This can be one of three values, with an increasing
chance of the Gamepiece being diverted from his current task:
- DISTURB_NEVER
A mech with this disturb level will never be diverted
from his current task until the objective changes.
- DISTURB_IF_ATTACKED
A mech with this disturb level will be diverted to
engage another Gamepiece who has attacked him.
- DISTURB_ALWAYS
A mech with this disturb level will be diverted to
engage another Gamepiece who has attacked him, and will be eligible
for being sent by the leader to attack other Gamepieces in the
vicinity.
- Mechs Per Target
As described above in the Mission Objective section,
this specified the optimal number of Mechs to be dispatched by
the leader to each target in the objective.
Firing Decisions
Whenever a Gamepiece is in 'target' or 'attack' state,
he will try to fire at his target. The gunnery skill value, one
of the AI Values, determines how often the Gamepiece will attempt
to fire. Once he has decided that it is time to fire, he will
examine the range of the currently selected weapon and see the
range is appropriate to hit his target. If the weapon has the
correct range, he will then look to see if the weapon is ready
to be fired. If it is, he then looks at the potential heat acquired
by firing this weapon. If firing this weapon would
not raise his heat level into the danger zone, he will accept
that weapon and fire it. Should any of these tests fail, he will
cycle to the next weapon and try again, until all weapons have
been checked. If he is unable to select a proper weapon, he will
not fire on this cycle.
Tactical maneuvers are a specific part of the AI which takes over from
the general AI at the point when a Mech is within battle range of his
opponent, i.e. when the mech has entered «attack» state.
The tactical maneuvering code takes control of all the mech's movement
functions including throttle, legs rotation, turret rotation, movement
direction, and jump jets. Firing decisions are handled separately.
Tactical maneuvers (for brevity, I'll drop the word "Tactical" below)
are divided into two successive stages;
the approach phase, when a mech is approaching his opponent
and may or may not be firing, and the withdrawal phase,
when a mech is moving away and may also be firing. There is a
group of maneuvers which fall into a third category which is neither
approach nor withdrawal. These types of maneuvers (for example
circling and behind) are typically handled like withdrawal maneuvers
as they are usually followed by an approach maneuver.
When a mech is considering a maneuver, he looks at
several factors before making a choice. These include things
like the availability of jump-jets or weapons, but the final choice
is a random, though sometimes weighted selection from a list of
appropriate choices. Every maneuver has a list of the maneuvers
which are allowed to follow it, and the final choice comes from
that list. These maneuvers, along with their lists of appropriate
follow-up maneuvers comprise a maneuver table and there is one
maneuver table for each gamepiece class (with the exception of
Elementals which are of class GP_MW2MECH but which have their
own table). Once a maneuver has been chosen it is executed until
completed or until some other circumstance requires termination
of that maneuver. The point at which a maneuver is considered
complete is dependent on the maneuver, but it is usually based
on 1) arrival at a world location, or 2) the expiration of a maneuver
timer. A master maneuver timer prevents any maneuver from exceeding
a pre-defined maximum duration in case it is unable to reach completion
within a reasonable time period.
The following is a
list of all current maneuvers. Maneuvers that start with an «a»
are approach maneuvers, the ones with a «w» are withdrawal
maneuvers, and the remaining ones are neither. Study it. Marvel
at it. Then make a really good paper airplane out of it.
-
aStraight
Run at your opponent in a threatening and condescending manner.
-
aSerpentine
Same as above, but zigzag back & forth.
-
aJumpin
Jump-jet up to a fixed height and fire on the way up and down.
-
aDFA
Used to 1) jump-jet to target, position over its head, and drop.
2) Feint back and forth in the air while shooting at target.
-
aKamakasi
Run up to opponent and pout (then go ahead and explode).
-
wStraight
Run away from your opponent to a fixed distance.
-
wBackup
Face your opponent and backup while firing.
-
wPeekaboo
Used if opponent is above us but not weapons visible. Jump-jet
us up to his height and start cracking («seek from below»).
Only used if opponent will be visible at height.
-
Stupid
Stand a fixed distance from opponent and blast him/her. If
opponent comes too close, go into Avoid.
-
Behind
Remain behind and to the right or left of your opponent.
-
Avoid
Like wBackup but has short duration. Used if we collide with something
or if target comes too close while we're in Stupid.
-
Sprint
Jump-jet out of the way of an opponent's projectile. Only used
when projectile is a guided missile or PPC.
-
Circle
Circle opponent while firing. Used mainly by Aerotechs & Helos.
-
Mock
Mimic opponent's posture and adopt an untraceable accent
while remarking on his poor choice of camo.
Piloting Skills
The piloting skill parameter, passed-in as part of
the AI values, lets the designer go beyond the basic capabilities
inherent in a mech's type to specify, or limit, an individual
mech's fighting capabilities. Whereas the Gunnery Skill
parameter (a number between 1 and 6) supplied in the gp_spec decides
how good a shot a mech is, the piloting skill parameter decides
how well a mech maneuvers while engaging another mech. The list
below shows what capabilities correspond to what piloting skill
values. A value of 3, for example, means that a mech with a piloting
of 3 or better (<= 3) will have this capability:
1 - Kamikaze (allows mech to rush his target
and explode within damage proximity).
2 - Shot avoidance (can jump out of the way
to avoid certain projectile types - currently PPC and guided missiles).
3 - Use jump jets for all turns (speeds
up the turning process so AI mechs have more opportunities to
fire. Also allows mechs with one leg blown off to still rotate
into firing position).
3 - Jump jet maneuvers (shoot from above,
DFA, seek from below)
4 - Friendly-fire avoidance. (By turning it
off for a mech, he doesn't care if one of his own gets
in the way of his weapon).
5 - Turret rotation (if turned off, a mech
acts like a beginning player and never use turret swivel. Thus,
mechs can fire only when completely facing their target.)
6 - Limited use of ground maneuvers. (use
a subset of the normal maneuver list). NOTE: this option is not
implemented in the code.
Collision Avoidance
Part of a mech's, or any gamepiece's
ability to roam its environment and give the impression that it
knows what it's doing is «collision avoidance».
When moving gamepieces encounter mountains, other gamepieces,
buildings, or crater walls, they must make intelligent choices
about how to proceed so that they can carry out their orders.
This can be complicated by combat where a gamepiece may be engaged
in combat in a confined area with many obstacles. The collision
avoidance code is called whenever an AI gamepiece
is actually on the ground and moving, and is also used when a
human player's mech is in autopilot mode to take control
of the navigation. When avoiding an obstacle, the avoidance code
takes complete control of the gamepiece navigation system and
throttle, and overrides any current behavior.
The collision avoidance algorithm takes the straightforward
approach of sending a ray directly out in front of the gamepiece,
its length is dependent on ground speed. This dynamic ray length
allows fast moving gamepieces with a high closing speed to begin
avoiding earlier. Slow moving gamepieces, which don't
require as much lead time, use a shorter ray length. This is
most beneficial in enclosed, maze-like environments where a longer
ray would be easily confused by the abundance of walls.
For Mechwarrior 2: Mercenaries, the
AI will be modified to include additional, more complex personalities
over and above the existing ones. In addition to the original
clan AI , there will be a new category of AI which will describe
individual mechs within the game. This new personality AI is
divided into two seperate seperate categories, each specified
by a single value. First, the general AI will designate
a mech's affiliation and will describe his star's general behavioral
traits. Second, the personality AI will further define
an individual mech's behavior within the confines of his general
AI designation.
Arguments in .WTB files
For new Mercenaries missions,
AI personality types will be passed-in via two of the three remaining
AI values that are part of the gp_spec. This will free up the
gunnery skill parameter to be used for its original purpose of
specifying gunnery skill. Implementing these two new AI values
will require the modification of WASM, but will not change the
format of the .WTB files and therefore won't require the re-WASM'ing
of old missions. Please note that Ghost Bear style gp_specs (where
the gunnery skill is used to specify a personality) is no longer
supported.
New AI Values
AI values 6 and 7 will be used to declare the type of new AI used
for a mech. For instance,
gp_spec warhawk whk00std 3 leader internal destroy;defend; 2 250 400 400 2 0 6 "SJ Masakari" ""
has AI value 6 equal to 0 (Clan), and AI value 7 equal to 6 (Veteran Pilot).
This means that the format for gp_spec is now
gp_spec <chassis_name> <configuration> <group_id> <authority> <control> <appl_actions>
<gunnery_skill> <rubberband_range> <sleep_range> <target_range> <pilot_skill> <affiliation type> <personality> "<target_text>" "<contents_text>" <targeting>
The following conventions will be used to specify AI personalities.
-
If AI values 6 and 7 are zero, then that mech will use the original Mech II AI
- If AI values 6 and 7 are
not zero, then these AI values will specify new personality profiles
shown below.
In both cases, gunnery and piloting skill values will be used to specify
the mech's gunnery and piloting skill.
The actual values for AI parameters 6 and 7 will be as follows:
The first value, number six,
will specify the mech's type. The possible type values are:
0) Clan (default for original Mech II missions)
1) House Troops
2) Irregulars
The second value, number 7,
will specify the "Personality AI" type and, as of this
writing, will have the following designations:
0) None (default for original Mech II missions)
1) William Tell
2) Green Pilot
3) Leg Shooter
4) Alpha Strike
5) Missile Man
6) Veteran Pilot
7) Floater
New Personality Traits
The new AI variations will
be implemented internally by breaking them down into a set of
more specific parameters or "traits" which, when combined,
will describe the more general personalities. Game designers
do not have access to these individual traits. Instead, they
will specify the more general personality types using the new
AI values as described above. By reducing all peronalities to
a smaller set of variables, additional personailties can be implemented
as needed to produce a wide variety of behavior. The following
"traits" are used to describe all personalities:
- Toggle rules of engagement; 0=no rules, 1=honor rules
- Percent chance of flee vs. kamakasi; 0-100, 0=always flee, 100=always kamakasi
- Heat threshold before ceasing fire; 0-100, percentage of HEAT_DEATH
- Weapon grouping; 0=none, 1=all, 2=like weapons (by range)
- Percent chance of forced missile lock; 0-100, 0=never lock, 100=always lock
- Targeting order: 0=current (clan), 1=tgt. in reverse order, 2=tgt. randomly
- Specific targeting; 0=none, 1=target legs only
- Target leading: 0=none, 1=always lead target
- Stupid range: meters (currently exists)
General additions
1) Firing code modified to
cause firing until a) weapon depleted, or b) hardcoded weapon
regeneration time exceeded. After one of these is true, weapon
is advanced according to existing flags.
Mercenaries AI Tables
Here are the complete AI tables used in Mechwarrior 2: Mercenaries.
- DEFLT
flee M_DIST, '@', 1500, T_NULL, godirect, agp_home
follow M_TGTABLE, agp_enemy, &t, T_NOTIFY, follow, agp_myleader
godirect M_REACH, '@', &n, T_NULL, follow, agp_myleader
idle M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle 0
target M_REACH, '@', 350, T_NULL, attack, '%'
M_DESTROY, '@', 0, T_POP, follow, agp_myleader
M_DIST, agp_rbanchor, &r, T_POP, godirect, '%'
attack M_DESTROY, '@', 0, T_POP, follow, agp_myleader
M_DIST, agp_rbanchor, &r, T_POP, godirect '%'
M_DIST, '@', 350, T_NULL, target '%'
patrol M_TGTABLE, agp_enemy, &t, T_PUSH, target, '%'
M_REACH, '*', &n, T_NULL, follow, agp_myleader
rest M_TGTABLE, agp_enemy, &s, T_NOTIFY, rest, 0
shutdown M_FALSE, 0 0 T_NULL, shutdown 0
- FDEFEND
nothing M_FALSE, 0, 0, T_NULL, nothing 0
- FDESTROY
nothing M_FALSE, 0, 0, T_NULL, nothing 0
- FLEAVE
flee M_DIST, '@', &n, T_NULL, idle, 0
- FRECON
idle M_DIST, agp_myleader, 300, T_NULL, follow, '%'
M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle, 0
follow M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle, 0
target M_REACH, '@', 250, T_NULL, attack, '%'
attack M_DESTROY, '@', 0, T_POP, follow, agp_myleader
- LDEFEND
godirect M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle, 0
- LDESTROY
godirect M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle, 0
- LLEAVE
flee M_DIST, '@', &n, T_NULL, idle, 0
- LRECON
recon M_REACH, '@', 500, T_NULL, godirect, '@'
M_REACH, '@', 0, T_NULL, idle, 0
idle M_REACH, '@', 0, T_NULL, idle, 0
godirect M_REACH, '@', &n, T_NULL, idle, 0
M_TGTABLE, agp_enemy, &t, T_NOTIFY, idle 0
attack M_DESTROY, '@', 0, T_POP, godirect, agp_home
M_DIST, '@', 250, T_NULL, target, '@'