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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe