IMGD 1001 Programming Practices Artificial Intelligence Outline o

IMGD 1001: Programming Practices; Artificial Intelligence

Outline o Common Practices o Artificial Intelligence IMGD 1001 2

Common Practices: Version Control o Database containing files and past history of them o Central location for all code o Allows team to work on related files without overwriting each other’s work o History preserved to track down errors o Branching and merging for platform specific parts IMGD 1001 3 Based on Chapter 3. 1, Introduction to Game Development

Common Practices: Quality (1 of 3) o Code reviews – walk through code by other programmer(s) n Formal or informal n "Two pairs of eyes are better than one. " n Value is that the programmer is aware that others will read o Asserts n Force program to crash to help debugging o Ex: Check condition is true at top of code, say pointer not NULL before continuing n Removed during release IMGD 1001 4 Based on Chapter 3. 1, Introduction to Game Development

Common Practices: Quality (2 of 3) o Unit tests n Low level test of part of game o See if physics computations correct n Tough to wait until very end and see if there's a bug n Often automated, computer runs through combinations n Verify before assembling o Acceptance tests n Verify high-level functionality working correctly o See if levels load correctly o Note, above are programming tests (i. e. code, technical) n Still turned over to testers that track bugs, do gameplay testing IMGD 1001 5 Based on Chapter 3. 1, Introduction to Game Development

Common Practices: Quality (3 of 3) o Bug database n Document & track bugs n Can be from programmers, publishers, customers n Classify by severity and priority n Keeps bugs from falling through cracks n Helps see how game is progressing IMGD 1001 6 Based on Chapter 3. 1, Introduction to Game Development

Common Practices: Pair (or "Peer") Programming o Two programmers at one workstation o One codes and tests, other thinks n Switch after fixed time o Results n Higher-quality code o More bugs found as they happen n More enjoyable, higher morale n Team cohesion n Collective ownership IMGD 1001 7 http: //en. wikipedia. org/wiki/Pair_programming

Outline o Common Practices (done) o Artificial Intelligence (next) IMGD 1001 8

Group Exercise o Consider game where hero is in a pyramid full of mummies. n Mummy wanders around maze n When hero gets close, can “sense” and moves quicker n When mummy sees hero and rushes to attack n If mummy wounded, it flees o What “states” can you see? What are the transitions? Can you suggest appropriate code? IMGD 1001 9

Introduction to AI o Opponents that are challenging, or allies that are helpful n Unit that is credited with acting on own o Human-level intelligence too hard n But under narrow circumstances can do pretty well n Ex: chess and Deep Blue o Artificial Intelligence n Around in CS for some time IMGD 1001 10 Based on Chapter 5. 3, Introduction to Game Development

AI for CS different than AI for Games o Must be smart, but purposely flawed n Lose in a fun, challenging way o No unintended weaknesses n No "golden path" to defeat n Must not look dumb o Must perform in real time (CPU) o Configurable by designers n Not hard coded by programmer o "Amount" and type of AI for game can vary n RTS needs global strategy, FPS needs modeling of individual units at "footstep" level n RTS most demanding: 3 full-time AI programmers n Puzzle, street fighting: 1 part-time AI programmer IMGD 1001 11 Based on Chapter 5. 3, Introduction to Game Development

AI for Games: Mini Outline o Introduction (done) o Agents (next) o Finite State Machines IMGD 1001 12

Game Agents (1 of 3) o Most AI focuses around game agent n Think of agent as NPC, enemy, ally or neutral o Loops through: sense-think-act cycle n Acting is event specific, so talk about sense+think IMGD 1001 13 Based on Chapter 5. 3, Introduction to Game Development

Game Agents (2 of 3) o Sensing n Gather current world state: barriers, opponents, objects n Need limitations: avoid "cheat" of looking at game data n Typically, same constraints as player (vision, hearing range) o Often done simply by distance direction (not computed as per actual vision) n Model communication (data to other agents) and reaction times (can build in delay) IMGD 1001 14

Game Agents (3 of 3) o Thinking n Evaluate information and make a decision n As simple or elaborate as required n Two ways: o Pre-coded expert knowledge, typically handcrafted if-then rules + randomness to make unpredictable o Search algorithm for best (optimal) solution IMGD 1001 15 Based on Chapter 5. 3, Introduction to Game Development

Game Agents: Thinking (1 of 3) o Expert Knowledge n Finite state machines, decision trees, … (FSM most popular, details next) n Appealing since simple, natural, embodies common sense o Ex: if you see enemy weaker than you, attack. If you see enemy stronger, then flee! n Often quite adequate for many AI tasks n Trouble is, often does not scale o Complex situations have many factors o Add more rules o Becomes brittle IMGD 1001 16 Based on Chapter 5. 3, Introduction to Game Development

Game Agents: Thinking (2 of 3) o Search n Look ahead and see what move to do next n Ex: piece on game board, pathfinding (ch 5. 4) o Machine learning n Evaluate past actions, use for future n Techniques show promise, but typically too slow n Need to learn and remember IMGD 1001 17 Based on Chapter 5. 3, Introduction to Game Development

Game Agents: Thinking (3 of 3) o Making agents stupid n Many cases, easy to make agents dominate o Ex: bot always gets head-shot n Dumb down by giving "human" conditions, longer reaction times, make unnecessarily vulnerable o Agent cheating n Ideally, don't have unfair advantage (such as more attributes or more knowledge) n But sometimes might, to make a challenge o Remember, that's the goal, AI lose in challenging way n Best to let player know how agent is doing IMGD 1001 18 Based on Chapter 5. 3, Introduction to Game Development

AI for Games: Mini Outline o Introduction (done) o Agents (done) (next) o Finite State Machines IMGD 1001 19

Finite State Machines (1 of 2) o Abstract model of computation o Formally: n n IMGD 1001 Set of states A starting state An input vocabulary A transition function that maps inputs and the current state to a next state 20 Based on Chapter 5. 3, Introduction to Game Development

Finite State Machines (2 of 2) o Most common game AI software pattern n Natural correspondence between states and n n n behaviors Easy to understand Easy to diagram Easy to program Easy to debug Completely general to any problem o Problems n Explosion of states n Often created with ad-hoc structure IMGD 1001 21 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machines: Approaches o Three approaches n Hardcoded (switch statement) n Scripted n Hybrid Approach IMGD 1001 22 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machine: Hardcoded FSM void Run. Logic( int * state ) { switch( state ) { case 0: //Wander(); if( See. Enemy() ) break; { *state = 1; } case 1: //Attack(); if( Low. On. Health() ) { *state = 2; } if( No. Enemy() ) { *state = 0; } break; case 2: //Flee(); if( No. Enemy() ) break; { *state = 0; } } } IMGD 1001 23 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machine: Problems with Switch FSM 1. Code is ad hoc n Language doesn't enforce structure 2. Transitions result from polling n Inefficient – event-driven sometimes better 3. Can't determine 1 st time state is entered 4. Can't be edited or specified by game designers or players IMGD 1001 24 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machine: Scripted with alternative language Agent. FSM { State( STATE_Wander ) On. Update Execute( Wander ) if( See. Enemy ) Set. State( On. Event( Attacked. By. Enemy ) Set. State( Attack ) State( STATE_Attack ) On. Enter Execute( Prepare. Weapon ) On. Update Execute( Attack ) if( Low. On. Health ) Set. State( if( No. Enemy ) Set. State( On. Exit Execute( Store. Weapon ) State( STATE_Flee ) On. Update Execute( Flee ) if( No. Enemy ) Set. State( } IMGD 1001 STATE_Attack ) STATE_Flee ) STATE_Wander ) 25 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machine: Scripting Advantages 1. Structure enforced 2. Events can be triggered, as well as polling 3. On. Enter and On. Exit concept exists 4. Can be authored by game designers n Easier learning curve than straight C/C++ IMGD 1001 26

Finite-State Machine: Scripting Disadvantages o Not trivial to implement o Several months of development n Custom compiler o With good compile-time error feedback n Bytecode interpreter o With good debugging hooks and support o Scripting languages often disliked by users n Can never approach polish and robustness of commercial compilers/debuggers n Though, some are getting close! IMGD 1001 27 Based on Chapter 5. 3, Introduction to Game Development

Finite-State Machine: Hybrid Approach o Use a class and C-style macros to approximate a scripting language o Allows FSM to be written completely in C++ leveraging existing compiler/debugger o Capture important features/extensions n n n n On. Enter, On. Exit Timers Handle events Consistent regulated structure Ability to log history Modular, flexible, stack-based Multiple FSMs, Concurrent FSMs o Can't be edited by designers or players o Kent says: "Hybrid approaches are evil!" IMGD 1001 28 Based on Chapter 5. 3, Introduction to Game Development