Yampa/game engine

From HaskellWiki
< Yampa
Revision as of 08:24, 30 July 2012 by Dancor (talk | contribs)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Yampa game engine architecture.png (download original Yampa game engine architecture.svg)

Yampa reactimate dataflow diagram.png (download original Yampa reactimate dataflow diagram.svg)

Yampa reactimate activity diagram.png (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.