Difference between revisions of "Yampa/game engine"

From HaskellWiki
Jump to navigation Jump to search
(New page: 768px (download original Yampa game engine architecture.svg) This diagram shows a complete ga...)
 
(Added Category:Games)
 
(6 intermediate revisions by 2 users 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.
 
  +
(download original [[:Image:Yampa reactimate dataflow diagram.svg|Yampa reactimate dataflow diagram.svg]])
   
  +
[[Image:Yampa reactimate activity diagram.png‎|768px]]
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.).
 
  +
(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.
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.
 
  +
 
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 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.
  +
  +
  +
[[Category:Games]]

Latest revision as of 10:21, 16 September 2015

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.