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