AIngine is designed to be a flexible toolkit suitable for a range of applications, with a focus on suitability for inclusion into a game engine.
Each component in AIngine can be used alone or in conjunction with the other components. To allow for ease of interoperation it was decided to use strings and integer based identifiers. For example the decision tree component can determine a goal that is passed to the planning engine that then drives the current state of the finite state machine.
To make AIngine suitable for game applications each component is designed to be lightweight and to avoid the STL when possible. The code is written in standard C++ and checked against multiple compilers to allow for possible compatibility with multiple platforms.
To ease integration into other code the AIngine attempts to define as few types as possible to decrease the intrusion into the host code.
AIngine is provided with Apple Xcode and Microsoft Visual Studio projects that target PPC and Intel OS X and Microsoft Windows.
Each major component is provided with self test code and the project files required to run the tests.
Finite State Machines are one of the older and most used ways to organize an AI's behavior. First Person Shoots, Real Time Strategy games, flight combat simulators and platform games are some of the applications for the Finite State Machine.
The FSM is closely related to the Finite State Automata, a parsing method used extensively in natural language processing. FSM are closely related to computing theory and von Nueman computers.
What exactly is a Finite State Machine? A FSM is an event driven method to organize an AI's behavior. Event driven means that changes in the software do not happen until an event or message is received by the software. Finite mean that only a countable number of states exist.
A state is a label for a set of actions that define a behavior. If an agent in a game started firing their gun at the player, then they are probably in an Attack state. If the character starts running away, they may be in a Flee state.
Events are occurrences in the game such as seeing and enemy or a light switch being used. Events can be generate internally or be received from external sources. An internal event is one that the agent generates. Examples include determining a low ammo count or reaching a goal position. External events are generated outside the realm of the agent. Examples include a player or another agent firing a gun, or a barrel exploding.
Events trigger transitions. Transitions are the switch from on state to another. Transitions are always paired with inputs, in our case the input is an event.
Organizing the behavior of the AI into discrete labels benefits the software in numerous ways. A game designer can easily picture and communicate their desires when in a FSM framework. The software also becomes easier to organize and less error prone. Discrete behaviors are also more obvious to the player. Debugging becomes an easier task. The list goes on.
The most common (and easiest to understand) example for an FSM may be a light bulb. A light build has only two states: On and Off. The common light bulb also only has two input events Switch On and Switch Off.
Every state machine has an initial state. In this example we will assume the initial state is Off. Now our light bulb will stay off until something happens. Lots of actions can happen in a room. People may enter and exit the room, the time of day may change from day to night and someone may even juggle chainsaws, but only one action can actually change the state of our light bulb: the switch being turned on. With this input of the switch being flipped, a transition is triggered and the state of the bulb is changed to the On state. The light bulb will stay on until a new event occurs, the Switch Off event.
The process function is where most of the action will take place. It takes an integer than is equivalent to the current message. An event ID is similar to a state ID. It is a unique value that corresponds to a world event.
An ID3 based decision tree generator and classifier. Unlike a full ID3 based classifier, this implementation does not provide for continuous values.
This is a simple learning mechanism based on Bayesian statistics.
Like a decision tree, it is capable of concept learning and classification. The resulting decision or classification is based on the overall probability of the possible outcomes along with the probability of an outcome given the current input
This is a simple planner based loosely on the STRIPS grammar, with support only for conjunctions of predicates. First order logic is used for resolution of facts, and a depth first search is used to generate actions.
World rules are kept in separate files and can be loaded on demand. Goals and states are given to the planner via strings or arrays of predicates. Once the planner finds a solution, the plan can be executed separately from the planner object.
This is a simple forward-feeding, back-propagating neural network. The network is fully object oriented and each instance is capable of being configured for up to 3 middle layers, each with 256 neurons.
Š Bloom Filters
Š Generic stats package
Š Generic A* search