A.I. in Conquest

<tabber>
Strategic A.I.=
Conquest Mode Strategic A.I. Layer
What is it?
In Conquest mode, as it currently stands, A.I. run around randomly, attacking/defending command posts in accordance with their own thoughts. There is no strategy, no coordination, and, as a result, single-player Conquest battles appear random and (potentially) uninteresting. The Strategic A.I. Layer is a VM script that underlines each Conquest match and controls if, when, and how A.I. choose to attack capital ships and command posts.
High-Level Goals of the Strategic Layer
*To coordinate A.I. behaviour so they attack and defend Command Posts as a team.
*To give designers control over how the A.I. approaches each map:
**How often they choose to attack command posts and capital ship components / interior reactor. 
**Which CPs they consider to be “important”, and attack more than others (effectively a weighting for command posts).
**To allow for the inclusion of other level-specific behaviour, such as flagging the Hoth Shield Generator as being a goal for the Imperials on that map (and a structure for the Rebels to defend), Endor to cater for the inclusion of the Death Star rather than frigates, etc.
*To potentially simulate a battle happening elsewhere on the battlefront without the need for actual A.I. to be present:
**Command posts change hands while the player is battling A.I. on the enemy frigate, with all the available A.I. still focused around the player.
**The player is told their frigate reactor is under attack while they are fighting on the ground, without the need to waste valuable A.I. resources drawing them where the player cannot see them.
**As the player moves between layers, A.I. spawn to populate these areas in accordance with the simulation, creating the illusion that the battle was always happening there.
**See the ‘Combat Density vs. Player-Focused A.I.’ section for more.
Required Functionality of the Strategic Layer
Command Post Capture Simulation
*The Strategic Layer script will need to drive a significant number of A.I. to attack single command posts at any one time, with the CP selected via internal dice-rolling:
**Each CP attack will be signposted via talking head radio chatter.
**Each attack will need to continue until there is a resolution to the conflict, and the CP is either successfully defended or captured by the enemy
***The probability of either outcome will need to be decided through, effectively, a simulated dice roll.
**If the CP is located in an open area (such as the Bridge in Tatooine), enemy bombers / fighters will need to use splines attached to that CP to conduct bombing / strafing runs on the location.
***This will require code as splines cannot currently be linked directly to CPs.
**There will need to be time intervals between these attacks (again dictated through a dice roll) to prevent the player being bombarded with constant messages and feeling overwhelmed by what is happening around him.
**If the player travels to an allied CP that is under attack and successfully engages a number of enemy units there, the probability of that CP being defended should increase (the defending A.I. should become more ‘capable’ of doing their job in some fashion)?
**The CP capture phase will need to behave in a manner that seems believable:
***The length of time needed to capture a CP should vary to indicate A.I. being killed while trying to capture it (essentially the balance of power shifting).
***If the simulation dictates that the CP is switched to neutral, it should again remain in that state for a random period of time to create the illusion of a real battle happening around it.
***After this time, the CP should either go back to its original colour (to show it has been successfully defended) or change to the enemy colour.
**If the Strategic A.I. is simulating a conflict over the last remaining allied CP, we should consider putting special rules in place to ensure the CP does not stay in a neutral state for longer than ~20 seconds (as the player will not be able to spawn in if killed), and the bias should potentially favour the allied team slightly (so it is less likely that the match will come to an end in this fashion).
Weighting Command Posts and Frigate Components
*Through the Strategic Layer script, designers will need to be able to attach a weighting to command posts and frigate components:
**The Bridge CP is more frequently contested than the Wreckage CP, for instance.
*This helps to sell the idea that the A.I. are thinking tactically, and also helps to ensure that Base CPs are not contested over (and potentially lost) immediately.
Frigate Assault Simulation
*The Strategic Layer script will need to govern assaults on frigates too:
**A.I. factions will need to coordinate attacks on enemy frigates.
**These attacks can be one of four types:
**#Assaults on the turrets
**#Assaults on the exterior components
**#Bombing / strafing runs (general frigate attacks)
**#Landing in the hangar and attempting to destroy the reactor
**Each of these will need different probabilities attached to them.
**In the case of option 4, the simulation will need to cater for the A.I. – destroying the reactor shield console first before moving on to attack the reactor.
***Random-chance probabilities will need to exist for success or failure in both of these stages.
***If the simulation dictates that the A.I. have successfully defended the shield console or the reactor, probabilities should be in place to dictate if they then repair the shield console (restoring the reactor shield if it is down).
**As with command post capture, if the player travels to the allied frigate and joins the bid to defend it, defeating numerous attacking enemies in that area, the probability of the assault being repelled will increase (the A.I. working with the player will “step up their game” in some fashion)?
Ion Cannon / Orbital Strike Cannon Simulation
*The Strategic Layer script will need to govern both Ion Cannon and Orbital Strike use.
*The Ion Cannon can be used for:
**Targeting capital ship components
**Targeting a capital ship
**Shooting at flying fighters (although the probability of scoring a hit is low)
*The Orbital Strike Cannon can be used for:
**Targeting ground infantry and vehicles
**Shooting at flying fighters (although the probability of scoring a hit is low)
*Probabilities need to be attached to each of these, with the outcome dictated through the internal dice roll.
*In both cases, projectiles need to be ‘steered’ through the air towards their target by the A.I..
**There should be a probability attached to the A.I. missing their target through steering incorrectly.
*Projectiles can also be detonated at any time by the A.I. to damage any nearby fighters.
*Probabilities needed so that the Ion Cannon occasionally targets where the player is, and at other times targets enemy CPs and vehicles.
Escape Pod Simulation
*When the player is outside of either frigate, the simulation needs to attach a probability to launching escape pods down to the ground layer (both allied and enemy).
*Five escape pods can launch from a frigate at any one time. A probability should probably be associated with each of these, meaning more than one escape pod could launch at a time.
*A high probability should be attached to having the escape pods land near the player’s location.
Vehicle Use Simulation
*Through the simulation, A.I. should consider using vehicles when available in accordance with the vehicle behaviour document.
*On Hoth, for example, it is essential that the A.I. still attempt to attack the shield generator with AT-ATs and AT-STs even though the player is in space inside a frigate.
**A probability of these vehicles being destroyed could be applied through the simulation to continue the battle as would be happening.
Hero Vehicle Spawns
*Flying A.I. can be awarded a hero vehicle ship (such as the Millennium Falcon) for scoring large numbers of points.
*The simulation A.I. should aim to bring these vehicles towards the player’s location.
**If the player is on the ground, have them fly within the atmosphere
**If the player is on the enemy frigate, have them fly around that ship
Unique Scripts per Map
*A unique Strategic Layer script will need to exist for each Conquest map to cater for the various map designs and level features:
**Hoth is a special-case map with a shield generator controlling a shield that encompasses the majority of the ground area. The main Imperial goal is to destroy this, so ships from their frigate can fly freely and land.
Layer A.I. Respawning vs Player-Centric A.I.
There exists some “uncertainty” with regard to the current combat density solution, where A.I. respawn continually from around the map to be near the player. A potential alternative to this system is spawning and despawning A.I. in layers (ground or space) instead. For example, if the player travels from a frigate down to the ground, all the A.I. that were in that frigate would despawn / turn off, and A.I. spawners on the ground would become active instead. A super-cheap simulation of the A.I. (an extension of what was discussed above) would be used on any layers of the VBF the player was not located in to ensure that command posts were still captured and points were still scored while the player was not around. Effectively a dice rolling system for A.I. in distant layers, instead of populating those layers with physical A.I. units.
Other features of this system could be:
*A pool of A.I. names could exist for the A.I. to use. When they spawn in, they select a name that is not already in use, ensuring the player cannot fly away from “Battle Droid Tom” on the ground only to land on a frigate and have “Battle Droid Tom” rush at you because he respawned there.
*The super-cheap simulation A.I. would store details of the number of A.I. that were present in a layer when the player left it and would run its simulation based on that figure. Subsequently, the player would not be able to fly out of a frigate leaving two friendly A.I. behind, turn back and land in the same frigate to find a 25 vs. 25 battle happening because new units have spawned in.
*Instead of respawning near the player, A.I. located at a distance to the player would sprint (potentially faster than they could normally?) to get within range of them when not visible (like in the previous Battlefront games).
Potential Issues to Consider
*Infantry and vehicle combat – can we simulate believable combat taking place on layers the player is not in?
**Teams would need to score points for killing infantry and vehicles while the player is not around.
**If I left 10 of my guys on my frigate battling 1 enemy, I would not expect that enemy to kill off of all of my guys.
**When arriving at a new layer, I would expect to find damaged units / vehicles, potentially destroyed Ion Cannon Consoles / Health Droids, damaged turrets, etc.
**Can we simulate such things in a believable manner?
*When on a turret in a frigate, A.I. will need to be populating the space area outside of that frigate in fighters:
**If the player looks out of a frigate window or looks out of the hangar entrances, they need to see action.
*When using the Ion Cannon or the Orbital Strike Cannon, the player will need to see action happening in the other layer in accordance with the simulation.
*Some of our ground maps are less open than others, with numerous CPs located indoors and at a distance to the player.
**Can we simulate A.I. attacking and defending these CPs while all of the ‘real’ A.I. are around the player, and spawn A.I. at these CPs when the player gets closer to them?
Advantages of this System over Player-Centric A.I.
*Allows us to focus all active A.I. on the player’s experience, removing the need to have physical units active in areas when they are not directly affecting the player (saving resources both in terms of rendering and computations).
*The full quota of A.I. can be in the same layer as the player instead of spread over the VBF, creating a greater sense of combat density than we have now.
*Eliminates the occasionally very obvious ‘popping in’ of A.I. we have now, where players can turn their back on an empty room, turn around again and find two or three A.I. have spawned in there (because they were respawned off-screen).
**A.I. within range of the player would spawn at command posts rather than out of thin air, fitting in with the Conquest mechanic and addressing any such issues.
*It helps to eliminate the obvious naming problems we have with the current respawning system, where the player can run away from “JellyJoey”, run into the next room and find “JellyJoey” there again because he has respawned.
*The player-centric A.I. system has been known to “break” where more unique characters are involved.
**Bugs have been present where Hero characters (Darth Vader) have been respawning around the player (Force Teleport?)
*Understandably, A.I. do not like being respawned around a level (it interferes with their objective states), and it can become jarring as players see A.I. standing around working out a new objective).
Disadvantages of this System over Player-Centric A.I.
*Would this system work in split-screen if one player was on a frigate, and the other on the ground?
**Is it workable to have the A.I. split between each player?
*If all A.I. are focused around the player on the ground, no distant Command Posts on the same layer would ever change hands.
**Can these be simulated in a similar way without real units, and we only spawn in real units when the player gets close?
**Alternatively, if we use real A.I. for this scenario, would we be able to achieve an acceptable level of Combat Density (better than we have now) with 50 A.I. spread around the ground layer?
*The space layer (and flying area above the ground), need to always be populated with vehicles and general combat activity:
**Can we afford to have 50 units on the ground, and also have flying vehicles active?
*A.I. unit naming – can we use a pool of names and a check to see which names are “available” (if the character is still alive), to name our A.I. such that the player does not fly off from an ally called “Bob” on the ground, land in the enemy frigate and find “Bob” already on board fighting (because the ground layer have been despawned and the space layer have spawned in)?
**Can the simulation be aware that “Bob” is still active on the ground, and therefore cannot also be in space?
*Believability – the player has to believe that a real battle is happening around them:
**Command posts cannot just change from Red to Blue – they have to be captured in a believable manner (going from Blue to White and, after a number of seconds, back to Blue to show it was successfully defended, etc).
**The health of the frigate components cannot just slowly decrease – they need to decrease as though being attacked by real players.
**Can we simulate these features in a believable way?
|-|A.I. Vehicle use in Conquest=
A.I. Vehicle use in Conquest
This document is designed to answer one question:
How should the A.I. use vehicles in Conquest?
What follows is a series of statements the A.I. adheres to. 
Design-wise, we are not bothered about the details of HOW it accomplishes these statements, only that it DOES accomplish them.
Getting In
*The A.I. always attempts to get into any vehicle with empty user slots near it (needs distance defining).
*If the A.I. is engaged in a combat situation where it is not outnumbered, it does not attempt to enter a nearby vehicle.
*If the A.I. is engaged in a combat situation where it is outnumbered, it attempts to enter a nearby vehicle.
*If the A.I. is capturing a CP, it does not attempt to enter a nearby vehicle.
*Only the number of A.I. who can occupy a vehicle attempt to enter that vehicle.
*If a vehicle is driving past within a certain range, the A.I. attempts to get into that vehicle.
*If the A.I. is unable to get into a passing by vehicle within a certain time, the A.I. stops is attempt to get in and continues on foot.
*If the A.I. is unable to get into a passing by vehicle as the vehicle moves beyond a certain distance, the A.I. stops is attempt to get in and continues on foot.
*If the A.I. is in the driving position of a vehicle and is near to the player, it calls for the player to ‘get in’ and waits.
*If the player comes closer to the A.I.-driven vehicle while it is waiting for the player, the A.I. continues to wait.
*If the player moves away from the A.I.-driven vehicle while it is waiting for the player (needs distance set), the A.I. stops waiting and decides another action.
*If a small amount of time (needs defining) passes and the player has not entered the A.I.-driven vehicle while it is waiting for the player, the A.I. stops waiting and decides another action.
*The A.I. driver does not ‘wait for a player to get in’ more than once every 5 minutes if it continues to be the driver of the vehicle for that time.
*If an A.I.-driven vehicle passes by an A.I. who attempts to enter an empty slot on the vehicle, the A.I. driver stops and waits for the on-foot A.I. to enter.
Travelling
*Once driving a vehicle, the A.I. driver plans where to go based on the current attack plan of the entire A.I. team (feature as discussed on 09/04/2008).
*If the A.I. is in a vehicle and the attack plan is to take a CP which is inside a vehicle exclusion zone, the A.I. drives as far as possible towards the CP and exits the vehicle to continue on foot when it hits the boundary for the exclusion zone.
Attacking
*The A.I. should always use the vehicle it is currently in if attacking a CP which can be captured by vehicles (i.e. not inside a vehicle exclusion zone).
*When using a vehicle (driver or gunner), the A.I. attacks targets in its attack range in a prioritized order of greatest threat to lowest threat.
*The threat priority list includes all threatening units currently being used by A.I. and players: vehicles, turrets, characters on foot, and airborne vehicles within firing range and angle.
*When using an airborne vehicle, the threat priority list is different than for ground vehicle use.
*If no targets are within firing range of the A.I. gunner, the A.I. gunner targets the nearest potential target and does not fire.
Assisting
*The A.I. inside a vehicle (driver or gunner) also assists players who are not in the vehicle.
*The A.I. threat priority list contains an entry to ‘assist players’.
*This is so that the A.I. attack targets which are attacking players not in the vehicle if the threat to the player is greater than that of the vehicle.
*One example would be: A player is on foot being attacked by infantry (with no anti-vehicle infantry in the vicinity), an A.I.-driven vehicle (or A.I. gunner in a vehicle) is near. The A.I. driver/gunner’s priority is to assist the player by attacking the A.I. infantry who are attacking the player.
Getting Out
*A.I. characters only get out of a vehicle for two conditions:
*Firstly, as previously mentioned, when attacking a CP that cannot be attacked in a vehicle.
*Secondly, if a player enters a vehicle which is full, but has a slot taken by A.I.. This forces the A.I. to exit the vehicle, giving up their space for the player.
*A.I. characters swap position with a player if that player tries to swap to a position in a vehicle taken by an A.I. character.
</tabber>
==References==
* BFIII Conquest Mode Strategic AI.doc (02/05/2008)
* AI Vehicle use in conquest.doc (11/04/2008)
Category:Internal & Technical