Sorry for the late reply, I somehow missed this eMail ... On 11/29/2012 06:28 PM, Heinrich Apfelmus wrote:
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.
In that light, the separation seems straightforward to me. Given the time-varying values that represent game objects,
bSpaceShipPosition :: Behavior Position bAsteroidPositions :: Behavior [Position] bTime :: Behavior Time
you can transform and combine them into a graphic, for instance like this
bSpaceShipPicture :: Behavior Graphic bSpaceShipPicture = blinkenLights <$> bTime <*> bSpaceShipPosition
bAsteroidPictures = map drawAsteroid <$> bAsteroidPositions
bPicture = overlay <$> ((:) <$> bSpaceShipPicture <*> bAsteroidPictures)
In other words, you just combine old time-varying values into new ones, much like you would combine combine graphical plots. Also note that you can add animation a posteriori; it doesn't have to be part of the values representing a space ship.
Yes, but these examples are extremely simple. The animation has no internal "state". What if every Asteroid also has a animation state (which I would want to add a posteriori) and can be destroyed. Than the connection between the asteroids "game logic" value, and "rendering" value needs some kind of bookkeeping to be maintained.
Of course, one important question is whether to represent asteroid positions as a time-varying collection Behavior [Position] or as a collection of time-varying values [Behavior Position] . The latter form tends to require dynamic event switching, while the former form tends towards a monolithic GameState value, which would forgo many of the advantages of FRP.
I don't have enough practical experience to give a useful recommendation here, but at the moment, I tend towards breaking it up as much as possible, but trying to avoid dynamic event switching. My rule of thumb is to model similar objects (asteroids) as a time-varying collection, while modeling distinct objects (player space ship) as individual behaviors.
Thank you for your input! Regards, Nathan