How to make Behaviors contain other Behaviors in reactive-banana

Question

It appears that everyone is doing a computer game with reactive-banana FRP framework, so I had to try that too. However, I'm stuck with the early steps, trying to describe the game data as reactive-banana Behavior types.

Basically, I'm trying to have a (changing) list of game characters (such as Frodo or Sam). The game characters might be updated on every game tick (modeled as a tick event). The idea is that whenever a game character is changed, a single Event (Character) is triggered, and the character update is finally sent over the network. The benefit of this compared to the Asteroids.hs example should be that the whole game state (the whole list of game characters) doesn't need to be sent over the network, since there will be a number of events having a single game character instead of a single event with a game character list.

For a single game character this works fine! I created the Behavior (Character) with mapaccum, so that the character update signal gets sent when the character is updated. The problem I can't solve is how to make this work with a Behavior list of game characters.

I'm trying to model the game character list as a Behavior, since characters might come and go during the game. Do I need to use dynamic event switching here? Or if I don't use Behavior with the individual game characters (and only use Behavior with the game character list), is there a way to conditionally trigger update events when I'm going through the character list? Or am I not understanding something here?

Answer 1

To manage a dynamic collection of behaviors, you have to use dynamic event switching. See the BarTab.hs example for a demonstration.

However, dynamic event switching can be a bit unwieldy and it is often possible to avoid it. Two common situations are:

1. The collection of behaviors is known statically. The TwoCounters.hs demonstrates that one can simply use the applicative functor combinators to calculate a value depending on either behavior.
2. The dynamic collection can be modeled as a behavior of a collection (Behavior [a]) as opposed to a collection of behaviors ([Behavior a]). The Asteroids.hs example demonstrates how to use this. This is a stylistic trade-off: the individual entries of the collection cannot be formulated with FRP anymore, but the collection becomes easier to manage.