You can also read all about the engineering at AI Factory, where downloads of testbeds and product documentation are available. The web also provides case studies, showing what we can offer to developers and publishers on different platforms, and detailed descriptions of the general engineering and all our game engines.
Update: we are not currently entering into any new licences as we are full time maintaining our own apps.
A core part of AI Factory's business is providing a large resource of mature and easy-to-interface games engines for 3rd party developers to license or purchase, for use with new products. To make this really work well it is necessary to address the following issues:
Our Solution...
1. Interfacing needs to be easy and code integration painless
We have carefully evolved an interface design featuring a clean engine interface that provides the user with, not only elegant access to the engine, but also good game control features. This makes it possible to avoid embedding too much game-specific knowledge in the 3rd party UI. The UI does not need to understand about game sequencing as the game engine looks after this in a very clean manner. Our engines are built around C++, with all game code and data held within a C++ class. There is no troublesome global data.
2. Game interfaces need to be generic, where possible, to make multi-game projects easier
This has been evolved over three years, and now all our engines have the same interface. This makes it possible to drop any one of our engines into a game UI with very little integration work. Code for manipulating the game record is completely generic. The code for calculating a move is also completely generic. The same interface is shared by products as diverse as Chess and Snooker. This is a big step forward for easy game engine integration.
3. Engines should be adaptable for a wide range of platform resources
The engines can be automatically configured by selecting a "best-fit" platform type (eg. PLATFORM_BIGMOBILEPHONE). This uses conditional compilation to switch between floating, fixed or integer arithmetic, where needed. It also auto-fits tables to match the available memory. Of course there are also key design features that can be conveniently shared by all platforms. One of these is stack size. AI Factory have defaulted to arranging that stack usage is minimal, as often this is a restricted resource.
4. There should be a clean separation of source and 3rd party UI - no fiddly invasive tweaking needed
We have worked hard to make this possible. The engines are clean, and allow the processor to be shared with the UI with little fuss (see main article "Writing cpu intensive AI without multi-threading"). This technology is special to us; as of this date, we are unaware that there is any other 3rd party engine source provider for processor-intensive games that can do this.
5. Engines need to be certified as good engines
We have a solid proven track record in international competition. We have Chess, Shogi, Go, Chinese Chess and Bridge game engines that have competed at the highest level. We also have engines out there in successful commercial products, with many more in the pipeline.
6. Engines should allow characterisation
Of course, we dropped in this "unexpected" requirement for a reason: we have a full generic characterisation module which allows our engines to play with characterisation. This lifts them above the average automaton, giving the user a richer game experience. This has received much praise in our Pool and Snooker product, which GameSpot offered this flattering assessment: "...Generally, your artificially intelligent rivals behave in a fashion that harmonizes smartly with their descriptions and play levels. Indeed, the game works hard to deliver distinct playing styles and diversity. In this way Friday Night 3D Pool stays fresh when similar games have already grown stale."
7. Sources must be well supported
This is where we have a great package. We provide not only clear and extensive documentation, but also 2 out-of-the-box testbeds to try out the game engines. Both of these clearly show how the interface is used. The "bare bones" testbed has the minimal test shell to just run the engine. The "full" testbed provides a complete console product, allowing the user to play and save whole games, adjust play level and characterisation, and even add their own test commands.
Behind this there is also a valuable trace support., which allows indented subroutine traces, and console-switchable output, meaning the user can add easy-to-use colour to the standard monochrome stdio-based console output. This allows the programmer to work within the core serial IO functions of C/C++, but still generate complex diagnostic output. You should not need this but it is a boon to have it available should you need to develop some extra shell to test the engine.
Perhaps there is more that you want as a 3rd party developer? Let us know and we will probably provide it!
