(New page: 768px (download original Yampa game engine architecture.svg) This diagram shows a complete ga...)
|(5 intermediate revisions by one user not shown)|
Revision as of 08:24, 30 July 2012
(download original Yampa game engine architecture.svg)
(download original Yampa reactimate dataflow diagram.svg)
(download original Yampa reactimate activity diagram.svg)
These diagrams show a complete game engine architecture using arrowized functional reactive programming. The concept is heavily based on the Space Invaders example of the Yale Haskell Group, using the Yampa reactimate and dpSwitch function.
A game can be thought of as an input-process-output loop (a "stateful process") which produces a new game state every cycle. The main idea is to have a collection of game objects (isolated parallel signal functions), each producing a new observable state (f.e. position, animation frame), which together make up the whole game state. The game state is put out every cycle (rendering, sound etc.), but also fed back to the new processing step. The function 'logic' does observing of the global game state (f.e. collision detection) and routes the input and messages to the game objects correspondignly. The input comes from non-deterministic IO sources (time, gamepad, harddisk etc.).
Keep in mind that there is an additional 'init' step (see reactimate) prior to the first input step and which produces the first game state.
What may appear strange compared to imperative game engines is the fact the whole game state and object list is reproduced every cycle. Additionally, if the game object list changes, the whole core is "switched-into" a new core.