A Functional Reactive Game Engine: The best Library

I’ve spent a lot of time searching for a good functional reactive programming (FRP) library to use. If you’re thinking why don’t I implement FRP myself? Well that would take a long time and far more skill than I have to accomplish. By the way my previous post explains why I’m building a game engine.

Instead of building my own, I looked at some Haskell libraries like Reactive-banana but I found the syntax to be too unfamiliar to me. Next I looked at Flapjax, a web oriented language built on top of Javascript. Seemed promising but I am not familiar with web programming and I’ve only built only a few projects in Javascript/webgl.

I then tried Netflix’s RxJava but it proved to be too large a code base and aimed primarily at networking which isn’t good for a game engine. RxJava is named after C#’s native Rx built by Eric Meijer but wasn’t entirely sure if it was fully built enough for me to use with my game engine, although that said I didn’t look into it too much so I might be wrong on that assumption.

I managed to find another library that seems perfect for my game engine, SodiumFRP. It’s a simple small library built by Stephen Blackheath. It’s a FRP library (no simple RP here!) with some important features some FRP implementations don’t have such as glitch avoidance. The best part of SodiumFRP is that it’s written in seven different programming languages (five finished and two WIP) each with around 900 lines of code. For me this means it’s the easiest to learn from and introduce other people to, which is exactly what the author wants to do.

At first SodiumFRP took some time to learn, actually I’m still learning it but I feel like I’ve got my head around some main concepts. As the author mentions in his talk, SodiumFRP has eight ‘primitives’ and two data types. I’ll talk about the types in this post and the primitives in my next blog post. To learn more about SodiumFRP watch the author’s talk.

The two data types are Event and Behaviour (or in Java, Stream and Cell).

Behaviour/Cell – The way I imagine a Cell is that it’s a container for a value that you want to mutate. As FRP is functional reactive programming it isn’t possible to mutate variables directly as you would do normally in Java or other imperative languages. Instead, you have to use ‘side effects’ to indirectly mutate them. I still don’t fully understand side effects but basically Cells let you do this.

Event/Stream – Streams seem to control the flow of data through your program. In the Java implementation of SodiumFRP, each Stream is defined to handle a certain type of data. So a Stream may only send Integers where another can send MyComplicatedJavaClass where the data they send are instances of these classes.

An example in Java code.

codeExample

The SodiumFRP repository can be found here with more in-depth examples in the tests section of each language’s implementation.

But wait. What are the weaknesses of SodiumFRP? Well there is the lack of parallelism right now which is unfortunate. One of the strengths of functional programming is the ability to make it run in parallel, due to no dependency on state. The author hopes SodiumFRP will be parallel in the future but this does seem to be an unsolved problem of all FRP implementations as stated by Bainomugisha in A Survey on Reactive Programming.

I’ll talk further about SodiumFRP in a later blog post. For now I’ve got a game engine to build.

Leave a comment