A Programmer's Blog

Prototype: Cubemaze


Good Morning!

As I don’t know what else to write, I thought I will present some of my older prototypes I wanted to turn into a game eventually, but never found the motivation to do so.

Today I will present you Cubemaze, a prototype I created somewhere in 2014.


The goal is to get out of a maze in a cube drawn with an orthographic camera. You move with your arrow keys, by hitting the spacebar you can rotate the cube and proceed to find your way out of the maze.

Here is the demo. Here is the source.

I think this has quite some potential, but I don’t like to create puzzle games by myself. I would be glad to see this beeing turned in a real game, so feel free to do with it whatever you like 🙂

NPBehave Tutorial 02: Simple Patrolling AI


I created a new tutorial for how to create a patrolling AI with NPBehave.

Tutorial: Automated Functional Testing in Blueprints in UE 4.14


I made a simple tutorial for creating an automated functional test within a blueprint in UE 4.14:

I made this as I couldn’t find any useful documentation for how to set this up. I hope that it helps someone.

NPBehave Tutorial 01: Getting Started


I created a first video for how to getting started with NPBehave (my Behaviour Tree library for Unity).

If there is interest, I will continue this series and dive deeper on what you can do with it and how to use it to create AIs.

The path how I became a game programmer


I haven’t been writing for the past 4 years. The reason is that I had really problems in motivating me to update the blog. I think it was primarly because of my career’s focus. This post is about the past 4 years of my life.

Last time I wrote I was still working for Memonews/Sentric on our big data project, with Hadoop, Ruby and such. Shortly after this, I eventually began to start working for their unbrella company, YMC. There I worked mostly on various mobile projects (Android & iOS, checkout my blogposts here). But focus shifted more and more towards web between 2014 and 2015. I developed mostly pretty small PHP websites with the Symfony Framework. During that time I realized that, while my most experience so far is indeed web development (I write PHP code since 2000), it wasn’t really not what I wanted to concentrate my future on.

That’s only part of the story, the other part is that since 2013 I already was a bit depressed at YMC, as there was just not so much sophisticated work and I felt pretty subchallenged. So I began with a new hobby, a hobby I tried often before, but never kept going. That hobby was game development. That’s how Moyo was born.
After working a couple of months on Moyo, I lowered my job at YMC to a 60-80% position to give my new hobby more time. I was very glad that YMC was so flexible and I am very thankful for that. 60-80% from a Switzerland salary is still enough to have a good life, especially if you live nearby the German border, where you can buy things cheaply. But having so much extra time helped me to develop my game development skills a lot.
I never went up to 100% at YMC again. I released Moyo in May 2014, as a free browser game and a (optional payed) desktop game with better graphics and gamepad support.

It was fun to create Moyo, but it took me over 1 year to build. Most of the time was spend working on the engine. I knew, in order to produce games more quickly, I have to learn one of the popular game engines. That’s why I began trying new engines like Godot and Unity. For the next year or so, I attended many online gamejams, which helped me to learn Unity a lot ( you can check out my projects here ). I think the coolest games I produced at that time were Alice in the Mushroom Hole, the VR title The Captain took your Ducky and probably Dragon Fightress or Ace of Traze.

Programming games is what I like more than any other work, so I started to think about how I could make my living out of it. I often thought it might be cool to quit my main job and just work on the stuff I like most, but I knew it’s gonna be hard. Very hard. Probably too hard. I am not good at Art, Sound Design and especially Marketing. And it were already hard times for indie developers, as there were just so many of them.
I checked out other options. My (now) wife and I wanted to leave Switzerland anyway to get back to Germany, that’s why I started to check out if there are probably some game companies nearby I could try. I found only one in Offenburg, which was around 150km away. It’s Black Forest Games and it’s where I eventually started working for 🙂
I earn a lot less than before, but it’s still enough to have a good living and I finally do what I enjoy most.

In the future I will write about game programming topics. Right now I work mostly with the Unreal and Unity engines. Especially for Unreal there isn’t enough information available in my opinion. Unreal has a lot of features with little documentation and it’s often hard to figure out how the stuff works. This was the main pusher why I decided to start blogging again. I want to write about these things that took me ages to get working and wished I had found more information for upfront.

HBase Split Visualization – Introducing Hannibal!


As Christian wrote a few days ago at the Sentric Blog, we have created a new opensource tool, called Hannibal which is a tool to help monitor and maintain HBase-Clusters that are configured for manual splitting.

I recently created a video tutorial the tool:

Let me hear what you think.

JS-Labs PT.3: Schlankere Controller durch Bindings mit AngularJS!


In meinem letzten Post habe ich gezeigt wie Jasmine und Coffeescript schönen Test-Code schreiben kann. In diesem Post werde ich zeigen wie sich Controller-Code durch Bindings mit AngularJS vereinfachen lässt.

Mein bisheriger Controller

Meine Arbeiten an der jQuery-Version des Wakmarks-Projekts neigen sich dem Ende zu. Ein Anti-Pattern was sich herauskristallisiert ist, dass der Controller bei diversen Events sowohl Model als auch View aktualisieren muss.

Als Beispiel soll hier der ‘click’-Handler auf dem “gelesen”-Button eines Bookmarks dienen. Mit dem Button lässt sich der Zustand eines Bookmarks zwischen “gelesen” und “ungelesen” wechseln:

onBookmarkReadClick : (event) ->
 bookmarkView = $(event.target).parents(".bookmark")
 # update the model ...
 bookmark = Bookmark.find(bookmarkView.data('id'))
 bookmark.read = !bookmark.read
 # ... and the view :(

Das “M” und das “V” im MVC

Schön wäre es, wenn der Controller nur das Model aktualisieren müsste und sich der View dann automatisch aktuallisiert. Im klassischen MVC wird das Problem durch das Observer-Muster gelöst.

(original von Wikipedia)

In meinem Beispiel besteht der View aber aus purem HTML:

<div data-id="1">
   <button class="unread">&nbsp;</button>

Was also tun?


Glücklicherweise gibt es Frameworks die sogenannte Bindings anbieten. Durch Bindings lassen sich Attribute des Models an HTML-Elemente des Views binden und automatisch damit synchronisieren. Letztendlich handelt es sich um vereinfachte Variante um mit dem Observer-Musters zu arbeiten.

Mit AngularJS kann der Code des Controllers damit stark vereinfacht werden:

$scope.onBookmarkReadClick = (bookmark) ->
  bookmark.read = !bookmark.read
$scope.getBookmarkReadClass = (bookmark) ->
  if bookmark.read

Eigentlich wäre es ein Zweizeiler gewesen, aber leider leider unterstützten AngularJS-Bindings keine Kontrollstrukturen, weshalb es die weitere Methode “getBookmarkReadClass” benötigt um den read-Flag in einen CSS-Klassennamen umzuwandeln.

Der View sieht dann so aus:

<div class="bookmark" data-id="{{bookmark.id}}">
   <button class="{{getReadClassName(bookmark)}}">&nbsp;</button>


Mir gefällt diese Variante schon deutlich besser, aber mich stört die Methode “getBookmarkReadClass” in meinem Controller. Es gibt in AngularJS auch die Möglichkeit eigene Filter zu definieren, damit liesse sich der View in etwa so schreiben:

<div data-id="{{bookmark.id}}">
   <button class="bookmark.read | to_bookmark_class">&nbsp;</button>

Die Methode “getBookmarkReadClass” könnte damit entfernt werden. Allerdings habe ich es nicht geschafft einen solchen Filter zu schreiben, da die Dokumenation nicht aktuell ist.

Weitere Frameworks mit Binding-Support

Morgen werde ich mir noch Batman-JS anschauen. Ein weiteres Framework mit Bindings wäre noch Ember-JS, welches aber leider nicht zu CoffeeScript kompatibel ist. Ein Vergleich verschiedener MVC Frameworks gibt es hier.


JS-Labs PT. 2: Javascript sauber testen mit Jasmine und Coffeescript


Im ersten JS-Labs Post habe ich angekündigt, dass ich mir verschiedene Frameworks zur RIA Entwicklung mit Javascript anschauen werde.

Der erste Versuch soll eine reine jQuery-Entwicklung werden – Keine kompletten MVC-Frameworks, nur jQuery mit ein paar Extras. Dazu habe ich mir das Testframework Jasmine und die Scriptsprache CoffeeScript angschaut.

Jasmine ist ein behaviour-driven-development-framework um Tests im Stil von rspec zu schreiben. CoffeeScript ist eine Scriptsprache die direkt in Javascript kompiliert. Die Kombination aus beiden führt zu sehr schönen Tests!

Hier ein vereinfachtes Beispiel der Suite für die Bookmark-Klasse aus dem Wakmarks-Projekt:

describe "Bookmark", ->
  bookmark = null

  beforeEach ->
    bookmark = new Bookmark(1, "A Bookmark", "http://google.de")
  it "should have correct id", ->
  it "should have correct name", ->
    expect(bookmark.name).toEqual("A Bookmark")
  it "should have correct URL", ->

Das Ergebnis ist sehr übersichtlich, wie ich finde.

Die getestete Bookmark-Klasse sieht in CoffeeScript so aus:

class Bookmark
  constructor: (@id, @name, @url) ->

Also wenn das nicht cool ist?

JS-Labs – Wakmarks PT.1


In den nächsten Tagen werde ich verschiedene Frameworks zur RIA-Entwicklung austesten. Primär interessieren mich dabei die folgenden Punkte:

  • MVC
  • Dependency Injection
  • Testbarkeit
  • Performance

Momentan habe ich vor allem einen Blick auf AngularJS und JavascriptMVC.

Ich habe mir zu Testzwecken eine kleine WebApp überlegt um Bookmarks zu verwalten. Natürlich gibt es dafür schon tausende, es geht jar nur ums ausprobieren 😉

Ich werde in nächster Zeit drei Protoypen bauen, jeweils mit UnterschiedlichenTTechnologien:

  1. jQuery plus diverse Plugins für Unit-Tests und Klassen.
  2. AngularJS
  3. JavascriptMVC

Die statische Variante (ohne Funktion) ist bereits hier (ja ich weiss: schön ist was anderes ;D). In den folgenden Parts werde ich dann die einzelnen Prototypen vorstellen.

Rest in peace Flex … oder: was ich in der Javascript-Welt vermisse …


Seit ich HTML und Javascript entwickele, wächst in mir eine Trauer. Ich trauere um Flex und ich trauere um Actionscript. Ich trauere um eine Art der RIA-Entwicklung, wie sie sein sollte. Actionscript und vor allem das Flex-Framework boten so vieles, was ich in der Javascript-Welt einfach nicht wiederfinde.

Im Folgenden werde ich auf einige Dinge eingehen, die mir ganz besonders fehlen. Für Lösungsvorschläge bin ich natürlich sehr dankbar!

Vollständige, flexible und stylebare UI-Komponenten

Hier hatte ich nie mit Problemen gerechnet. Für mich war beim Wechsel ganz klar, das es da draussen UI-Bibliotheken geben müsse, die zumindest annähernd so vollständig und flexibel sind, wie die von Flex … Aber Pustekuchen!

jQueryUI, YUI und wie sie alle heissen, sie alle bieten nur eine unvollständige Anzahl an zusammengewürfelten Komponenten, die wenig mit einemv ollständigen Baukasten für eine RIA zu tun haben. Zudem haben sie meist kein einheitliches Konzept von Erweiterbarkeit oder Wiederverwendbarkeit. Und noch dazu ist das Styling in CSS meist die Hölle. Mein Lieblingsbeispiel ist hier das Menu von YUI-3 : Schwierig zu stylen, so gut wie nicht konfigurierbar, es gibt überhaupt keine Events und beim Initialisieren der Seite zickt und zuckt es das ich Augenkrebs bekomme. Und das ist die Zukunft?

Wer mir ein open-source UI-Framework nennen kann, das so vollständig, so einfach zu verwenden, zu stylen und trotzdem so anpassbar wie Flex ist, dem werd ich persönlich die Füße küssen!


In Flex ist das Entwickeln von Views einfach genial. Mittels Data-Binding werden Daten des Models gebunden und damit ist das View-Verhalten ganz klar vom Controller-Code getrennt. Und wie ist das mit jQuery? Hmm … zugegeben: es ist deutlich besser als mit reinem Javascript, aber jetzt manipuliert man mit jQuery Daten des DOM und wo liegt dieser Code? Im Controller? Gehört er hier wirklich hin? Ein Blick in die Dokumentation von JavascriptMVC bestätigt es mir, ja da kommt er hin!

Durch Data-Binding in Flex ist es möglich Views zu entwickeln, von denen der Controller nichts weiss. Ich denke dies ist der richtige Weg um Wiederverwendbarkeit zu erlangen, da der View jederzeit ausgetauscht werden kann, genauso wie der Controller. Mit gängigen Javascript-Frameworks wird das ganze so streng mit einander verwoben, das hier von Wiederverwendbarkeit keine Rede sein kann.

ECMAScript 4

ECMAScript 4 … das sollte einmal ein Javascript-Standard werden:

Though flexible and formally powerful, the abstraction facilities of ES3 are often inadequate in practice for the development of large software systems. ECMAScript programs are becoming larger and more complex with the adoption of Ajax programming on the web and the extensive use of ECMAScript as an extension and scripting language in applications. The development of large programs can benefit substantially from facilities like static type checking, name hiding, early binding and other optimization hooks, and direct support for object-oriented programming, all of which are absent from ES3.

ECMAScript 4 wurde aber aus irgendwelchen politischen Gründen der Browserhersteller verworfen, allerdings erst nachdem Actionscript 3 diesen Standard bereits adaptiert hat. Mir ist es bis heute nicht klar warum, dieser Standard hätte so vieles ändern können. Während Actionscript sich bereits seit guten 5 Jahren wie eine ausgewachsene Programmiersprache anfühlt, fühlt man sich bei Javascript immer noch wie ein Script-Kiddie, dem offenbar keine Grenzen gesetzt sind.

Bei Javascript ist alles möglich und das liegt hauptsächlich am sog. “Prototyping“, dem Vererbungsmechanismus in Javascript. Das Prototyping ist meiner Meinung nach eine Katastrophe, die Dinge zulässt, die in einer objektorientierten Programmiersprache nicht möglich sein dürfen. Und was haben wir statt dem? Dutzende Frameworks, die versuchen genau diese Probleme lösen, in dem mittels Prototyping eine Abstraktion geschaffen wird, um eine OO-Sprache nachzuahmen. Jedes Framework meint das besser zu können als andere Frameworks. Damit ist jede einzelne Klasse, die ich in einem solchen Framework schreibe, eben an dieses Framework gebunden. Mit anderen Worten: Fast jedes Framework bringt seine eigene Programmiersprache mit sich.


Dazu gibt es nicht viel zu sagen: in Flash brauche ich ein Video oder Musikstück nur in einem Format ausliefern, in der HTML-Welt muss ich Multimedia-Formate für verschiedene Browser in verschiedenen Formaten abliefern. Hier wird so schnell leider keine Javascript Bibliothek Abhilfe schaffen können.


Das Event-Modell von Javascript ist nicht einheitlich. Der eine Browser unterstützt Event-Bubbling, der andere Event-Capturing und mit jQuery erhalte ich auch ein einheitliches Event-Modell, bei dem ich aber folglich weder Bubbling noch Capturing verwenden darf, weil eben nicht jeder Browser unterstützt wird. Korrigiert mich bitte wenn ich hier falsch liege. Auch hier wird leider kein Framework Abhilfe schaffen können.


Wie gut die Aussicht hinsichtlich UI-Komponenten ist, weiss ich nicht. Ich hoffe einfach darauf, dass irgendwann einmal das Thema von kompetenten Entwicklern in die Hand genommen wird und ein reichhaltiges UI-Framework geschaffen wird. Leider ist dies keine einfache Aufgabe, hier sind sicherlich viele Mannjahre an Arbeit erforderlich.

Hinsichtlich Data-Binding ist das AngularJS-Framework sehr vielversprechend. Dieses werde ich mir in nächster Zeit genauer anschauen.

Die Punkte ECMAScript 4, Multimedia-Formate und Event-Modell sind mit einer Javascript Bibliothek oder einem Framework vermutlich nicht so einfach lösbar. Das ist die alleinige Schuld der Browser-Hersteller!

Ich sehne mich nach einer Zukunft ohne Flash, aber in dieser Zukunft muss die HTML-Welt liefern, was in Flash schon seit Jahren Realität ist!