[Haskell-cafe] Observer pattern in haskell FRP

[Heinrich Apfelmus]

Nathan Hüsken wrote:
> Heinrich Apfelmus wrote:
>>
>> 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. [..]
> 
> 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?

Of course, generally speaking, you can describe it any way you like, FRP 
is just a perspective, not a dictatorial doctrine.

But you probably mean that you want to describe spaceships within the 
FRP perspective, though independent of how they are displayed. That's a 
good point, which I missed. (The guideline of working backwards from the 
very final result has served me very well when developing in FRP style, 
though, hence my insistence on it.)

In the FRP perspective, I would use a slightly different language, 
though. Namely, I would not say that spaceships are "entities that react 
to button clicks", but rather that they are "represented by time-varying 
positions that depend on past button clicks". The change is subtle but 
important: you invert the direction of control. Instead of having a 
button click do something to the spaceship ("push"), you have a 
spaceship whose present position depends on past button clicks ("pull").

The FRP perspective is also more "holistic": you can think of a 
spaceship and other time-varying values as if you knew their values for 
all points in time, as if you were given graphical plots. (I have drawn 
a few pretty pictures in the slides linked to here 
<http://apfelmus.nfshost.com/blog/2012/07/15-frp-tutorial-slides.html>)

> 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.


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.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com