Ja, eigentlich hatte ich mir vorgenommen, mindestens einmal im Monat ein Update zu posten – und schon im Jänner hat das nicht geklappt. So viel also zu meinen Neujahrsvorsätzen… 🙃

Warum war es so still?

Seit Dezember gibt es einige Dinge, die mich stark von der Entwicklung abgehalten haben:

  • Mein viertes Kind wurde kurz nach Weihnachten geboren! 🎉 Ich bin aktuell in Babypause und habe entsprechend wenig Zeit zum Entwickeln.
  • Projekte, mit denen ich tatsächlich Geld verdiene. Rechnungen zahlen sich leider nicht von selbst.
  • Die wirtschaftliche Lage und mein Hauptjob. Die aktuelle globale Situation sorgt dafür, dass ich in meinem Beruf, wo ich (leider?) eine wichtige Rolle einnehme stärker gefordert bin als sonst.

Ich hoffe, dass ich ab März wieder mehr Kapazität habe – nach einer beruflichen Indienreise. Bis dahin bin ich leider nur schwer erreichbar und mache langsame Fortschritte. Großes Sorry an Hexx und die Community! 😔

Was hat sich trotzdem getan?

Auch wenn es nur kleine Schritte waren, ist nicht nichts passiert. Das größte Entwicklungshemmnis ist nach wie vor die verwobene Code-Struktur. Um dieses Problem anzugehen, habe ich über die Feiertage einen Proof of Concept (PoC) bzw. Prototyp erstellt.

Modularisierung mit REST-Service

Die Idee: Die bestehende Funktionalität in kleinere, getrennte Domänen unterteilen, sodass Änderungen nicht mehr so weitreichende Auswirkungen haben. Der Prototyp basiert auf einem REST-Service, den ich in der Programmiersprache Zig geschrieben habe. Dieser kann im Moment als Regelkatalog dienen – aktuell lassen sich damit nur Vorteile durchsuchen und verlinken, aber die Basis steht.

Der Ansatz sieht vielversprechend aus. Als nächstes möchte ich im Februar noch ein besonders komplexes System, das auch irgendwie der größte Kern der Regeln ist, als Prototyp umsetzen:

Das System der Voraussetzungen

Momentan gibt es in den JSON-Daten viele “Magic Keywords” und undokumentierte Eigenschaften, die Bedingungen für Vorteile, Sonderfertigkeiten und andere Dinge, die euer Charakter auswählen kann, festlegen. Mein Ziel ist es, herauszufinden, ob sich dieser Bereich modularer und flexibler gestalten lässt – idealerweise so, dass wir künftig Anpassungen einfacher und schneller vornehmen können.

(Einschub: Warum Zig? Weil es C-kompatibel ist, speichersichere Konzepte bietet und ich rust wirklich nicht mag. Wer Lust auf eine philosophische Diskussion darüber hat, kann mich gerne darauf ansprechen!)

Das Kreuz mit der Infrastruktur

Aktuell läuft Compiling, Hosting und Distribution der Binaries über verschiedene Free-Tier-Dienste:

  • Bitbucket – Offizielles Repo von Hexx
  • GitLab – Mein persönliches Coderepo + Linux-Build
  • GitHub – Windows-Build
  • GitLab (extra) – Hosting der Website

Dieses verteilte System sorgt regelmäßig für Probleme:

  • Stockende Daily-Builds – Die Entwicklungs-Builds laufen oft nicht stabil oder gar nicht.
  • Keine macOS-Builds – Weil die Infrastruktur fehlt.
  • Free-Tier-Limits:
    • GitHub erlaubt keine Builds, die länger als 60 Minuten dauern – unser Build braucht aber manchmal 90 Minuten.
    • Nach 60 Tagen werden Daily-Builds automatisch deaktiviert.

Ich suche weiterhin nach besseren Lösungen, die den Build-Prozess schneller und stabiler machen, aber finanziell im Rahmen bleiben. Die Public-Server von GitLab und GitHub sind leider keine Leistungsmonster (klar, sind auch free tiers). Falls jemand Ideen hat: Meldet euch gerne! 😊

Ich hoffe, dass ich bis März wieder aktiver sein kann. Bis dahin vielen Dank für euer Verständnis und eure Geduld!