COEN 196/296 Artificial Intelligence for Gaming
You are free to choose whatever platform you like, but it makes sense to choose from the very beginning a platform that allows simple graphics (of the bouncing ball type). Java is barely OK, C# in the form of silverlight is barely OK, C or C++ with a graphics module like OpenGL is overkill if you do not know already how to use it. I use Python and TkInter, because it has decent graphics and is easy to program.
We extend the Miner Bob example to include more states: Miner Bob needs to go to sleep and needs to eat. He also acquires a wife "Gertie" that spends her time between cleaning house, cooking for Miner Bob, and sleeping. (It is 1849 after all.) When she finishes cooking, she calls Miner Bob to eat, and he obeys. When Miner Bob is tired, he goes home and both of them sleep. State transitions need to be made dependent on the time that the avatars spend in the state.
For the communication, we create a queue (Python has such a data structure) with messages from one avatar to another. Each avatar has a queue with messages to that avatar. We add actions to check for the state of the queue and pop messages.
Here is some Python code to get you started: tState.py , minerBob. I am using Python 3.3.
We implement the functions given in hw2. We then use a graphics interface that generates random points and line segments as needed and calculates the relevant measures. For the first problem, we have a ball rotate around a center.
The following Python code implements simple kinetic movement of two balls in a toroidal world. (The balls do not bounce back at the edge of the field, but appear at the other side.) Using this as a template or as a platform, implement:
main.py, tsGraphics.py, tsMath.py
Using the code developed last week, implement now dynamic movement. You should have flee, simple search, search with arrival, wandering.
Building on the code base developed in the last two weeks, implement dynamic obstacle avoidance, where the obstacle can be a sphere or a line. Test this out by placing the objects in the code in a rectangular box and by putting several internal obstacles.
We now implement path finding using Dijkstra and A*. We start out with a dense tiling (120 by 150). Some of the tiles are filled in representing obstacles in the level. We generate a graph with connections to the neighboring tiles in the eight directions N, NW, W, SW, S, SE, E, NE, unless one of the tiles is filled in. Once we generated the graph, we can use it for path planning. You should use graphics in order to represent the level. Allow the user to specify tiles as the beginning and end of a movement. Then generate and display the path that you find using Dijkstra or A*.
To start out, here is a graphic interface that allows you to add and remove squares from the main.py . Each square is given by a tuple (i,j). The tool allows you to maintain two lists, clicked and unclicked, of the squares. You control the number of squares with the variable boxes.
|1||Introduction, Nature of Game AI, Game AI design, Simple State Machines|
|2||Computational Geometry, Kinetic and Dynamic Movement|
|3||Steering and combining steering|
|4||Interaction with Physics engine, Jumping, Coordinated movement, Motor Control|
|5||Path finding methods|
|6||Decision Making: Decision trees, State Machines, Fuzzy Logic|
|7||Decision Making: , Markov Systems, Goal-oriented behavior, Rule-based systems, blackboard architectures|
|8||Decision Making, Tactics|
|9||Learning, Execution Management|
|10||Presentation and Evaluation of homework assignments|
|11||Final Examinations Week|
|©2013 Thomas Schwarz, S.J., COEN, SCU||SCU||COEN||AI for Games||T. Schwarz||These documents are not intended for dissemination beyond SCU. CAVEAT LECTOR|