Personal tools

Yampa/game engine

From HaskellWiki

< Yampa(Difference between revisions)
Jump to: navigation, search
Line 4: Line 4:
 
This diagram shows a complete game engine architecture using [[Arrows|arrowized]] functional reactive programming. The concept is heavily based on the Space Invaders example of the Yale Haskell Group, using the Yampa [[Yampa/reactimate|reactimate]] function.
 
This diagram shows a complete game engine architecture using [[Arrows|arrowized]] functional reactive programming. The concept is heavily based on the Space Invaders example of the Yale Haskell Group, using the Yampa [[Yampa/reactimate|reactimate]] 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 and routes the input and messages to the game objects correspondignly. The input comes from non-deterministic IO sources (time, gamepad, harddisk etc.).
+
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 [[Yampa/reactimate|reactimate]]) prior to the first input step and which procudes the first game state.
 
Keep in mind that there is an '''additional 'init' step''' (see [[Yampa/reactimate|reactimate]]) prior to the first input step and which procudes the first game state.

Revision as of 09:22, 2 July 2011

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

This diagram shows 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 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 procudes 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.