Difference between revisions of "Yampa/game engine"

From HaskellWiki
Jump to navigation Jump to search
m
(3 intermediate revisions by one other user not shown)
Line 2: Line 2:
 
(download original [[:Image:Yampa game engine architecture.svg|Yampa game engine architecture.svg]])
 
(download original [[:Image:Yampa game engine architecture.svg|Yampa game engine architecture.svg]])
   
  +
[[Image:Yampa reactimate dataflow diagram.png‎|768px]]
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.
 
  +
(download original [[:Image:Yampa reactimate dataflow diagram.svg|Yampa reactimate dataflow diagram.svg]])
  +
  +
[[Image:Yampa reactimate activity diagram.png‎|768px]]
  +
(download original [[:Image:Yampa reactimate activity diagram.svg|Yampa reactimate activity diagram.svg]])
  +
 
These diagrams show 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]] and [[Yampa/pSwitch|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.).
 
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 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.
 
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.

Revision as of 08:24, 30 July 2012

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.