Click to request Fireball documentation samples.

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:

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.

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.

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.

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.

The architecture of the interface is generalised to allow support of the following:

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.

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.

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:

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.

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.

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.

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.

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.

In a multi-threaded environment you need checks to avoid accidental code re-entry and invalid data access

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