Technical Bible Humanoid enemy AI Enemy AI has one main

advertisement
Technical Bible
Humanoid enemy AI
Enemy AI has one main controller “tEnemyBrain.cs” that simply is a base controller and a state
handler of instances of states / controller of external attached game object scripts and has many
functions written within the “tEnemyBrain.cs” that when manipulated by instances, perform in game
tasks for example patrolling, attacking and chasing. With the functionality to also control scripts that
are attached to the enemies’ game object.
The diagram below shows the current scripts that are called within the enemy state manager,
dependent upon a certain scenario, variables / parameters, and the scripts attached the type of
enemies that use this system.
tEnemyBrain.cs
tAIPatrol.cs
tEnemyChaseState.cs
tAISight
tEnemyAttackState.cs
tEnemyRagdoll.cs
tAIMutantAttack.cs
tAIGunner.cs
Generally speaking, there tends to
be only one instance of a state at
any one time. These states can
categories as the following
patrolling, chasing and attacking.
The tEnemyBrain.cs works with
tAISight.cs to identify whether or
not the player is in sight. Based
upon this, the brain will determine
the type of approach the enemy
should take, for example if the
player is in sight, but out of weapon
range, tEnemyBrain would use an
instance of tEnemyChaseState.cs to
progress towards the target.
There’s more than one enemy
within the game, some of these
enemies within the game have the
need to perform the same functions
but with just different attack style.
tAIMelee.cs
tAIAttackSinglePistol.cs
State scripts use, functions
within tAIBrain, to access
scripts attached to the
enemy gameobject, in
which is used to controller,
whether or not an object,
for example a sword
should listen for a collision
witih for example a player.
tSwordCollision.cs
tFist.cs
A public enumerators in conjunction with a
function that is called in OnAwake() and
OnEnable() allows the brain to identify in which
enemy is currently using this system and from
this override certain states. For example,
selecting the Gunner enemy type within the
Unity inspector will mean that OnAwake() the
default tEnemyAttackState.cs is overridden with
the tAIGunner.cs.
Technical Bible
Image of multiple humanoid enemies using the same system within the current build as of
11/05/2015.

Humanoid, assault attacker / fights with guns.

Humanoid, mutant / fights with fists.

Humanoid, melee, mutant, single pistol and assault rifle enemies using the same state
machine.
Technical Bible
Drones
The drones within the game use a similar method to the Humanoid enemy system with regards to
the fact that the drone uses a state machine to split up the different states. The drones are designed
to simply follow a leader (invisible game object), the leader within the group searches for the player
and pinpoints a random location, near the player, this random location changes as the player
progresses and or when the leader reaches its target destination. This gives the illusion that drones
avoid each other, circle and attack the player (a threat).
Drone

Unity drone leader target position list with hardcoded radius offsets.
Technical Bible
Function that randomises the Unity drone leader target.
Modified previous semester work on flock controlling, giving the ability to the drones to flock
towards and around the player.
Other functions within drone manager include the handling of shooting bullets and death. For
example when the enemies health <= 0, the deathHandler() attempts to create the illusion that the
drone is no longer in control, by adding an explosion force the drones rigid body.
Editor
This section describes the use of code, developed to increase productivity within the Unity editor.
As previously explained there is many Humanoid types, these different types of enemies within the
game require different components to be added or modified for example bullets, fire rate, reload
time and more. It’s came to the attention the inspector always displayed fields that didn’t
necessarily needed to be filled in, in which sometimes caused confusion.
To clean this up EditorOverride.cs was developed. Based upon a public enumerator in the inspector
window, the EditorOverride.cs simply overrides the inspector and enables and disables the correct
fields for that enemy type - which require attachable components.
This is decided by using the OnInspector(GUI) with references to the script in which the developer
wants to change, and references to the Enumerator.
Technical Bible
EDITOROVERRIDE.CS
Based upon the enumerator selected, the correct functions are called, and as a result, the correct
fields are displayed.
EDITOROVERRIDE.CS
Line Ending Warnings
To fix line endings warnings the developers simply outsourced a script and place the script
“LineEndingsEditMenu” into the editor folder within the hierarchy.
LINEENDINGSEDITMENU.CS
Technical Bible
Controller
This section describes the scripts that are used at the highest most level, that are interconnect with
each other to control the outcome of the game, in terms of spawning / initiating the correct prefabs
and enabling / disabling the correct dependencies.
Net Manager
Handles the communication between the client and the server - in terms of creating rooms, and
enabling the player to connect to the server.
NETMANAGER.CS
Because this is one of the first scripts that get called, Net Manager is used to decide whether or not
the game should be in offline or online mode.
Based upon whether or not the client is in offline mode or online mode the script then uses simple
conditions to determine whether or not is should initiate objects locally or on the server.
NETMANAGER.CS
Technical Bible
Enemy spawning
Because the volume and frequency in which enemies spawn, die and respawn is high, the need for
object pooling arises, therefore a system has been created that uses the combination of enemies,
enemy spawning and object pooling.
Local pooling script enables developers to explicitly define which objects they want to spawn, the
intervals between each spawn process and the ability to add randomness to the equation.
There’s four simple steps in terms of defining the process of performing a successful pool from start
to finish. Firstly, if local pooling is enabled the pooler identifies the enemy prefab with the empty list
associate to that object and then OnAwake() the pool is created containing those objects.
Secondly, to actually spawn an enemy, one of the several functions within the local pooling script have
to be called, this is done by the player. When the player walks over an object with the tag “tActivator”,
Technical Bible
the OnCollisionHandler() (attached to the player) identifies and searches for the spawner script
attached to the trigger and calls upon it to start the spawning process.
Upon OnEnable() (on the spawning prefab, in the scene) the script, starts a coroutine in which handles
the spawning of the objects based upon the criteria set.
To actually spawn the enemy, the enemy spawner calls upon a public function within the local pool,
this then in return, grabs and sets active the enemy, into the scene.
TENEMYSPAWNER.CS
Technical Bible
In terms of recycling the enemy health script has a function that hadnles the recycle process, by
simple resetting variables, disabling components, and deactivate the prefab at the highest most
level.
TAISTATEMANAGER.CS
Impact manager
Is yet again another script that uses internal pooling but in this case for impact prefabs that
represent a collision between two objects? The setup is similar in terms of setting up the pool,
pulling and recycling back to the pull, the difference between both scripts purposes are different, in
this case impacts manager is called when the player shoots a ray from the weapon towards its
target, the initiation of impacts uses this information to use the first hit point of the ray, to be the
origin of the prefab.
IMPACTMANAGER.CS
Cinematic Camera - A system has recently been created in the means to allow developers to simply
override the current camera script and define where they want the camera to be and what object to
look at. This gives designers the ability to add quick cinematic snippets within the game, aiding to
the narrative of the game.
Technical Bible
TCINEMATICAMERA.CS
To enable the cinematic system firstly users have to set the bool NetManager.cs, gameobject,
inspector to use cinematics, secondly users have to define the transform positions within the
inspector.
TCINEMATICAMERA.CS
Technical Bible
The current system allows users switch the camera to lerp towards and look at certain objects based
upon a defined case statement.
TCINEMATICAMERA.CS
The system also enables users to toggle between different angles, camea positions with the ability to
set the duration of that certain camera angle / positon, before the camera lerps back towards
following the player.
Death Floor – In terms of defining boundaries in conjunction with cliffs and lava, a very simple
technique was used. This was to simply create a collider box with a tag name in this case
“deathfloor”.
Technical Bible
If and when player jumps / falls of the cliff the enemy should eventually hit collider with a box called
“deathfloor”.
This collision detection is identified by the script called tCollisionHandler(), in which
tCollisionHandler() is simply a script that listens out for collisions, if a collision has been identified in
which it meets a certain condition, the collision handler either tells the character to perform an
action and or tell the colliding object to perform an action, in this case, the collision handler decides
to communicate to the player, telling the player to process it’s death.
TPLAYERHEALTH.CS
Technical Bible
Checkpoint Manager – Connected Net manager game object within the hierarchy of Level1T, is a
script called tCheckpointManager.cs. This script simply stores the amount of defined placeholder
transforms (Checkpoints) within the world in an array.
Each checkpoint must be placed in sequential order and must be placed into the checkpoint
manager inspector window to declare it as a known checkpoint.
In the script tCheckpointManager there’s a current checkpoint ID the ID, simply refers to the index
number of the checkpoints placed within the tCheckpointManager script inspector window.
Every time the current ID increments we can assume that the next checkpoint in sequential order is
a checkpoint further from the start, closer to the end checkpoint.
Once the checkpoints have been placed in the world and the game is running, the player simply has
to run into one of the checkpoints, which has the tag name “tCheckPoint”.
Upon entrance, the player collision handler attempts to increment the current check point ID by
accessing the newcheckpointfunction(), which moves the checkpoint marker.
In terms of re-spawning the player character, the player calls the function “get current checkpoint”
into which the positon of current checkpoint positon is returned.
Technical Bible
Player
This section describes the script in which relate to the player.
Writing / Receiving Data
A script that decides whether or not the object in which this script attached to, is the actual player.
Based upon this the script either sends or receives data, disables / enables scripts attached to that
player.
Player Movement
The player is restricted to move in 8 different directions, these directions, dependent upon users
input, point towards at least one point on a compass for example, travelling north, south or
southwest. The player in terms of movement can jump and sprint, in which the player movement
script tells the animator what animation to play.
Technical Bible
Override Controller
A script designed for easy collaboration with other programmers, enabling other programmers to
easily override different aspects of the player, by referencing and calling functions within this script.
Grenade Handler
Receives players input, uses line renderer to create a grenade arc. The script also spawns a grenade
prefab, with a script attached to it called tGrenade.cs.
Technical Bible
Grenade
This a script requires input from tGrenadeHandler.cs in which the grenade passes a velocity for the
target, in which upon a Collison the tGrenade.cs, uses explosion prefabs, accompanied with the
deactivation of the gameobject, which in return gives the illusion that the object is exploding.
Weapon managing
Weapon Manager uses, at the core, the same state machine system in which the humanoid enemies,
use. Currently there are two main attacking scripts for this weapon system, which are
tAssaultRifle.cs and tShotgun.cs, these both call upon functions with the main body of the state
machine system, but the rate of fire, the type of bullet, animation and sound initiated when shooting
differentiate.
Player Rotation
The players body rotates on the lower and upper half of body, in which an algorithms embedded
within tPlayerRotateHandler script, identifies the current conditions of a player character, for
example the target direction in which the player in tends to move in relation to where the player is
looking (the cursor). Based upon this the player functions decide which way to rotate either the
upper or lower half of the body. This script used LateUpdate(), to override Mecanims animation
system.
Technical Bible
Player Health
Self-explanatory, the health script handles incoming collision and either applies damage the players
shield or the health, furthermore upon death, the health functions within this scripts enable ragdoll
and disable conflicting scripts that will effect ragdoll.
Player Shield
Controls the values of the shield objects / transparency, enables and disables particles effects based
upon collisions.
Player Energy
Player energy controls the energy bar, in which uses the weaponmanager current bullet count
values, and converts this into a certain percentatge, to indicate, visually, to the user to show
Player Footstep Audio
Reads the current velocity of the player, if the velocity of the player reaches a certain threshold
footsteps audio sounds will play.
Technical Bible
Player Ragdoll
Player Ragdoll simply controls the activation and deactivation of the child rigid bodies within the
player in which this script functions tend to be called from external scripts, and generally used to
simulate death, furthermore Ragdoll script records the original rotational and positional data in
which is used with a recycle function to avoid the player respawning with ragdoll activated.
Players Weapon, Laser Pointer
Controls the length of a line renderer, in which the script sets the origin and the end point of the
renderer, to identify the end, the laser pointer, simple shoots a laser towards the cursor, in which
the first hit point, is the end point for the line renderer. This technique tries to simulate what a laser
would do in real life.
Weapon Display
Uses weaponmanager public enumerator to identify the current weapon the player is holding and
then users this information to show an icon of the weapon.
Technical Bible
BulletCasing
Bullet casing handles the deactivation of the bullet casing after a period of time, in which it’s just set
to inactive, to be stored back in to the pool
.
CoinScript
Is a way to get virtual currency, which can be used for upgrades. When an enemy dies, coins are
spawn in which a magnet modifier is added to the coin script in the form of the coin floating towards
the player.
Section Spawning
Activators / deactivatosr with the means to try and enable / disable sections of the game within the
game world, with the use of triggers, to successfully identify and perform the correction functions
automatically.
The sections, uses coroutines to load assets once per frame, in which tries to avoid CPU / GPU
memory spikes.
Technical Bible
Destroying Objects
tDestroy.cs – if an object needs to be destroyed after a certain amount of time, this simple script
enables developers to do so, enabling developers to set the duration in terms of the life span, in
seconds of the object in whicht the script is attached to.
Automatic doors & Manual Doors
Has been added to the game, sectioning off parts of the level into sections, enables optimisation
increases. There’s two types of doors, Automatic & manual.
Automatic doors, simply open upon entry and close for good behind the user.
Manual Doors require Nina to hack the door, this representation requires the user to hold down a
selection button, this makes Nina move towards a hackable terminal, and start to hack the door.
Download