Reading:
Chapter 4 of Playing Smart by Julian Togelius, “Do Video Games Have Artificial Intelligence?” (Attached)
Additional reference: Chapter 2, section 2.2, “Ad-Hoc Behavior Authoring” (pp. 32-39) of the Yannakakis & Togelius AI & Games textbook (PDF version here)
Background:
A common approach to writing AI for games, especially for non-player characters (NPCs), is to write the desired NPC behavior “manually”, also called ad-hoc behavior authoring. This is “ad-hoc” in comparison to using a systematic AI technique to drive behavior, like game-tree search, machine learning, or planning algorithms. “Manually” does usually mean in a more structured way than just a big pile of code, though. Usually the behavior is specified in a high-level structure, which helps also guide how the behavior interacts with the game engine at a technical level and gets executed.
Two common frameworks for ad-hoc behavior authoring are finite state machines (FSMs) and behavior trees (BTs). Togelius (Ch. 4) goes through an example of an FSM AI for an NPC in detail, and the Yannakakis & Togelius reference (Ch. 2.2) gives a more textbook definition of FSMs and discusses behavior trees as well. Yannakakis & Togelius also discuss utility-based AI, an alternative that is more suited for cases where the reasons for switching between behaviors are more gray-area or fuzzy and easier to encode as floating-point numbers than as graphs or trees.
Assignment:
Choose an existing game, and write how AI for the game would work, using one of these ad-hoc behavior authoring techniques (of your choice). You can either write a bot that plays the game, or AI for a specific NPC within a game, depending on which kind of game you choose.
When thinking about how to structure your AI, a typical approach is to think of high-level logic and low-level logic. High-level logic will be represented by arrangement of nodes and edges within an FSM or BT, and encodes how the AI should make its top-level decisions about what to do, and when to change to doing something else. Low-level logic is represented by specific nodes that aren’t broken down any further, things like “patrol” or “move left”. Of course, patrolling has sub-parts too, but at some point these low-level behaviors are reasonable to leave as something atomic to be implemented as just code.
Your job as AI designer in this case is to:
1) identify which low-level behaviors you’ll need, and then
2) write the high-level logic in either an FSM or BT (or possibly utility-based AI). You only need to turn in the FSM or BT – you can assume that your team will write the code for the low-level behaviors you need. You might want to consider whether the low-level behaviors can truly be written though! Do your low-level behaviors themselves require a lot of “smart” decision-making?
0 comments