From BlenderWiki

BGE GameObject GameLoop control

The current BGE GameLoop is rather constrained to a Logic Brick focused design. I propose that this is modified with support for generic "GameLoop" systems that control how the engine is run.

KX_KetsjiEngine

This may involve some additional modifications to the Blender source where time-dependent operations occur.

1. Make a small map of the logic brick system; distinguish between interfaces and implementations (where a feature is implemented as part of the logic brick system, and where the logic brick uses an existing, generic feature). By the looks of things, this is mostly the latter.
2. Look at the KX_KetsjiEngine implementation, and separate it into its constituents. At the moment, it has one large NextFrame method that handles the entire update procedure, with some setup logic in between calls to each component of the game.
3. Separated out this logic, so that each component could be controlled by the main loop where necessary. In doing so, one would expect a game-loop interface that controls / talks to the engine, rather than having a native “logic brick oriented” loop, or a customised Python controlled loop.
4. Create an interface that allows a choice for the main loop control. In order to support native C++ Logic bricks (and/or future systems in C++) and Python scripts, there should be a method of declaring a “Logic system” in the same manner. One would maintain an internal Logic manager. During conversion the engine looks up a list / struct in the blend file that stores any Python GameLoop modules, then calls KX_KetsjiEngine::RegisterLogicLoop() for each which accepts the interface and an identifier. The C++ classes call this directly.
5. Python would use a generic interface, eg KX_PythonGameLoop which would interface with the Python gameloop. Each interface would have something like an on_register, on_unregister (to manager) on_enable and on_disable methods that can be used to enable / disable loops. In terms of running multiple “loops”, as a gameloop should control the engine, this would not be native behaviour. They should not be aware of each other, nor should they need to interact with one another. This shouldn’t be a large problem, because all loops either support or are defined in python, so complex logic is always possible.
6. In order to support data structures like the Nodal logic, the scene conversion should be able to run callbacks (a bpy module to register callbacks should be added).

Phased transition

1. Create the framework for the logic manager.
2. Create a KX_GameLoop class that can be subclassed in Python / C++.
3. Create a LogicBrick KX_GameLoop class.
4. Make a record of any potential issues in replacing the hard coded update with a generic implementation.
5. Implement the register method for the KX_KetsjiEngine.
6. Register the LogicBrick KX_GameLoop class by default (for standard behaviour)(active=True)
7. Todo: Consider moving constants into the KX_GameLoop class for logic bricks
8. Todo: General refactoring to move methods away from the assumption of logic bricks
9. Todo: Making use of a check to ensure logic-brick methods have a logic brick environment (use a try catch, raising an error)

UI changes

1. Implement a text field to specify the path to the Python class (if running custom gameloop)
2. Create a new panel in the Properties area; Gameloop which houses the existing (Internal) gameloops and enables the user to register external "Python" gameloops, much like the way one can register a custom particle system. By default the drop-down selector is populated with options for HIVE or the BGE.
3. Internal gameloops can be associated with a name; and given configurable properties. It may be that a special attribute can be named on the KX_PythonLogicLoop that exposes configurable parameters to the user. The majority of configuration should however occur from the existing system panel.
4. From this UI it should be possible to define a custom converter to register Blender data into the gameloop.
5. Potentially move the logic editor into the node editor. It would be easy to enforce the SCA concepts, and that way all interfaces are unified.