5 Tips for Reactive Programming

Game programming heavily depends on OOP. Additionally schools teach programming in a OOP way and we’ve much tools designed in OO way.

While everything is fine with the OOP, there’re some other paradigms to be consumed. After all engineering is to have the best outcome with the minimal effort. That’s why an engineer must continuously learn new techniques, paradigms, advances to expand the space of possible choices.

These are the tools in our bags and we should know where they fit in or not.

Reactive Programming is a paradigm which structures the flow of code based on data streams or change of the data. OOP, on the other hand, based on the relations and states of objects. In OOP, flow is controlled based on instructions, in RP flow is controlled with changes in the data.

That’s why reactive programming requires some changes in the mental structure. In OOP, we might think on objects and their functionalities while discussing a project. In RP, we should focus on the changes of data or state.

I’ve been practicing RP for 5 years. I didn’t started to write functional reactive code at the beginning. Was using observables like i was writing OO code. Was subscribing to click observable like i was subscribing to its delegate equivalent.

After some time, by reading articles on RP or codebases and the source code of the framework i’ve been using(UniRx), i’ve started to develop my view on RP.

Below i tried to list 6 items which helps me structuring the code in a Reactive way.

More importantly before the items, we should ask ourselves, what would be the best conditions to use RP?

Simple. Considering the definition of Reactive Programming, the best environment for it would be the place where the objects are highly interactive and in interaction with their environment.

Objects that should react based on the changes of their environment and does not have strict dependencies between them. This also means RP will help us having more async codebase.

So after having this brief causality, here’re my 6 items:

1. Focus on objects states instead of their dependencies or relation

I generally think on the code and its structure while discussing projects. Every definition would be a class, their abilities are the methods. They’ve their own states and they’ve relations between each other.

Imagine a car racing game.

There will be cars in the game so we might have a car class, an engine class, a wheel class, etc. I suppose their dependencies are obvious.

From the RP POV, i’d think what these objects might have as observables.

Like instead of having an accelerate method in car which calls some other methods in engine, I might have an observable in car regarding the engine increased its power.

2. Every state of an object might be a canditate to become an observable

So instead of having an explode method in Car, we might have an observable regarding its condition. Something like ObserveCrashed, ObserveRepaired, etc. These observables might be merged into one by using a generic(class or enum).

3. Every action/interaction of an object with its environment might be an observable

Car colliding with other objects or a character interacts with an object or start a conversation.

4. Objects should not call each others methods in RP

Objects should observe their states/streams etc to trigger something. They should not call each others methods.

5. Only synchronous logic must be implemented with method calls

Method calls mean dependencies between classes and synchronous flow. This is not something that we can get rid of in games :)

There’re several reasons to have OO structure and synchronous flow. In software development we’re trying to reduce the coupling as much as possible but it has its own pros and cons.

Before ending my post, i must state that there’re some helpful OO design principles that have place in RP.

The first would be interface segregation. This is very important to decouple classes/systems which is also the intention in RP. Supporting this principle with dependency inversion with a DI framework, all the references in our code might be interfaces with different observables. This way, none of the classes can change other ones state and we can reduce the side effects.