On 11/27/2012 04:18 PM, Heinrich Apfelmus wrote:
Nathan Hüsken wrote:
Hey,
When writing games in other (imperative) languages, I like to separate the game logic from the rendering. For this I use something similar to the observer pattern.
With rendering I mean anything only related to how objects are drawn to the screen. Animation state for example.
On my journey of exploring game programming with haskell (and FRP), I wonder what a good way of archiving something similar would be.
[..]
So I am wondering: Is there (or can someone think of) a different pattern by which this could be archived? Or asked different: How would you do it?
Personally, I would recommend is a complete change in perspective.
The main idea of FRP is that it is a method to describe the evolution of values in time. What is a game? It's just a picture that evolves in time. The user can exert influence on the evolution by clicking certain buttons on a mechanical device, but in the end, all he sees is a picture that moves.
How to describe picture that moves? Your large picture is probably made from smaller pictures, for instance a small picture in the shape of something we often call a "spaceship". So, you can implement a game by describing the evolution of smaller pictures, and then combine these into the description of a larger picture.
Now, the smaller pictures tend to have "hidden state", which means that their future evolution depends a lot on the past evolution of the other small pictures. In my experience with programming in FRP, it is very useful to describe the individual pictures in terms of tiny state machines and then connect these state machines via appropriate events and behaviors to each other. The essence here is to decouple the individual state machines from each other as much as possible and only then to use the FRP abstractions to connect and combine them into a "large emergent state machine".
That perspective certainly make sense. But couldn't one also describe a game as a set of entities (spaceships) that react to the clicking of buttons? If I take for example the breakout game from here [1]. It outputs an object "scene" of type Picture. But this picture is calculated from the objects "ballPos" and "paddlePos". So first a game state (ballPos, paddlePos) is created and than transformed to something renderable. I believe all examples I have seen for games with FRP follow this pattern, and I would I want to do is seperate the steps of calculating the game state and calculating the renderable from it.
(However, it is important to keep in mind that the fundamental abstraction is not a state machine, but a time evolution that remembers the past. This helps with embracing the new perspective and not accidentally fall back to previous ways of thinking. Whether that ends up with good code is up to you to find out, but if you decide to apply a new perspective, it's best to do it in an extremist way to gain the maximum benefit -- this benefit might certainly turn out to be zero, but you will never find out if you wet your feet only a little bit.)
That certainly makes sense, and it is also very difficult for me to stick to the "FRP perspective". But I do not see that seperating rendering and game logic code goes against the FRP perspective. Best Regards, Nathan [1] https://github.com/bernstein/breakout/blob/master/src/Main.hs