Game System

1
Game System
2
Simplify Your Thinking into Modula (1/2)

• Control system
• User input
• Mouse or keyboard
• Keyboard layout
• Camera control
• View angle
• View range
• Interaction with player
• A walk through system
• Combat system
• Controls
• Motion management and blending
• NPC AI
• FX
• Visual
• Audio

3
Simplify Your Thinking into Modula (2/2)

• Reward system
• Number system
• Levels
• Damage
• User Interface
• Menu
• Mini-map
• Messages
• Blood bar
• Caption
• The main program
• Main loop
• Level management
• Configuration
• Save/Load

4
(No Transcript)
5
Game AI Steering Behavior
6
Motion Behavior

• Action selection
• Steering
• Locomotion

7
Action Selection

• Game AI engine
• State machine
• Discussed in Finite State Machine section
• Goals
• Planning
• Strategy
• Scripting
• Assigned by players
• Players input

8
Steering

• Path determination
• Path finding or path planning
• Discussed in Path Finding
• Behaviors
• Seek flee
• Pursuit evasion
• Obstacle avoidance
• Wander
• Path following
• Unaligned collision avoidance
• Group steering

9
Locomotion

• Character physically-based models
• Movement
• Turn right, move forward,
• Animation
• By artists
• Implemented / managed by game engine

10
A Simple Vehicle Model (1/2)

• A point mass
• Linear momentum
• No rotational momentum
• Parameters
• Mass
• Position
• Velocity
• Modified by applied forces
• Max speed
• Top speed of a vehicle
• Max steering force
• Self-applied
• Orientation
• Car
• Aircraft

11
A Simple Vehicle Model (2/2)

• Local space
• Origin
• Forward
• Up
• Side
• Steering forces
• Asymmetrical
• Thrust
• Braking
• Steering
• Velocity alignment
• No slide, spin,
• Turn

12
Euler Integration

• The approach
• Steer_force Truncate(streer_direction,
  Max_force)
• Acceleration Steer_force / mass
• Velocity Truncate(Velocity Acceleration,
  Max_speed)
• Position Position Velocity

13
Seek Flee Behaviors

• Pursuit to a static target
• Steer a character toward to a target position
• A moth buzzing a light bulb
• Flee
• Inverse of seek
• Variants
• Arrival
• Pursuit to a moving target

• Seek Steering force
• desired_velocity normalize(target -
  position)max_speed
• steering desired_velocity velocity

14
Arrival Behavior

• One of the idea a stopping radius
• Outside the radius, arrival is identical to seek
• Inside the radius, the speed is ramped down to
  zero
• target_offset target position
• distance length(target_offset)
• ramped_speed max_speed(distance/slowing_distanc
  e)
• clipped_speed minimum(ramped_speed, max_speed)
• desired_velocity (clipped_speed/distance)target
  _offset
• steering desired_velocity velocity

15
Pursuit Evasion Behaviors

• Target is moving
• Apply seek or flee to the targets predicted
  position

• Estimate the prediction interval T
• T Dc
• D distance(pursur, quarry)
• c turning parameter

• Variants
• Offset pursuit
• Fly by

16
Obstacle Avoidance Behavior

• Use bounding sphere
• Not collision detection

• Probe
• A cylinder lying along forward axis
• Diameter characters bounding sphere
• Length speed (means Alert range)
• Find the most threaten obstacle
• Nearest intersected obstacle
• Steering

17
Wander Behavior

• Random steering
• One solution
• Retain steering direction state
• Constrain steering force to the sphere surface
  located slightly ahead of the character
• Make small random displacements to it each frame
• A small sphere on sphere surface to indicate and
  constrain the displacement

• Another one
• Perlin noise
• Variants
• Explore

18
Path Following Behavior

• The path
• Spine
• A spline or poly-line to define the path
• Pipe
• The tube or generated cylinder by a defined
  radius

• Following
• A velocity-based prediction position
• Inside the tube
• Do nothing about steering
• Outside the tube
• Seek to the on-path projection

• Variants
• Wall following
• Containment

19
Flow Field Following Behavior

• A flow field environment is defined.
• Virtual reality
• Not common in games

20
Unaligned Collision Avoidance Behavior

• Turn away from possible collision
• Predict the potential collision
• Use bounding spheres

• If possibly collide,
• Apply the steering on both characters
• Steering direction is possible collision result
• Use future possible position
• The connected line between two sphere centers

21
Steering Behaviors for Groups of Characters

• Steering behaviors determining how the character
  reacts to the other characters within his/her
  local neighborhood
• The behaviors including
• Separation
• Cohesion
• Alignment

22
The Local Neighborhood of a Character

• The local neighborhood is defined as
• A distance
• The field-of-view
• Angle

23
Separation Behavior

• Make a character to maintain a distance from
  others nearby.
• Compute the repulsive forces within local
  neighborhood
• Calculate the position vector for each nearby
• Normalize it
• Weight the magnitude with distance
• 1/distance
• Sum the result forces
• Negate it

24
Cohesion Behavior

• Make a character to cohere with the others nearby
• Compute the cohesive forces within local
  neighborhood
• Compute the average position of the others nearby
• Gravity center
• Apply Seek to the position

25
Alignment Behavior

• Make a character to align with the others nearby
• Compute the steering force
• Average the together velocity of all other
  characters nearby
• The result is the desired velocity
• Correct the current velocity to the desired one
  with the steering force

26
Flocking Behavior

• Boids Model of Flocks
• Reynolds 87
• Combination of
• Separation steering
• Cohesion steering
• Alignment steering
• For each combination including
• A weight for combing
• A distance
• An Angle

27
Leader Following Behavior

• Follow a leader
• Stay with the leader
• Pursuit behavior (Arrival style)
• Stay out of the leaders way
• Defined as next position with an extension
• Evasion behavior when inside the above area
• Separation behavior for the followers

28
Behavior Conclusion

• A simple vehicle model with local neighborhood
• Common steering behaviors including
• Seek
• Flee
• Pursuit
• Evasion
• Offset pursuit
• Arrival
• Obstacle avoidance
• Wander
• Path following

• Wall following
• Containment
• Flow field following
• Unaligned collision avoidance
• Separation
• Cohesion
• Alignment
• Flocking
• Leader following

• Combining the above behaviors in your application

29
Game AI Finite State Machine
30
Introduction (1/2)

• Finite State Machine (FSM) is the most commonly
  used game AI technology today.
• Simple
• Efficient
• Easily extensible
• Powerful enough to handle a wide variety of
  situations
• Theory (simplified)
• A set states, S
• An input vocabulary, I
• Transition function, T(s, i)
• Map a state and an input to another state

31
Introduction (2/2)

• Practical use
• State
• Behavior
• Transition
• Across states
• Conditions
• Its all about driving behavior
• Flow-chart diagram
• UML State chart
• Arrow
• Transition
• Rectangle
• State

32
An Example of FSM As a Diagram
Monster in sight
Gather Treasure
Flee
No monster
Monster dead
Cornered
Fight
33
FSM for Games

• Character AI
• Decision-Action model
• Behavior
• Mental state
• Transition
• Players action
• The other characters actions
• Some features in the game world

34
Implement FSM

• Code-based FSM
• Simple Code One Up
• Straightforward
• Most common
• Macro-assisted FSM Language
• Data-Driven FSM
• FSM Script Language

35
Coding an FSM Code Example 1
void RunLogic(int state) switch(state)
case 0 // Wander Wander()
if (SeeEnemy()) state 1 if
(Dead()) state 2 break case
1 // Attack Attack() state
0 if (Dead()) state 2
break case 2 // Dead
SlowlyRot() break
36
Coding an FSM Code Example 2
void RunLogic(FSM fsm) // Do action based
on the state and determine next input input
0 switch(fsm-gtGetStateID()) case
0 // Wander Wander() if
(SeeEnemy()) input SEE_ENEMY if
(Dead()) input DEAD break case
1 // Attack Attack() input
WANDER if (Dead()) input DEAD
break case 2 // Dead
SlowlyRot() break // DO state
transition based on computed input
fsm-gtStateTransition(input)
37
Mealy Moore Machines

• Mealy machine
• A Mealy machine is an FSM whose actions are
  performed on transitions
• Moore machine
• A Moore machines actions reside in states
• More intuitive for game developers

38
FSM Language Use Macros

• Coding a state machine directly causes lack of
  structure
• Going complex when FSM at their largest
• Use macros
• Beneficial properties
• Structure
• Readability
• Debugging
• Simplicity

39
FSM Language Use Macros An Example
define BeginStateMachine define State(a)
bool MyStateMachineStates(StateMachineEvent
event, int state)
BeginStateMachine State(0)
OnUpdate Wander() if
(SeeEnemy()) SetState(1) if (Dead())
SetState(2) State(1) OnUpdate
Attack() SetState(0)
if (Dead()) SetState(2) State(2)
OnUpdate RotSlowly()
EndStateMachine
40
Data-Driven FSM

• Scripting language
• Text-based script file
• Transformed into
• C
• Integrated into source code
• Bytecode
• Interpreted by the game
• Authoring
• Compiler
• AI editing tool
• Game
• FSM script engine
• FSM interface

41
Data-Driven FSM Diagram
Authoring
Games
FSMs
bytecode
FSM Script Engine
Compiler
Artist, Designers, Developers
AI Editing Tool
FSM Interface
Condition Action Code
Game Engine
Condition Action Vocabulary
42
AI Editing Tool for FSM

• Pure text
• Syntax ?
• Visual graph with text
• Used by Designers, Artists, or Developers
• Non-programmers
• Conditions action vocabulary
• SeeEnemy
• CloseToEnemy
• Attack

43
FSM Interface

• Facilitating the binding between vocabulary and
  game world
• Glue layer that implements the condition action
  vocabulary in the game world
• Native conditions
• SeeEnemy(), CloseToEnemy()
• Action library
• Attack()

44
FSM Script Language Benefits

• Accelerated productivity
• Contributions from artists designers
• Ease of use
• Extensibility

45
Processing Models for FSMs

• Processing the FSMs
• Evaluate the transition conditions for current
  state
• Perform any associated actions
• When and how ?
• Depend on the exact need of games
• Three common FSM processing models
• Polling
• Event-driven
• Multithread

46
Polling Processing Model

• Processing each FSM at regular time intervals
• Tied to game frame rate
• Or some desired FSM update frequency
• Limit one state transition in a cycle
• Give a FSM a time-bound
• Pros
• Straightforward
• Easy to implement
• Easy to debug
• Cons
• Inefficiency
• Some transition are not necessary to check every
  frame
• Careful design to your FSM

47
Event-driven Processing Model

• Designed to prevent from wasted FSM processing
• An FSM is only processed when its relevant
• Implementation
• A Publish-subscribe messaging system (Observer
  pattern)
• Allows the engine to send events to individual
  FSMs
• An FSM subscribes only to the events that have
  the potential to change the current state
• When an event is generated, the FSMs subscribed
  to that events are all processed
• As-needed approach
• Should be much more efficient than polling ?
• Tricky balance for fine-grained or coarse-grained
  events

48
Multithread Processing Model

• Both polling event-driven are serially
  processed
• Multithread processing model
• Each FSM is assigned to its own thread for
  processing
• Game engine is running in another separate thread
• All FSM processing is effectively concurrent and
  continuous
• Communication between threads must be thread-safe
• Using standard locking synchronization
  mechanisms
• Pros
• FSM as an autonomous agent who can constantly and
  independently examine and react to his
  environment
• Cons
• Overhead when many simultaneous characters active
• Multithreaded programming is difficult

49
Interfacing with Game Engine (1/2)

• FSMs encapsulate complex behavior logic
• Decision, condition, action,
• Game engine does corresponding
• Character animation, movements, sounds,
• The interface
• Code each action as a function
• Need recompile if any code is changed
• ie., FleeWolf()
• Callbacks
• Function pointers
• ie., actionFunctionfleeWolf()
• Container method
• actionFunctions-gtFleeWolf()
• DLL

50
Interfacing with Game Engine (2/2)

• Take TheFly3D as example

class AArmyUnit public FnCharacter
void DoAttack() AArmyUnit army army-gtObjec
t() army-gtMoveForward(dist, ) army-gtDoAttack
()
51
FSM Efficiency Optimization

• Two categories
• Time spent
• Computational cost
• Scheduled processing
• Priority for each FSM
• Different update frequency
• Load balancing scheme
• Collecting statistics of past performance
  extrapolating
• Time-bound for each FSM
• Do careful design
• At the design level
• Level-of-detail FSMs

52
Level-Of-Detail FSMs

• Simplify the FSM when the player wont notice the
  differences
• Outside the players perceptual range
• Just like the LOD technique used in 3D game
  engine
• Three design keys
• Decide how many LOD levels
• How much development time available ?
• The approximation extent
• LOD selection policy
• The distance between the NPC with the player ?
• If the NPC can see the player ?
• Be careful the problem of visible discontinuous
  behavior
• What kind of approximations
• Cheaper and less accurate solution

53
Extending the Basic FSM

• Extending states
• Begin-end block

BeginDoAction() DoActions() EndDoAction()

• Stacks FSMs
• Stack-based history of FSMs
• Remember the sequence of states passed through
• Retrace its steps at will
• Hierarchical FSM
• Polymorphic FSMs
• Fuzzy State Machine
• Combined with fuzzy logic

54
A Hierarchical FSM Example
Monster in sight
Gather Treasure
No monster
Flee
Monster dead
Fight
Cornered
Find Treasure
Active FSM
Go To Treasure
Gather Treasure
Find Treasure
Live
Stack
Take Treasure
55
Another Hierarchical FSM Example
Patrol
Done
Done
Noise
Investigate
Saw Enemy
Attack
Saw Enemy
Go to A
Look for Intruders
Go to B
Look for Intruders
Patrol
noise
noise
Report Noise
Go Over To Noise
Look for Intruders
False Alarm!
Investigate
56
More Topics in Game AI

• Scripting
• Goal-based planning
• Rule-based inference engine
• Neural network
• References
• Game Gems
• AI Game Programming Wisdom

57
Shadows (brief version)
58
Contents

• Fake shadow
• Traditional projected shadow
• Two-pass shadow rendering
• Projective texture mapping
• Shadow mapping (shader)
• Shadow volume

59
Shadows
60
Traditional Projected Shadow

• By Jim Blinn
• Me and My (Fake) Shadow
• IEEE Computer Graphics and Applications, January,
  1988
• Project the geometry on the ground plane.
• Scale the height to zero.
• Make the shadow material to black.
• Polygon solution
• Flat shadow on the ground.

61
Two-pass Shadow Rendering

• First pass
• Treat the light source as the camera.
• Assign the material color of the object (to be
  shadowed)
• 1 shadow_color
• Render the object on a texture (shadow map).
• Second pass
• Texture map the shadow map on the terrain with
• Source_blend zero
• Destination_blend 1 source_color
• Pros
• Easy to implement
• Cons
• Texture resolution
• Z fighting
• Aliasing

62
Game Control System
63
Introduction (1/2)

• Game control is the interface between the game
  and the user.
• Game control is not only input device control but
  also camera control
• Input device control
• On PC
• Mouse
• Keyboard
• Gamepad
• On game console
• Gamepad
• 0 or 255
• Joystick
• 0 - 255

64
Introduction (2/2)

• Camera control
• First-personal view
• Third-personal view
• God view
• Pre-set camera view

65
Mouse Control (1/3)

• Mouse is a 2D device.
• 2-axis moving
• Related movement
• 2 or 3 buttons
• Mouse can
• Move
• Drag
• Double-click
• Behaviors
• Hit test
• Selection
• Pilot
• Position orientation

66
Mouse Control (2/3)

• Typical game types using mouse control
• Real-time strategy games
• Role Playing Game
• Typical game play examples
• Path finding for playable character
• Hitting the enemy
• Selecting a group of units
• Orientating the camera in FPS games
• Menu selection
• Features
• Always coupling with god-view camera control
• Viewing from the top of game world

67
Mouse Control (3/3)

• Easy to hand on
• ????
• Slow action
• Compared with joystick
• Value range from -32727 - 32727

68
Keyboard Control (1/3)

• Standard PC input device
• Simulating the gamepads usually
• Not every PC game player having gamepad
• Using keyboard as the alternative device
• Hotkey system
• Each key has two states.
• Pressed
• Released
• 256 keys
• Behaviors
• Key presses/released
• ASCII code
• One hotkey can represent a command

69
Keyboard Control (2/3)

• Communication tool
• Typing messages
• Typical game types using keyboard
• MMORPG
• Needs chatting with friends
• Real-time strategy games
• Hotkey system
• First-person shooting games
• Fighting games
• Typical game play examples
• Chatting
• Character controls
• Move forward
• Turning

70
Keyboard Control (3/3)

• Features
• Shortcut for a sequence of actions
• Commands
• Menu selection
• But a little bit complicated for players
• 256 keys

71
Gamepad Control (1/3)

• A small keyboard designed for game playing
• Gamepad can map to the hotkey system
• Same behaviors
• Less than 20 keys
• Majors keys

72
Gamepad Control (2/3)

• Recent gamepad capable of two extra digital
  joysticks
• For keys
• Value range 0 or 255
• For joystick
• Value range 0 to 255
• Typical game types using gamepad
• Almost all types of games except
• Need typing
• Need large-range selection for game units
• Typical game play examples
• Character controls
• Move forward
• Turn

73
Gamepad Control (3/3)

• Combat system in a fighting game
• Move forward
• Turn
• Features
• Designed for game playing
• Look and feel
• Easy to hand-on
• If you not to challenge the players usual
  practice

74
Camera Control

• Types
• First-personal view
• Third-personal view but following the playable
  character
• God view
• Fixed
• Following the playable character
• Fixed view
• Pre-rendered background
• Pre-set view
• Very sensitive to game play design game control
• Camera control is not an independent system

75
God-view Camera Example
Age of Empire 3
76
Game Control Case Study Third-personal View
(1/6)

• Use arrow keys on keyboard or gamepad

• Basic key assignments
• Up key to move the playable character forward
• Down key to turn character facing to the camera
  and move forward
• Left right keys to turn the character to left
  or right

77
Game Control Case Study Third-personal View
(2/6)

• The camera following the character to move
• And keeping a range of distance, a reasonable
  height and look-down angle with the character.

78
Game Control Case Study Third-personal View
(3/6)

• Detailed key assignments
• Up key
• Turn the character facing back to the camera
• Move the character forward
• If the distance between the character and the
  camera is larger a pre-set range, move the camera
  forward to keep the distance.
• At the same time, the height to the ground will
  be changed to synchronize with the character.
• Down key
• Turn the character facing to the camera
• Move the character forward
• The camera will move backward to keep a distance
  with the character.
• The height to the ground will be changed to
  synchronize with the character.

79
Game Control Case Study Third-personal View
(4/6)

• If the camera is blocked by obstacle to move
  backward, raise the height of the camera but keep
  the eyes on the character.

80
Game Control Case Study Third-personal View
(5/6)

• Right key
• Turn the character facing to the right of the
  camera.
• Take the cameras position as a circle center and
  the distance between the camera and the character
  as the radius.
• Set the circle as the movement orbit.
• Let the character move on the orbit.
• When the character moving, turn the camera to
  right to keep eyes on the character.

81
Game Control Case Study Third-personal View
(6/6)

• When the character hitting the obstacle, let the
  character keep on turning and moving, use the
  same approach in Down key step to raise the
  camera.
• Left key
• As same as Right key step except the left
  direction.
• Reference game examples
• Sprinter cell 3
• PSO
• Prince of Persia(????)
• The Legend of Zelda (?????)
• Demo DCI students work iRobot