Henrik Nilsson wrote:

Hi,

...

Thoughts, people?

Functional Reactive Programming (FRP) tends to, in principle, work pretty well for this kind of application.

So I keep hearing. Unfortunately, discovering what FRP actually *means* is more or less impossible. I can't find a precise definition of the term anywhere. There are a small handful of libraries which claim to "implement it", and their documentation generally isn't especially helpful. Too many trees for me to actually see the wood - i.e., what it's doing and why that's helpful.

The page you referred to didn't seem to consider FRP?

There's a tiny footnote at the end muttering something about "next I need to figure out how FRP fits into the picture", but that's it.

Don't know if FRP would address all of your concerns.

The guy has written a number of posts on the topic, and one of his criticisms is that "FRP is supposed to 'fix' this, but every FRP demo is bouncing balls or asteroids or something equally trivial". I don't know if he wrote that before Frag - isn't that FRP?

But as to collisions, we can observe that this involves two or more entities and is, from the perspective of each entity, something external. Thus I don't think it's unreasonable that code handling collision detection is done "somewhere else", meaning outside the code describing the game entities themselves.

A reasonably argument...

As to how to respond to collisions, that can be a great deal trickier.

Is that not always the way? ;-)

Ryan Ingram wrote:

Oops, misread a bit. I thought this was your series of posts, Andrew! But other than that, my points stand :)

Don't you just *hate* it when you reply, and then later realise you missed some small but important detail? ;-) As for your actual content... I will have to meditate deeply on this to comprehend if/why it's helpful here. (As with all good ideas!)

On Wed, Dec 17, 2008 at 12:13 AM, Ryan Ingram wrote:

...

In the last "episode" you talk about an entity's update being a function like:

...

input_state -> (output_state, [event])

for some suitably defined types of input state, output state, and event.

Connecting together functions with types like this is exactly what Reactive does well. You have an event stream representing the behavior of the user during the course of the game, and you use that to construct other values representing the *behavior* of the game. The key difference is that instead of the game's behavior being a set of functions from input to output, it is functions from one behavior to another, eventually culminating in something like

...

-- "user input", "clock tick"; output a new display list at each clock tick game :: Event UserInput -> Event () -> Reactive [RenderCommand]

In fact, I think your analysis in the first message is somewhat right on; this exercise is somewhat like "writing a novel without using the letter 'e'". The benefits you get from a pure language are not necessarily "lack of effects", but rather, "explicitly mentioning where effects happen".

That said, I'm curious where you are going with it. I'd love to see the game running & take a look at your code!

-- ryan