While the previous "official" Java desktop GUI framework, Swing, was based on the Publisher-Observer pattern, JavaFX is instead oriented around Properties.

Although superficially similar (they also allow listeners to be added), the crucial difference is the concept of "binding" properties to one another, essentially synchronizing them automatically. This allows for essentially writing GUI logic like a set of logic rules, e.g. (pseudocode) :

where visible and selected are both of type BooleanProperty. What’s more, you can bind multiple properties into complex statements, which essentially allows you to create dataflows that are updated automatically.

Essentially, the logic starts to look like a declarative stream specification, much more maintainable and convenient than the "Listener Hell" of Swing. It’s a shame JavaFX arrived only when classic desktop apps have already started to go out of fashion.

If you do want to start developing JavaFX applications, however, there’s several libraries that allow to comfortably code using Scala.

The first one, of course, is scalafx, which simply "Scalifies" the API, and adds a convenient DSL for property bindings. The previous example would now look like:

Even more rule-like^[1]!

Another thing is FXML development. FXML works pretty much like e.g. Android’s UI XML files - it allows you to separate general UI specification (the XML) from your business-logic code (a Controller class).

To take advantage of that convenience in Scala, there’s scalafxml. What’s especially nice is that integrates Scala DI approaches (like Macwire), to automatically instantiate the Controller classes^[2].

Over the last year or so, I’ve been evaluating Gremlin/TinkerPop, specifically the Scala implementation, in a variety of projects. Out of curiosity, I went with it as the DB layer for pomisos, using an embedded OrientDB instance as the storage implementation.

Unfortunately^[3], while the API Gremlin API is almost amazingly intuitive (and the Scala implementation doubly so, big kudos to Michael Pollmeier for his work here), I found the "constant" cost of introducing this kind of abstraction seems to be an overkill for projects with only several, unconected, entity types.

Specifically, the biggest problem was creating generalized DAOs, and attempting to use edges as an Ersatz for trivial relations.

To be clear though: in this case, the aforementioned cost of introduction is comparable to an RDBMs. It’s just that, for projects of scale comparable to pomisos, simple object stores are more than sufficient.

From my observations, it appears there’s a persistent myth that experienced developers somehow create perfect code instantly - like some sort of rainbow-excreting unicorns. I find that exceedingly harmful, since it effectively reduces the amount of code that gets out to the public, due to lowered self-esteem of aspiring devs.

By the way, one of the best things in Clean Code is the part where Uncle Bob shows the continuous process of implementing a simple example, starting from a very messy prototype.

This is exactly why I haven’t squashed the ongoing commits. I think it’s a good idea for there to be more transparency in development of similar-scale projects, exactly because of the learning potential in demonstrating the actual coding process.

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:

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.

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:

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