On 4 Mar 2009, at 15:05, Patai Gergely wrote:
Hi everyone,
I feel this should be very simple to do, but I can't find a way to describe the movement of the ball in a breakout game. What do you think, how should it be modelled?
My idea was to define a vector-valued behaviour for the position of the ball, and an event that fires on collisions and carries information about them. I believe such an event is necessary if I am to add sound to the program, for instance, and it feels natural to me anyway. The ball position behaviour is then defined as a stepper in terms of this event. Now the problem is that the event is defined in terms of the ball position among other things. At the moment this leads to a <<loop>>, no matter how I try to approach the problem. This is not too surprising, since I can't really think of a way to define the event other than filtering some kind of clock tick (e.g. framePass) using whenE. Please tell me if there are other, fundamentally different alternatives.
After thinking about this for a while, I feel that Reactive really needs delayed semantics for switching, at least optionally. Otherwise I don't see how we could possibly avoid looping, since the event must be generated assuming that the behaviour continues without switching. Such an alternative reality doesn't fit in the semantic domain of time functions, but an infinitesimal delay looks like a possible solution that resolves the dependency loop. Using delayed constructs always felt clumsy in Yampa too, but loops need special attention...
Another thought I had for a moment was defining some kind of intermediate semantic domain, where behaviours are represented as a _list_ of time functions (with or without intervals provided), which would somehow give access to pre- and post-switching behaviours (like 'head' and 'tail') through some mid-level combinators. But I don't see how that could be made elegant on the application level, and it doesn't seem to achieve anything the delayed switch can't do for us.
What do you think?
I would model this as the position being the integral of the ball's velocity, and switch the velocity, this way, you don't need to do complicated things with trying to grab the position from the last section of the behavior. Re delayed switching, Reactive already has a kind of delayed switching, that happens automatically when necessary. If you attempt to take the value of a Reactive value at the exact moment of a switch, you will receive the value from the previous step. This allows you to compute the new value even in a recursive computation, because sampling no longer gives you the value you are computing. I hope that helps. Thanks Bob