Reactive Streams in Scala meet a Game Engine - Part 2

Mikołaj Koziarkiewicz

Series' Table of Contents

Unfortunately, just after the first installment of this series, I’ve involved myself in another side-project, which will probably be released soon. But hey, that’s no excuse to at least make a small update in the meantime, to keep the ball rolling, right?

Scope

Desiderata

As mentioned in the first post, the next step should be defining our scope. This basically boils down to making our exploration of the streaming paradigm as efficient as practicable, specifically identifying problems intrinsic to game programming.

One of those is efficient resource allocation. Games need to spawn and remove potentially large numbers of object quickly, and without taxing the memory of the device. For JVM-made games, Android device limits would probably serve as the most prominent example in recent years[1]. Game engines like libgdx mitigate this problem by employing pools of mutable data structures (which reduces the number of created objects, and hence GC time), among other tricks.

Another issue is smooth rendering of the game’s updates. Enjoyment drops sharply if the game becomes visibly choppy.

A related problem is responsiveness to player input. Smooth FPS gives little consolation if the player remains constantly frustrated while unable to react in time to the unfolding events.

To sum up…​

We would like to have a game that:

  • requires relatively quick player reaction (so e.g. no turn-based games),

  • has a lot of events happening at any given moment,

  • and employs a large number of entities to do so.

Recall also one of our initial assumptions: mistakes will be made prominent (and prominently made), including potentially avoidable ones, in order to showcase them and their solutions.

First sketches

Obviously, we want some kind of an arcade game, somewhat close in style to a shoot’em up, even drifting into bullet hell territory[2].

For starters, we want some sort of controllable character, multiple, respawning enemies, and some sort of score meter (which will help us gauge the rate of updates).

Here’s a veeery rudimentary sketch of how the game will look like at the beginning:

starter sketch
Figure 1. No, I’m not a graphic artist, why do you ask?

Of course, we’ll keep adding stuff as we go along, but we already have more than enough work to do.

Up Next

In the following episode we’ll finally see some code. We’re going to define the boilerplate skeleton of our application, and create an Akka Streams source that allows to react to game state updates.

1. Alongside Minecraft’s chunk management.
2. Apologies for linking to TV Tropes.

Reactive Streams in Scala meet a Game Engine - Part 1

Mikołaj Koziarkiewicz

Series' Table of Contents

Intro

It’s always interesting to see a new (or newly fashionable) technique being applied to new and unexpected areas, and see whether it makes sense (and what makes or breaks it).

Such is the case with Scala (reactive) streaming and computer game creation. A while ago, I stumbled upon a talk by Aleksandar Prokopec, which planted the seed of inspiration for this blog series. And what set that seed on a path of growth was another presentation, this time by Michał Płachta [1].

So, why another thing on this?

Well, of course it wouldn’t be fun if the blog series was just a same-scenario rehash. Here’s what’s going to be different - while the aforementioned talks were more-or-less "from-scratch" affairs, creating a game engine and/or a streaming platform along the way - I will be going the "lazy" route, and attempting to join together a ready-made game engine with a ready-made streaming framework.

The primary advantage of this kind-of-unique[2] setup is that the focus almost by definition falls on the paradigm mismatch problem, and thus it’s easy to see what one must solve to make the whole shebang work.

And there’s a related blessing in disguise - because we’re operating between two rigid boundaries of stable libraries, any domain-related idiosyncrasies will be easily identifiable, and have a reduced chance of rising up later on to bite is in the hind parts.

Now, let’s talk framework choices.

Decisions, decisions

Game Engine

It may come as a surprise to some of the readers, but JVM game programming is not exactly a barren field, despite the infamous "Java is slow" stereotype. Probably the greatest influence in recent years has been the rise of Android, hence why a high proportion of JVM game engines provide support for both "mobile" and "desktop" targets[3].

In any case, two engines seem to be the strongest contenders at the moment: libGDX and jMonkeyEngine. Both have been present on the scene for several years, and offer comprehensive game development feature sets[4].

The choice, however, falls on libGDX, for two reasons: it has explicit support for 2D rendering, and it’s the one I’m actually familiar with.

I’m going to expand on libGDX in upcoming installments. Right now, let’s roll over to the other side for the…​

Streaming Implementation

Apart from the obvious choice of Akka Streams, I was also monitoring the progress of Swave.

I recommend following its development closely. It is, in implementation and design, significantly less complex than Akka Streams. Swave can therefore serve as a convenient stepping stone in beating the learning curve, when adapting to the streaming paradigm.

However, Swave is still shaping up, its documentation is somewhat lacking[5], and I have a sneaking suspicion that some unique features of its "competitor" (like blueprinting) might come in handy, so we’re sticking with Akka Streams.

OK, so the tech base is decided now. All that remains is one tiny detail - just what is the end goal and how to achieve it?

Some ground rules

Let’s start with the goal itself, since it’s pretty obvious - a natural way to verify whether something works (or doesn’t), is through a practical proof-of-concept. Therefore, during this series, I’m going to work towards a fully-playable simple game, that uses streaming as its core operational model.

This leads nicely to the preferred form of the series, i.e. a development blog - meaning:

  • installments will be posted (hopefully) regularly,

  • with a soft word-length cutoff,

  • mistakes will be made prominent (and prominently made), including potentially avoidable ones, in order to showcase them and their solutions[6].

Finally, to spice things up a bit, I’m going to deliberately forgo gathering "technical" inspiration from the aforementioned related talks and projects (like the additional abstractions introduced by Dr. Prokopec), in order to see where the problem domain lends toward convergent solution creation.

Up Next

In the next installment, we’re going to cover defining the scope of the PoC game. Stay tuned!

1. Source code here.
2. There are at least two similar projects. One went in the direction of providing an Rx* translation layer. It seems to be inactive for about two years now. Another, implemented in Kotlin, seems to be under active development. Both use the Rx* family of libraries.
3. Be aware 'though that since Android supports "native applications", a lot of Android games are written in C/C++ instead.
4. To answer a - perhaps - lingering question: Minecraft, the poster child of JVM games, uses neither. It has a proprietary engine, with several native bridges for OpenGL support etc.
5. Do see the presentations 'though for a good feel of what it offers.
6. Also making for a nice excuse in case of eggregious blunders.