[Haskell-cafe] Re: FRP for game programming / artifical life simulation

[Peter Verswyvelen]

Actually, I believe that many Yampa examples do separate the drawing
from the update... The arrow provides the game data that *can* be
rendered. If you provide interpolators for that game data, you can
still achieve the same as is explained in "fix your timesteps" (in my
own FRP experiments I have an update thread and a render thread).

But IMHO "fix your timestep" still misses an important detail, in that
the delta-time that is measured is the duration of the previous frame,
and it assumed that the next frame will take as long as the previous
(who says that "integrate" from the article won't take longer than
dt?). Now say you are updating at 100 FPS = 10ms, but the next frame
actually takes longer, say 20ms. That actually means that you should
have passed 20ms as the delta-time of the this frame, because the real
time is ahead now! This is really noticeable as little jerky frame
hick-up in the motion. In my first game (1987), I added an estimator
to compute how long the delta-time of the next frame would be, which
results in much smoother motion: you notice that the
frame-sampling-rate drops, but you don't see a frame hick-up. I rarely
see this in modern games, most PC and even console games suffer from
frame hick-up (which could be defined as the real-time moving ahead of
the game-time for a brief moment)

Regarding FRP, I like to look at this as a kind of a data flow system
(a network of "signal transformers", or just "nodes"). However, it is
not clear if you want to "pull" or "push" such a network: if side
effects are not present, there should be no difference in the "game
state" if you push or pull it, but one can be far more optimal than
the other. Of example, nodes connected to an analog joystick would
most likely benefit from a pull approach, since the joystick always
moves a little. But nodes connected to a timer that changes once each
second clearly should benefit from a push approach. Although sometimes
a static "change frequency" could help to determine wether to push or
pull, I believe this can only be determined with profiling. So in a
sense, push or pull should  be some kind of attribute...

Okay, a bit off topic :)


On Sun, Apr 25, 2010 at 5:09 PM, Christopher Lane Hinson
<lane at downstairspeople.org> wrote:
>
>> 1) In FRP, there is no global *type*  GameState  that stores the whole
>> game state. Rather, the game state is implicit in the collection of
>> "active" computations. This is also why state updating and drawing is
>> woven together in FRP, which is good syntactically, but hard to
>> disentangle for interpolation.
>
> I disagree somewhat with this.  FRP should be thought of like the IO monad,
> out of which everything that can be lifted, should be, especially the
> GameState.
>
> I like to imagine that the FRP's job is to observe the GameState and reenact
> changes therein.  Some changes take a little while to act out, and the FRP
> element that is doing the action can signal that it isn't ready for the next
> transition.  Or, if no changes occur, the actors can stand around doing idle
> animations.
>
> Friendly,
> --Lane
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>