Link to Home Page link to index
fireball icon AI Factory's Fireball Interface
Update: we are not currently entering into any new licences as we are full time maintaining our own apps.
AI Factory’s AI Workbench is written in C++ and makes use of the language's object capabilities to allow the creation of game engines using generic AI components to provide an easy route for engine integration. This is primarily an in-house tool for AI Factory Ltd, and was also designed for use by 3rd party developers, although we are not currently licencing out our engines. It consists of:
link to common interface
The standard Fireball interface presented to the 3rd Party engine developer
link to common interface
The test-bed console for testing and developing the engines
link to common interface
The body of generic AI components developed to build new engines
The advantages for the 3rd party UI developer:
link to common interface Common Interface
link to testbed User-Friendly Testbed
link to platform support Multi-Platform Support
link to probability-based static evaluation with inferences Simple AI Architecture
Fireball Engines:
Engines icon Engines - for a list of the engines implementing Fireball Architecture.
Engines icon Testbed Downloads for developers.
A common standard engine interface for all engines
This is designated as the “Fireball” interface and is shared by all of our engines. This has been an evolving standard, but one for which the central components are unchanged. It gives the developer the same simple interface type for all engines. This interface provides:
1. A uniform simple interface
This uses the same common calls for all engines, based on a universal game state class, completely generic game functions (such as PlayMove) and generic control of play strength. Once you have implemented one engine, the next engine will have the same interface structure, so will be much easier.
interface diagram
2. Game Sequencing
Game engines often provide raw "calculate and play move" interfaces, but our engines provide full game sequencing. After any move, the game is left at a known “stage” that the UI can respond to. For example our Bridge engine recognises 18 such stages. This means the UI need not have embedded game sequencing knowledge, but leave it to the engine (through “Play Move”) to automatically advance this to the next new stage.
sequencing diagram
3. Game housekeeping
The interface not only provides basic operations, such as play move and calculate move, but also management of the game history. This allows simple repositioning of the move history and the load and save of the game state. The housekeeping required to ensure the correct board/game position and status, including time, is all handled by the engine.
testbed icon
An off-the-shelf test console for testing engine integration
When integrating an engine into a new UI, it is useful to have a test-bed that allows the programmer to rehearse engine operations. The UI programmer can add their own test commands and compare the operation of the interface within the test bed and the target application. This also provides a console version of printf that supports colour.
platform icon
Support for Single User and Server Implementations
The architecture of the interface is generalised to allow support of the following:
1. Single User platforms
This is the common example, for platforms such as PCs and consoles. This is the simpler case, so the interface provided for this is a subset of the full interface.
2. Server Applications
This might be for a mobile phone game server, which requires the ability of the engine to handle a stream of move requests and simple UI requests (such as tests for “legal move”). The interface explicitly supports this.
The penalty for this extended functionality is that the interface may appear more complex than you would expect. This means that for the single user implementation the functionality provided is more than needed. The server model requires two internal game states, not just one. This gives the single user implementation more possible ways of using the interface. However we recommend following the style used at the end of this document, which uses both game states.
link to common interface
A simple AI architecture that easily integrates on any platform
Integrating an alien engine into a new platform can be hard. One of the key problems is handling an AI engine that consumes much processing (cpu) time with a platform UI that also needs access to the processor at all times. A common approach to solving this is to use a separate thread to run the engine in. This is undesirable for the following reasons:
1. Multi-threaded programs are complex
Having surrendered to the need to multi-threads means that the program no longer functions as a serial application. This can be a minefield for synchronisation bugs, and can often lead to greatly increased development times.
2. The multi-thread is hard to control for processing balance
Running the engine in a separate thread make it very difficult to control the load balance between the UI and engine. Considerable resources can be lost through waiting for event synchronisation. The UI has to “release” the engine thread for slices of time and then allow re-entry into the engine. The engine then no longer becomes a pure engine, but must handle the complexities of code re-entry. This again adds complexity and potential unreliability.
Our Solution:
The AI factory approach taken with the AI Workbench is to provide an engine that very frequently and automatically exits after a short calculation. The calculation is only complete when the engine returns a “TRUE” value. The UI keeps calling the engine until it completes the move calculation.
1. The engine has no UI knowledge
The engine does not change from platform to platform as the engine needs no knowledge whatever of how the target platform works. The engine can always be used without modification and without the engine placing any constraints on how the UI interfaces to it.
2. The UI program can exactly control the engine behaviour
There are no scheduling problems. The UI can choose to instantly stop calling the engine during some time critical stage, or to perform limited engine calls if there is significant UI activity.
3. No need for mutex locks and other methods of access control
In a multi-threaded environment you need checks to avoid accidental code re-entry and invalid data access
4. Complete flexibility
The UI programmer still has the option to run the engine in a separate thread, if they still wish. The engine architecture places no added constraints on the UI programmer, in exchange for the advantages above