##The Game Engine
This component is responsible for maintaining and advancing the state of the game; it receives Events from the Actors/Game-Objects, processes the game rules and accordingly updates the state of the game, and notifies the players and registered Subscribers/External Systems. The internal components of the Game Engine are implemented in PHP (http://www.php.net), and its database is deployed on the MySQL database manager server.
The Game Engine consists of (a) the Event-driven Machine, (b) the Message Manager, and (c) the Game Manager. The figure below depicts the run-time behavior of the engine. Actors/Game-Objects generate events which are received by the Message Manager that forwards it to the Event-driven Machine. The Event-driven Machine communicates with the Game Manager, which queries the fAARS database for the relevant game rules . Based on the rules, the Event-driven Machine updates the state of the virtual world and the state of the Actors and notifies the Subscribers about any changes and Events that occur during game-play.
The Actors/Game-Objects are notified about game-state changes by the Message Manager using the Long Polling approach, which is a is a communication protocol where the server holds a request for as long as there is no information available for the client. When the request times out, or information is sent to the client, the client automatically sends a new request to the server. This communication modality enables the Game Engine to transfer data to the Actors/Game-Objects on demand without requiring players to explicitly re-quests updates from the Game Engine. The Message Manager has been partly implemented using the Javascript Framework MooTools (http://mootools.net/) and runs on the APE (Ajax Push Engine) Project Server (http://www.ape-project.org/) which allows to subscribe any piece of software interested in interacting with internal and external pieces of the fAARS platform.
##Authoring fAARS Games Rules fAARS does not have an authoring environment. The game rules are defined as Events-Conditions-Actions (ECA) triplets, stored over three database tables. The Events table specifies the event generator, its recipient, and its type. The Condition table specifies the name of a condition, the subject of the condition (generator or recipient), and the value of that condition, which can be the current state of an Actor/Game-Object in the game, the score of an Actor, or the location of an Actor/Game-Object or a group of Actors/Game-Objects. Finally, the Actions table contains the name of the action, the recipient of the action, which may be the generator or the recipient of the Event, and the value of that action, which can be a score number, a location update in the real or the virtual world, or a state to which an Actor/Game-Object or group of Actors/Game-Objects will transition.