[Haskell-cafe] Observer pattern in haskell FRP

[Nathan Hüsken]

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