When does a script get run? KevinSeghetti -- currently the object scripts run one each active/running object once per frame. There are a few other non-object scripts, like the meta-script which decided what level to load next, which run when needed.

Typically event-based systems are based on a "slot/filler" model, where each "slot" can be connected with a script. E.g. OnCollide can be connected with a function to do something when a collision occurs. The engine determines when events occur, look in the slot for the event, and call the user-function (if any) in that slot.

The idea, then, is:

If EVENT then call FUNCTION_FOR_EVENT

Blender takes this further by introducing the idea of a controller.

In Blender the paradigm is:

If SENSOR and CONTROLLER then ACTUATOR

The sensor is like an event. Furthermore, many sensors can be combined - not possible with an event based system. E.g. a sensor may fire if an object is within a certain radius (a "near sensor"), if an object lies along a particular ray (a "ray sensor"), or every frame (an "always" sensor). Combining sensors means for instance you can check for collisions along two rays (e.g. an object has to be visible to "both eyes" of an enemy for action to be taken).

One or more sensors are connected to controllers. If all inputs to a controller are true, then the controller makes a decision based on game state what should happen and returns either TRUE or FALSE. If FALSE, nothing happens. If TRUE, then the controller fires all actuators connected with it. The controller is where "logic" or "AI" occurs, and it is also here that a python script can be executed to make complex decisions.

Actuators execute some action and are, as mentioned before, connected to the output of controllers. Many actuators are provided which are a handy "toolset" of "ways to manipulate the world". E.g. apply physics forces, or play an audio track from CDROM, or set a property of a different object, or restart a level.

KevinSeghetti -- WorldFoundry does it a bit differently, we use Mailboxes for our countrollers. The object whose behavior is to change (they appear to call it the actuator) can read a mailbox and change its behavior (like movement) based on its contents. See the CookBook for several examples of this. We were originally going to continue with this system until just about anything could be done with it, even had objects which did boolean math on mailboxes (and, or, xor, not) so that complex logic could be built up out of objects, but eventually we decided that it was easier for everyone if the complex logic was handled by a scripting language instead (it is easier to cut and paste a script than a dozen interrelated objects). The above blender syntax IS a scripting language, it just has a very strict grammar. For an open source game engine I think it is wiser to use an off the shelf scripting language (although I haven't really found one I like for this purpose yet).

Need to write more here.....