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