Noxzed

Timeloop (Post-Mortem)

Cyd Noxzed — Mon, 22 Apr 2024 00:00:00 +0200

Die Idee kommt im Kern von dem Video »Clock Blockers«, in dem nach jeder Runde ein neuer Spieler zur Partie hinzugefügt wird und dieser in das bereits passierte Spielgeschehen eingreifen, und dieses somit verändern und erweitern kann.

Das Lernziel war es, ein rundenbasiertes Spiel zu erstellen, welches die Bewegungen der einzelnen Figuren speichert und diese wieder abspielen kann.

Geplant hatte ich hier mit mehreren unterschiedlichen Spielfiguren, welche auch unterschiedliche Fähigkeiten haben. Die eine wäre im Nahkampf besser, während die andere bereits aus der Ferne eine Attacke ausführt oder sogar verschiedene Zauber ausführen kann. Fokusiert wurde jedoch erstmal der Nahkampf.

Am ersten Prototypen arbeitete ich im September 2023 in Godot. Da auch noch mit den Tiles von Pixel Dungeon. Durch die Komplexität des Abspeicherns der Aktionen und mit den genaueren Steuerungsmöglichkeiten (nur Steuerkreuz oder auch Aktionsbuttons, etc), war hier nach kurzer Zeit die Luft raus und ich habe mich anderen Themen zugewandt.

Nachdem ich auf die Game Engine Pyxel gestoßen bin, wollte ich mit dieser (und meinen Python-Kenntnissen), der Idee nochmal eine Chance geben und einen Prototypen dafür erstellen.

Die Pixel-Dungon Tiles konnte ich in der Engine nicht direkt verwenden, weswegen ich auf die Pyxel-Bordmittel zurückgegriffen habe. Die Grafik sollte möglichst minimalistisch sein. Aus dem Grund wurde die Pyxel Standard-Farbpalette verwendet und mal schnell ein paar Tiles und verschiedene Figuren dazu erstellt. Die Tilegröße war hierbei 8x8.

Als ich dann mit Pyxel einen erneuten Anlauf durchgeführt hab, ging die Umsetzung relativ leicht von der Hand. Auch die Implementation des Aktionsspeichers, wurde schneller und auch leichter umgesetzt. Vermutlich hat es geholften, dass die mit Python durchgeführt wurde und nicht mit GDScript und ich somit die Datenstruktur leichter aus meinen Gedanken im Code abbilden konnte.

Die kleine Tilesize von 8x8 hatte zu Folge, dass ich viel weniger Zeit mit dem Erstellen von Tiles verbracht habe. Die Grafik wurde dann auf das wesentliche heruntergebrochen und der Fokus konnte auf die Funktionen des Spiel liegen und weniger auf dessen Aussehen.

Nachdem der Aktionsspeicher fertig Implementatiert war und ich auch ein paar Runden spielen konnte, hab ich leider schnell festgestellt, dass die Idee so als Spiel nicht taugt. Der Spieler, der zuerst am Zug ist, hat einen extrem starken Vorteil, den der zweite Spieler nicht ausgleichen kann. Zudem kommt hinzu, dass es leicht möglich ist, mit der ersten Spielfigur länger am Spawn zu verweilen, um in der nächsten Runde von der zweiten Spielfigur in der Bewegung unterbrochen zu werden. Dadurch ist es dem Spieler auch wieder möglich die Figur frei zu bewegen, da diese nicht die gespeicherten Bewegungen aus dem Aktionsspeicher verwendet.

Vielleicht hätte ich pro Runde ein Zeitlimit einfügen oder die Spawns der Figuren weiter voneinander entfernen müssen. Das schien mir aber alles den Aufwand nicht wert, wenn die Grundidee einfach nicht wie geplant/gewünscht funktioniert.

Hesperos (Post-Mortem)

Cyd Noxzed — Fri, 15 Dec 2023 00:00:00 +0100

Nach den vielen kleineren Projekten 2023, mit einem Umfang von einem Monat, wollte ich das Nächste doppelt so lange durchführen.

Die Idee war eine Mischung aus Tower-Defence und Ressourcenabbau. Man verteidigt seine Basis vor Wellen von Angreifern, entweder direkt mit der Spielfigur oder mit gebauten Geschützen. Letzteres muss man sich jedoch erst durch das Abbauen von Blöcken in der Umgebung der Basis verdienen.

Vom Aussehen wollte ich die Grafiken wieder komplett selbst erstellen. Um das auch stemmen zu können, war der Plan einiges über Pixelart zu lernen. Einen Einstieg habe ich über Lospec einige gute Einsteigerartikel zum Thema gefunden und dort auch einige Farbpaletten gesucht. Um den Schwierigkeitsgrad zu senken, habe ich mich für zwei Farben entschieden und eine Tilegröße von 8x8 - also ziemlich niedrige Anforderungen.

Der Fortschritt im August hat aber meinen Erwartungen nicht ganz entsprochen. Einige merkwürdige Bugs und auch ein gedankliches Hin und Her bezüglich der Steuerung, haben dazu geführt, das ich das Projekt vernachlässigt habe.

Bereits in der zweiten Augusthälfte wollte ich an dem Spiel nicht mehr weiterarbeiten. Ungeklärte Fragen, über den weiteren Entwicklungsverlauf, sammelten sich an.¹

Wobei ich immernoch glaube, dass das Spielkonzept interessant ist, habe ich mich entschlossen das Spiel erstmal beiseite zu legen.

Darunter: können die Türme nur in 4 Richtungen schießen oder sich um 360° drehen? ↩︎

Gamejam Juli

Cyd Noxzed — Sun, 20 Aug 2023 00:00:00 +0200

Im letzten Jam hab ich mich für ein paar Stunden wieder mit prozeduraler Generierung ablenken lassen. Deshalb wollte ich im nächsten Jam einen kleinen Dungeon Crawler erstellen, welcher die Levels anhand eines Seeds generiert.

Somit war das Mindestziel wie folgt:

Spielfigur bewegt man mit der Tastatur
Blickrichtung via Maus
Finden und Sammeln von Schlüsseln
verschlossene Türen versperren den Weg in die nächste Ebene
Gegner sehen den Spieler und machen Schaden bei Berührung

Grafisch wollte ich zunächst alles selbst machen. Habe dann doch für die Figuren auf vorhandene Tilesets zurückgegriffen. Die Dungeon-Tiles hab ich dann doch selbst gemacht und auch einige Gegenstände (im Grunde nur die Schlüssel).

Für die Generierung der Dungeon habe ich anstelle eines bisher mir bekannten Algorithmus ein anderes Konzept verfolgt und die Räume anhand von Prefabs (aus einer farbcodierten PNG) zufällig nebeneinander angeordnet und die Gegenstände / Monster abhängig von der aktuellen Ebene (bzw. des Spielfortschritts) darin verteilt.

Da alle Räume den gleichen Grundbauplan haben und potentiell in alle 4 Richtungen mit anderen Räumen verbunden werden können, musste ich hier keine Unterscheidungen treffen. Um ein bisschen mehr Variation zu den 8 Räumen zu bekommen, gibt es von allen jeweils noch (dynamisch) gespiegelte Versionen.

Aus Zeitgründen musste ich einige Features weglassen. Ein Monstertyp ist eigentlich ein bisschen wenig. Auch kann man eine anderen Gegenstände außer Schlüssel finden und verschlossene Türen gehen auch nur in den nächsten Level. Tränke mit verschiedenen Wirkungen wären auch ganz nett gewesen, genau wie Boss Gegner.

Was ich jedoch noch implementiert habe war ein Field-Of-View, welches vom Spieler kreisförmig ausgeht und die Sicht durch Wände/Türen behindert wird. Leider hat dieses Feature zur Folge, dass das Spiel im Browser nur noch einen schwarzen Bildschirm anzeigt. Warum das der Fall ist, habe ich auf die Schnelle nicht herausfinden können.

Zwischenzeitlich hab ich das Konzept verfolgt, dass man die Blickrichtung nicht mit der Maus steuert, sondern die Welt sich um den Spieler dreht und dieser relativ gesehen immer nach oben/vorne blickt. Der nächste Schritt wäre vermutlich dann MODE7 gewesen. Dann hätte ich aber auch alle Sprites auf eine top-down-Ansicht ändern müssen. Das hab ich dann lieber gestrichen. Sowas wäre vermutlich für ein Rennspiel interessant.

In den letzten Entwicklungsstunden habe ich dann noch den Highscore implementiert. Dieser speichert lediglich die Zahl der tiefsten bisher erreichten Ebene ab.

Gamejam Rocket

Cyd Noxzed — Sat, 27 May 2023 00:00:00 +0200

Nachdem ich einfache Achtwege-Bewegung im letzten Jam umgesetzt hatte, wollte ich mich nun ein bisschen tiefer mit der Physik-Engine auseinander setzen, die Godot zu bieten hat. Zum Einstieg habe ich mir hier lediglich Schwerkraft vorgenommen.

Hierzu wollte ich über die Osterfeiertage einen kleinen Prototypen erstellen, welcher lediglich Schwerkraft enthält. Da ein Sidescroller trotzdem einige Elemente hat, die mehr Aufwand erfordern, dachte ich an einen simplen Klon eines Spiel, welches ich in den 2000ern mal gespielt hatte: Crazy Gravity.

Um das Spiel grafisch Ansprechender zu machen, wollte ich die Sprites diesmal selbst erstellen. Um darin nicht zu viel Zeit zu verschwenden entschied ich mich das ganze einen einfachen Schwarz-Weiß-Look zu geben. Damit ich den Schwarzton ggf. ein bisschen variabel entschärfen kann und der Kontrast nicht zu stark ist, habe ich in den Sprites lediglich weiße und transparente Pixel verwendet.

Ziel des Spiels war es, innerhalb von kürzester Zeit, mit einem der Gravitation beeinflussten Rakete, Kisten von anderen Startrampen zu holen und diese zum Startpunkt der Karte zu bringen. Da die Rakete mit jedem Schub Treibstoff verliert, muss man zusätzlich ab und an zu einer Tankstelle fliegen. Wenn alle Kisten abgeholt sind, ist die Karte zu Ende und man bekommt die benötigte Zeit angezeigt.

Damit ich hier schnell Levels bauen kann, musste ich mich auch gleich mal mit dem Autotiling von Godot beschäftigen. Für den Anfang sollte hier ein einfaches 2x2-Tiling reichen. Auch hier habe ich einfache Linien verwendet, um die Grenzen des Levels darzustellen. Mit dem Tilemap-Editor in Godot konnte ich dann ganz schnell ein paar Maps erstellen.

Für den ganzen Prototypen habe ich nur ein paar Tage über Ostern benötigt. Hier könnte man tatsächlich von einem Gamejam sprechen, da ich hier auch pro Tag mehrere Stunden darin invenstieren konnte.

Generell bin ich mit dem Ergebnis ganz zu frieden. Die Steuerung funktioniert gut und das Spielprinzip ist kurzweilig. Jedenfalls ein schönes Beispiel was man aus einem guten Spielkonzept auf die Schnelle rausholen kann.

Gamejam März

Cyd Noxzed — Mon, 24 Apr 2023 00:00:00 +0200

Ich hatte mal wieder Lust mich mit Spieleentwicklung auseinander zusetzen. Um dieses mal einen anderen Weg einzuschlagen, hab ich mich entschlossen mich in eine fertige Engine einzuarbeiten. Meine Wahl fiel dann auf Godot. Primär aus den Gründen, dass es Freie Software ist und ich Builds für unterschiedliche Plattformen erstellen kann.

Parallel dazu habe ich mich mit den Konzept von Gamejams auseinandergesetzt. Deren Ziel ist es innerhalb kurzer Zeit ein Spiel fertig zu stellen. Was für mich bedeutet eine Deadline zu haben und entsprechend Features wegstreichen zu müssen um rechtzeitig fertig zu werden.

Die meisten Gamejams laufen so über ein Wocheende und in dieser Zeit kann/sollte man vollständig am Jam arbeiten. Zeitlich ist das für mich jedoch aktuell keine Option, ich kann vermutlich maximal 30 Minuten täglich (wenn überhaupt) dafür aufwenden. Bei den Gamejams, welche über einen Monat oder länger gehen, fühle ich mich wahrscheinlich auch schnell abgehängt. Nach langlaufenden speziellen Gamejams für erwachsene Berufstätige habe ich jedoch nicht gesucht, so ein Kommitment wollte ich dann doch nicht eingehen.

Also habe ich mir das Ziel gesetzt im Laufe des gesamten März ein Spiel zu schreiben, in welcher ich mir die Grundzüge der Godot-Engine aneignen kann. Darunter auch Bewegung der Spielfigur und Szenenwechsel.

Entschieden habe ich mich dann für ein einfaches Rätselspiel, bei dem man in jedem Raum jeweils ein Rätsel lösen muss, um in den nächsten Raum fortschreiten zu können. Es soll darin Elemente wie Schiebe- oder Schalterrätsel geben und keine handlungsfähigen Gegner.

Also habe ich eine Reihe verschiedener Räume gebaut, in welchen man ein oder mehrere Rätsel lösen muss. Mal ist es Kisten auf eine Druckplatte verschieben, mal Knöpfe in einer bestimmten Reihenfolge drücken. Viele der Level sind jedoch eher Klone von Sokoban-Rätsel, welches sich durch das freiere Bewegen der Spielfigur teilweise anders lösen lassen.

Weil die Grafik ziemlich schlicht gehalten ist (größtenteils besteht alles nur aus einfachen geometrischen Figuren), hab ich besonders darauf geachtet, dass die einzelnen Levels und deren Elemente leicht zu lesen und zu verstehen sind.

Das ganze Spiel lässt sich in ca. 5-10 Minuten durchspielen.

5 Tage vor dem Ende des Jams habe ich das Spiel zum ersten Mal jemanden testen lassen. Die Kritik war erschütternd. Viele Elemente des Spiels waren nervig und unschön gelöst. Das hab ich während der Entwicklung schon geahnt, aber nicht weiter Berücksichtigt. Wenn man ein Level 100x spielt, verliert man den Blick des Anfängers sehr leicht aus den Augen.

Ich habe versucht in den letzten Tage die gröbsten Schnitzer zu entfernen, um das Spiel schöner spielbar zu machen.

Rückblickend muss ich sagen, dass die Idee eines Zeitlimits bzw. einer Deadline enorm dazu beigetragen hat, zumindest etwas fertig zu machen. Zu schnell verliert man sich bei sowas in Kleinigkeiten, welche einem zwar in der Entwicklung spaß bereiten, jedoch keinen wirklichen Mehrwert schaffen. Der Fokus sollte immer bei der Erstellung der Kernelemente liegen. Polieren und Erweitern kann man im Anschluss immer noch.

In Godot selbst, kam ich durch die ganze Dokumentation Online, sowie den Massen an Tutorials gut rein. Auch habe ich in der Zeit die Vorteile der Architektur von Godot kennen gelernt. Wenn man von einem ECS kommt, wirkt der Ansatz mit den Szenen bei Godot erstmal befremdlich. Sobald man jedoch sich stärker damit auseinander gesetzt hat fällt es einem leicht die Vorteile davon für sich zu nutzen. Vermutlich bin ich hier jedoch erst am Anfang.

Dezentrale Flatfile Datenbank (Teil 2)

Cyd Noxzed — Fri, 24 Feb 2023 00:00:00 +0100

Im ersten Post zur Dezentrale Flatfile Datenbank habe ich bereits mal den Gedanken geäußert eine dezentrale flatfile Datenbank zu benötigen.

Seit dem veröffentlichen des Posts sind einige Gedanken hierzu noch dazugekommen, beziehungsweise habe ich einige Implementationsversuche unternommen, um ein eigenes System auf die Beine zu stellen.

Einsatzbereich war primär erneut der Feedreader und eine Verwaltung der einzelnen Feeds geräteübergreifend zu ermöglichen.

Grundidee

Während eine SQLite-Datei eine komplette Datenbank enthält und man diese auch als normale Datei synchronisieren lassen kann, würde es jedoch spätestens dann zu Problemen führen, wenn man die Datei vor einer Synchronisierung von zwei Rechnern aus modifiziert. Der Sync würde dann mit einem Mergekonflikt fehlschlagen.

Bei anderen Flatfile-Datenbank-Systemen (wie CSV, recutils oder maildir) würden bei umfangreicheren Änderungen auch solche Probleme auftreten. Zumindest könnte man bei solchen Plaintext-Formaten leichter mit diff oder ähnlichen Tools arbeiten. Manuell müsste man jedoch trotzdem tätig werden, was es zu vermeiden gilt.

Ziel soll es sein, eine Plaintext Datenbank zu haben, welche das Mergen vollständig übernimmt, ohne dass man dabei einen zusätzlichen Software-Stack aufsetzen muss. Die Synchronisierung selbst soll mit jeder beliebigen Dateisynchronisierung (Syncthing, rsync, Nextcloud, git, etc) durchgeführt werden können.

Mergekonflikte

Deshalb sind Mergekonflikte auf ein Minimum zu reduzieren. Da Mergekonflikte generell bei Änderungen einzelner Dateien auftreten, war der Gedanke, alle Informationen in einzelne Dateien zu speichern. Der Primärschüssel ist dann ein Pfad auf einen Ordner und der Ordner enthält dann für jede singulare Information eine einzelne Datei. Diese enthalten dann die jeweiligen Werte. Wenn die Datei nicht existiert, dann wird für deren Inhalt ein Standardwert (Leerstring oder NULL) angenommen.

Bei einem Mergekonflikt kann dann zb die neuste Datei den globalen Stand bestimmen, je nachdem wie das Synchronisierungstool so etwas automatisch auflösen kann.

Warum separate Dateien für jede Information?

Es gibt einige Formate, mit denen man ein Entity vollständig in einer Datei erfassen kann. Hierzu zählen JSON, Markdown-Frontmatter oder auch INI. Diese müssten jedoch auch gut durchsuch-/filterbar sein, was abhängig von der Formatierung nicht unbedingt gegeben ist, bzw. man die Dateien vorher noch parsen müsste.

Bei unterschiedlichen Formatierungen wäre ein lösen von Mergekonflikten im Rahmen des Syncs auch nicht mehr möglich.

Aufbau der Datenbank Struktur

Primärschlüssel: Als Primärschlüssel dient lediglich der Pfad der Entität innerhalb des "Datenbank"-Ordners. Feld: Der Feldname entspricht der Datei innerhalb des Entity-Ordners. Tabellen: Gibt es in dem Sinne nicht, siehe "Unterscheidung von Entitätstypen"

Unterscheiden von Entitätstypen

Bei einer relationellen Datenbank gibt es unterschiedliche Tabellen, welche unterschiedliche Daten beinhaltne können. In einer Flatfile Datenbank kann man dies abhängig vom Ordnerpfad, von den einzelnen Dateien einer Entität oder von einer Typen-Datei innerhalb der Entity abhängig machen.

Suchen, Filtern und Sortieren

Abhängig davon, ob man nur nach Entitäten suchen möchte oder nach einem bestimmten Inhalt, würden sich die klassichen Unixtools wie find oder grep anbienten. Glob wäre hier sicherlich auche eine hilfreiche Implementation, um alle Felder mit einem bestimmten Namen in einem Ordner zu finden.

Umfangreichere Filter könnten auch mit pipe-Verknüpfungen in grep realisiert werden.

Sortieren ist mit sort auch mit den Unixtools möglich und vermutlich sinnvoll. Auch vergleichen von Daten könnte innerhalb einer Subshell (mit gt, eq, lt) stattfinden.

Nachteile

Die Nachteile dieser Datenhaltung wären zunächst, dass ein größerer Platz auf der Festplatte eingenommen wird, da jedes einzelne Datenbankfeld den ganzen Informationsoverhead einer Datei beinhaltet, sowie die fehlende Indizierung der Daten, welches standardmäßig eine Datenbank mit übernimmt.

Auch das durchsuchen der "Datenbank", mit grep, ohne Indizierung würde mehr CPU-Zeit beanspruchen.

Implementation

Kommend sollte ich mich vermutlich mal an eine entsprechende Implementation versuchen, um zu testen ob das alles so funktioniert wie ich mir das aktuell denke und ob eine dezentrale Datenhaltung in so einer Datenbank überhaupt praktikabel ist.

Für Vorschläge, Links und Anregungen zu dem Thema kann man mir gerne eine kurze Mail schreiben.

Release: Webferea 2.4.0

Cyd Noxzed — Fri, 18 Mar 2022 00:00:00 +0100

Über den Winter hat sich in der Entwicklung von Webferea einiges getan.

Der HTML-Code der Feed-Einträge wird vor der Ausgabe nun viel stärker gefiltert und nur bestimmte Tags und Attribute im HTML-Code verbleiben. Das hilft dabei, dass Feed-Einträge die Struktur der Webferea-Seite nicht negativ beeinflussen kann. Die Filter für interne Links, Iframes und Bilder wurden überarbeitet und verlinken nun korrekt, auch wird man nun nach dem Login auf die letzte besuchte Seite weitergeleitet.

Die umfangreichste Änderung des neuen Releases ist jedoch das neue Theme. Im Vorfeld wurde die Templates und die zugehörigen statischen Dateien in einen neuen Ordner verschoben, damit das Anlegen von neuen Templates leichter durchführbar ist.

Neben dem alten Standardtheme gibt es jetzt ein w3css-Theme, welches auf dem CSS w3css aufbaut. W3css ist ein kleines und hübsches Style-Framework, welches ohne Javascript auskommt und ganz viele Beispiele mitliefert. Angepasst habe ich das erneut auf die mobile Nutzung.

Die statischen Dateien sind Größer als im Default-Theme, aber ein Aufruf der Liste oder der Einträge ist kleiner.

Für die Icons wird bei dem Theme font-awesome 4.7 verwendet und keine UTF-8 Icons, dadurch sehen diese auch browserübergreifend gleich aus.

Der Lesestatus eines Eintrags wird jetzt im localStorage des Browsers gespeichert und entsprechend am Eintrag mit angezeigt (als Fortschrittsbalken oben beim Eintrag oder als Tag in der Liste). Wenn man erneut den Eintrag öffnet springt man entsprechend wieder dort hin.

Zusätzlich kann das Theme noch folgendes:

Wechsel zwischen Dark- und Lightmode
Wechsel der Font zwischen Serif-Schrift und San-Serif-Schrift
Gleichzeitiges Bearbeiten von Einträgen in der Liste

Sonst sind wieder einige Fixes eingeflossen, welche mir beim täglichen Benutzen aufgefallen sind.

Zu finden ist das Projekt aktuell auf Github.

Hier noch ein paar Screenshots:

Dezentrale Flatfile Datenbank

Cyd Noxzed — Sat, 30 Oct 2021 00:00:00 +0200

Aktuell ist die Aktualisierung von Webferea abhängig von meinem Hauptcomputer, da ich meine Webferea-Instanz mit diesem synchronisiere. Eine Synchronisation zwischen mehr als einem Master würde nicht funktionieren, da die Rücksynchronisation nur den Lesestatus der einzelnen Posts überträgt, nicht jedoch die einzelnen Feeds an sich oder deren Position in der Feed-Ordnerstruktur.

Wie im initialen Webferea Post angedeutet, fehlen mir bei Liferea¹ einige Funktionen.

Am Einfachsten wäre es vermutlich die Datenbank in Webferea auf dem Server direkt zu verwalten (inkl. Aktualisieren und so) und meine Rechner greifen jeweils nur darauf zu. Als Client würde dann vermutlich pur der Browser zum Einsatz kommen und keine ressourcenschonendere native Alternative, was mir nicht so ganz zusagt. Zudem könnte ich dann gleich auf bereits etablierte Programme wie Tiny Tiny RSS oder Miniflux zugreifen ohne die Arbeit einer Eigenentwicklung.

Die Dezentralität spielt für mich hier aber eine entscheidente Rolle. Ich möchte unabhängig von einer Serververbindung meine Feeds direkt auf den Clients verwalten, sodass ich diese auch Offline lesen kann.

Um nicht direkt bei allen Sachen bei Null anfangen zu müssen, habe ich mich erstmal mit der Synchronisation auseinander gesetzt. Da ich meine Rechner und Smartphone bereits via Syncthing verbunden habe und diese so auch bereits Dateien austauschen, war meine Überlegung einfach darauf zurückzugreifen und die Synchronisation von einem darauf spezialisierten Programm übernehmen zu lassen.

Bei einer simplen Flatfile-Datenbank würden die einzelnen Werte jedoch CSV-ähnlich abgespeichert werden. Wenn hier dann Änderungen an den zwei Rechnern erfolgt, ohne zwischendrin zu synchronisieren, müsste ich hier manuell die Dateien dann mergen. Das wäre nicht zielführend.

Die nächste Überlegung war, die einzelnen Posts aus den Feeds jeweils in separate Dateien zu speichern, diese würden dann ja ohne Probleme synchronisiert werden. Damit es keine Kollisionen gibt benenne ich die Dateien jeweils anhand einer zufällig generierten UUID. Falls Posts zweimal gefetched und eingetragen werden, dann lasse ich diese jeweils automatisch anhand deren Titel abgleichen. Wenn ein Post bereits gelesen ist und der andere noch nicht, wird der bereits gelesene behalten und der andere gelöscht. Das ist aber echt umständlich zu implementierende Logik, die eigentlich von der Synchronisation erledigt werden sollte und nicht vom Feedreader selbst.

Eigentlich brauche ich doch nur eine dezentrale Flatfile-Datenbank. Kann doch nicht der erste sein, der sowas implementieren möchte.

Flatfile-Datenbanken gibts ja so einige, nennen will ich hier jedenfalls noch Recfiles aus den GNU Recutils. Aber auch die sehen keine Synchronisation vor.

Zwischenzeitlich hab ich mich noch mit dokumentenorientierten Datenbanken beschäftigt. Gerade CouchDB-Instanzen können sich wohl sehr gut untereinander synchronisieren. Leider ist hier wieder ein neuer Stack für die Synchronisierung zuständig und ich kann diese nicht einfach wie normale Dateien auch synchen.

Als Entwickler ist mir hierbei auch ein paar mal git in den Sinn gekommen. Synchronisieren und Mergen von Flatfiles ist ja quasi dessen Kernkompetenz. Aber da man hier auch wieder abstand von den eigentlichen Synctools nimmt, hab ich mich damit nicht näher beschäftigt. Immerhin ist git ja für Sourcecode und nicht für Datenbanken gedacht. Zumal ich hier auch bei einem Merge manuell tätig werden müsste.

Neulich bin ich dann jedoch auf einen interessanten Artikel gestoßen: Git as a NoSql database von Kenneth Truyers, welcher den Gedanken vertieft und einige Beispiele für eine Implementation mitgibt.

Momentan ist die Variante mit git (bare-repo oder Checkout) aktuell mein Favorit. Hier müsste ich dann aber Logiken implementieren, welche bei einem Mergekonflikt die Datenbank wieder gerade ziehen (nicht gerade ein einfacher Task).

Wobei ich wirklich interessiert daran wäre, ob es bereits Implementationen einer dezentralen Flatfile Datenbank gibt. Wäre für Links hierzu dankbar.

Liferea ist mein aktuell genutzer Feedreader, welcher auch als Basis für die Webferea-Synchronisation dient. ↩︎

Geminify the mail

Cyd Noxzed — Thu, 15 Jul 2021 00:00:00 +0200

This is a crosspost of my post of the same title on bbj.envs.net.¹

A few months ago in tilde.chat/#gemini I was part in an interesting conversation about tranfering the concepts and goals of gemini to email.

Despite the fact that email is a greatly decentralized standard in the online communication, it has a few historical flaws that are mostly impossible to patch. For example the lack of encryption per default.

"Email" is basicaly a push protocol and not a fetch one like gemini. The goal would be to design a protocol that can be used to push fully encrypted data (or messages) from one user (or system) to another.

If you already know a project or idea in that direction, feel free to contact me via email and send me a link.

For a push orientated protocol the receiver of the message should be online most of the time and adressable, therefore the client-server-architecture should be used. Even thou it could be the case that a server is not always online (eg. if its solar powered).

A basic path of a message could be the following:

Client A → Outbox A → Server A → Server B → Inbox B → Client B

There are different challenges to tackle, and most of them are just rethinking existing protocols:

Encryption and the Public Key Infrastructure
Envelope- and Message-Format
Mailbox-Format
Address / Identifier
S2S-Protocol
C2S-Protocol

Encryption and the Public Key Infrastructure

I'm not an expert on encryption and only know the basics of asymmetric encryption. For this very reason I don't know how to design such a system that is capable of fetching and validating the public key(s) of a specific user, to be able to send him an encrypted message. There are a lot of pitfalls I don't know.

Envelope- and Message-Format

The envelope itself contains 3 parts:

Receiver address (eg. [email protected])
the message (encrypted)
the signature of the sender server of the above data

The server can not see the content of the message or who is the sender address.

The message can only be decrypted by the client and contains header and a body. The body can contain multiple segments like a message or attachments.

Theirfore the server can not handle spam protection or redirect- or sorting rules. This can only be done by the client that can encrypt the messages.

Besides normal attachments that contains the file directly, it should be possible to reference/link to files that are too big to attach. Next to the link of the file there should be a decryption key and an expiration date provided, that way the files can be downloaded to a later time. (This could be used as a tracking pixel, but I'm not sure how to work around the filesize of a message with big attachments).

Mailbox-Format

Right now MAILDIR or MBOX let have the server full control over the messages and can see a lot of the content/metadata of the mails. This should not be possible.

Due to the full encryption, the server can not spam check the mails or filter them by any criteria. This needs to be done by the clients.

The user mailbox could have 3 directories:

inbox: all messages that were received by the server for this user (the user removes the message from the inbox after moving it into the encrypted data directory)
outbox: messages that the server should send to the receiver (the server deletes the message after it was send)
data: all files that are shared by the users clients (messages, encryption keys, etc) but fully encrypted

Address / Identifier

The address must contain at least two parts: the user identifier and the server identifier. eg:

[email protected] (normal address)
[email protected] (disposable address for alice)
groupconversation/[email protected] (address the user alice in a group conversation or mailinglist)

S2S-Protocol

This would possibly be the hardest part of all, because a server needs to be sure to receive messages only from trusted sources to prevent spam.

The sender server connects to the receiver server and identifies itself, and the receiver needs to validates this identity. Maybe over TXT records in the DNS or the servers have their own key-pair for signing and encrypting.

C2S-Protocol

The protocol provides access to the mailbox of the user. Perhaps SSH/SFTP could be enough to handle multiple clients from the same user? Messages itself could be written offline and sync to the servers outbox possibly days later, there should not occure errors on syncing the mailbox between server and the clients.

Those a just a few thoughts on this topic. If you have a different approach or other ideas I'm pleased to hear them. Most of the ideas above are probably naive, but I think they could head into the right direction.

If there is a better platform (or mailinglist) for this thought experiment, please let me know.

BBJ is a bulletin board which can be accessed with the tilde ssh account. ↩︎

Einfach zum Abschluss bringen

Cyd Noxzed — Mon, 24 May 2021 00:00:00 +0200

Nachdem ich jetzt jahrelang immer on und off daran rumwerkel, wurde es mal an der Zeit das Projekt zu einem Ende zu bringen. Von den Initial vorgenommenen Zielen habe ich in dem Zug einige ausgeklammert, da ich das MVP¹ in möglichst einer Woche fertigstellen wollte.

Die letzte große Änderung an dem Spiel war im Herbst letzten Jahres, als ich den Kern nochmal komplett auf ECS umgestellt habe. Das war (geschätzt) vermutlich bereits das fünfte Rewrite des Kernes seitdem ich mit dieser Spieleidee gestartet bin. Um die Sache diesmal ein bisschen zu beschleunigen habe ich mich dazu entschlossen erstmal alles Grafische auszuklammern und das dann irgendwann später nachzuholen. Sowohl die Karte, als auch die Akteure auf der Karte, bestanden aus simplen geometrischen Figuren² und das alles sah auch dementsprechend abschreckend aus.

Angefangen hatte ich damals™ mit einer Größe von 64x64 Pixel von einzelnen Kacheln und Sprites. Da war ich auch noch in der strengen Top-Down Ansicht.

Weil ich aber hierfür kaum Grafiken gefunden hab und die Kacheln für die Wand wegen der Perspektive ziemlich unschön aussehen, bin ich vor ein paar Jahren mal zur einer weniger strengen Top-Down Sicht gewechselt. Bei der Gelegenheit habe ich auch die Pixelgröße von 64 auf 16 verkleinert, um einen Pixel-Art-Look zu bekommen.

Da hab ich aber auch viel Zeit damit verschwendet schöne Grafiken zu finden, deshalb bin ich da dann bei der Umstellung auf ECS auch dazu übergegangen eine möglichst simple Darstellung zu nutzen, damit ich mich auf die Funktionalitäten fokusieren kann.

> Video mit simpler Grafik

Die Grafik wurde bei allen Kommentatoren jedoch als "bescheiden" bezeichnet, was ich fairerweise nachvollziehen kann. Aus dem Grund habe ich mich nochmal hingesetzt, um zumindest die Grafiken auf einfachste Art und Weise darstellen zu können. Also so Eye-Candy wie ich sie bereits bei anderen Kernen hatte (Drehen der Spielfigur abhängig vom Fadenkreuz oder Animation beim Laufen) habe ich hier jedoch dann weggelassen.

Für die Grafiken greife ich hier pur auf das 16x16 Dungeon Tileset von 0x72 zu.

Ich hab auch überlegt die Grafiken von Shattered Pixel Dungeon zu übernehmen, da hier die einzelnen Wände schöner dargestellt sind. Jedoch sind diese auch schwerer zu zeichnen, da es ja einen Unterschied macht, ob man bei einer generierten Dungeon alle Wände gleich anmalt oder Grafik verändern muss, abhängig von Faktoren wie Ausrichtung, Ecken oder Türen.

Zudem sind bei den 0x72 Grafiken auch passende Monster dabei. Zwar nicht animiert, aber das ist aktuell auch kein Todo.

Um das Hauptprojekt mal abzuschließen, habe ich mich vor ein paar Wochen mal hingesetzt und alle (dringend) notwendigen Features, sowie die damit zusammenhängende Todos priorisiert. Den Rest habe ich für das MVP gestrichen.

Weggefallen sind dann so Sachen wie Animationen oder auch der Netzwerkmodus. Eigentlich hätte ich auch noch gerne weitere Items integriert, wie Schlüssel für Türen (oder auch allgemein Türen) oder Schriftrollen mit weiteren Zaubern abseits des Feuerballs. Auch ein paar weitere Gegnerarten wären wünschenswert. Aber primäres Ziel war es dann doch, alles abzuschließen.

Übrig geblieben ist dann primär die zufällig generierte Dungeon und die darin enthaltenen Entities (eine Gegnerart, Healthpotions, Ein-/Ausgang und Feuerbälle als Waffe). Zusätzlich noch das voranschreiten in tiefere Ebenen der Dungeon. Beim Beenden der 6. Ebene hat man das Spiel gewonnen, wenn einen die Gegner vorher töten können verloren.

Das Endergebnis sieht schon ganz nett aus, ist aber bei weitem nicht der große Wurf, den ich noch zu Beginn erträumt hatte.

> Gameplay Trailer (1.6 MiB / 2.40min / webm)

Eigentlich müsste ich das Spiel auch noch paketieren und zum Download anbieten. Mit pyinstaller könnte ich jedoch nur Binaries für Linux anbieten und zum Thema Crosscompiling hab ich mir noch keine Gedanken gemacht. Den Source einfach so reinzustellen, bringt vermutlich niemandem etwas, da es bessere Codebeispiele im Netz zu finden gibt.

Im Großen und Ganzen habe ich viel bei der Umsetzung des Spiels gelernt. Vorallem in Bezug auf die Einhaltung des Scopes. Ein Spiel, welches man im Kern einige Mal neu schreibt, wird nie fertig. Lieber immer komplett neue Ideen frisch starten und die alten mit der bisherigen Architektur zu Ende bekommen.

Jetzt hab ich jedenfalls wieder Lust irgendwas komplett neues anzufangen. Vielleicht mal einen Sidescroller oder einen Raycaster, mal schauen wie ich da die Zeit dafür finde. Vielleicht suche ich mir auch ein Projekt abseits der Spieleentwicklung.

wp:Minimum_Viable_Product ↩︎
Größtenteils große und kleine Quadrate und Kreise. ↩︎

The idea of Gemmail

Cyd Noxzed — Mon, 26 Apr 2021 00:00:00 +0200

Durch den Unmut mit E-Mail-Anbietern, entstande gestern in #gemini¹ ein interessantes Gespräch über eine Alternative zum bestehenden E-Mail-System, welches die Prinzipien von Gemini umsetzt.

Grundgedanke war es, die bestehenden E-Mail-Protokolle (SMTP, IMAP, MAIL) mit neuen Protokollen für s2s, c2s und E-Mail-Envelope zu ersetzen, um bei der Gelegenheit die ganzen Legacysachen aus den Protokollen zu entfernen und diese von Anfang an Leichtgewichtig und vollständig verschlüsselt zu designen. Idealerweise auch möglichst SPAM-sicher (sonst wäre es ja kaum ein Fortschritt).

Hier ein paar der Gedanken unzusammenhängend aufgeschrieben:

UTF8
TLS
TOFU: Server tauschen durch ersten Kontakt Security Daten aus
gemtext als E-Mail Body nutzen
Text und Anhang der Mail sind vollständig asynchron verschlüsselt
Envelope wird durch den Senderserver signiert
»Passer«-Server, welche Mails weiterleiten (der Quellserver muss diesen das jedoch mit einem Schlüssel erlauben, den der Zielserver prüfen kann)
Ein Ziel- oder Quellserver kann manchmal nicht erreichbar sein (zB. wenn es ein solarbetriebener Homeserver ist)
Das s2s-Protokoll sollte weiterhin ein Pull-Protokoll bleiben
Attachments werden (optional) nicht mit in der Mail versendet, sondern lediglich mit einem Link (gemini, http, ipfs) referenziert, sowie einem Key zur Entschlüsselung und ein Ablaufdatum. Damit müsste keine riesige Mail versendet werden, welche ggf. vom Empfängerserver abgelehnt werden müsste.
Dem Serverbetreiber sollten so wenig Informationen wie möglich zugänglich gemacht werden

Mir kommen bei der ganzen Thematik gerade einige Parallelen zu Messengern in den Sinn. Vermutlich gäbe es hier durchaus einige Schnittpunkte. Das Axolotl-Protokoll zum Verschlüsseln der Nachrichten und die Möglichkeit mehrere Personen gleichzeitig anzuschreiben (Gruppen) wären natürlich schon ein guter Mehrwert.

Die Verwendung von eigenen Domains sollte genauso möglich sein, wie das Migrieren der eigenen Daten auf einen anderen Server. Mit IMAP ist sowas bei Mails ja relativ einfach möglich: Mails alle runterladen, Mails beim anderen Anbieter alle wieder hochladen.

Möglicher Aufbau eines »Gemmail-Postfaches« könnte zB so aussehen:

INBOX: Server legt neue Mails in diesem Ordner an
OUTBOX: Inhalte werden vom Server versendet und dann gelöscht
DATA: enthält eine (mehrere?) verschlüsselte .tar Archive, welche die verschlüsselten Mails enthalten. Diese Archive werden von den Clients heruntergeladen und verschlüsselt auch wieder hochgeladen.

Ziel wäre es, dass der Server so wenig Metadaten wie möglich bekommt.

Ich bin mal gespannt, ob sich aus der Idee in den nächsten Monaten etwas ergeben sollte.

irc.tilde.chat unter https://tilde.chat/ ↩︎

Release: Webferea 2.2.0

Cyd Noxzed — Sun, 18 Apr 2021 00:00:00 +0200

In den letzten Wochen sind mir beim Nutzen von Webferea einige Sachen aufgefallen, die ich noch korrigieren bzw. implementieren musste.

Beim Rendern von Feedeinträgen, welche iframes enthielten (gerade YT) wurde die Ausgabe des Posts dadurch unterbrochen. Das Verhalten konnte ich browserübergreifend beobachten. Um das zu korrigeren, wird nun vor der Ausgabe des Posts, der iframe-Tag entsprechend herausgefiltert und lediglich ein Link auf das src-Attribute erstellt.

Neben dem iframe-Tag filtere ich nun auch script-Tags raus, deren src außerhalb der Feed-Domain liegt und Links/Bilder Referenzen werden nun auch relativ zur Feed-Domain konvertiert.

Liferea bietet das Feature, dass der Inhalt eines Posts nochmal vollständig von der Webseite heruntergeladen werden kann, falls der Feed nur eine Zusammenfassung enthält. Die berücksichtige ich nun auch bei der Ausgabe des vollständigen Feeds.

Den Sync zwischen Client und Server wurde durch das mit bz2 komprimierte Übertragen der sqlite-Datenbank beschleunigt. Die Datei wird dadurch auf ca. 20% ihrer eigentlichen Größe verkleinert. Gerade der Upload kann durch separater Komprimierung schneller durchgeführt werden.

Sonst sich noch viele weitere Fixes eingeflossen, welche mir beim täglichen Benutzen aufgefallen sind.

Zu finden ist das Projekt aktuell auf Github.

Subscribe and Comment

Cyd Noxzed — Sat, 17 Apr 2021 00:00:00 +0200

RSS Feed

In der letzten Woche habe ich auf dem Blog die Links zu den Feeds geändert. Bei der Gelegenheit lasse ich auch die Generierung der ATOM-Feeds bleiben und stelle alle Feeds nur noch im RSS-Format bereit.

Für meine Anforderungen reichen beide Formate, da sich diese bei den Features nur im Detail unterscheiden. Jeder Feedreader kann sowieso beide Formate lesen, somit macht es keinen Unterschied auf welches Format ich mich konzentriere. Ich habe mich jetzt halt für RSS entschieden, weil das Format mir irgendwie sympatischer ist¹.

Der Hauptfeed ist nun unter https://noxzed.de/feed/ zu erreichen und die jeweiligen Tag-Feeds unter der jeweiligen Übersichtsseite des Tags, zB. https://noxzed.de/tag/projects/feed/.

Kommentieren

Mit RSS gibts einen einfachen Weg, Inhalte zu abonnieren und auf neue Posts aufmerksam gemacht zu werden (idR durch den Feedreader). Jedoch ist das einen pure Einbahnsstrasse. Es gibt damit leider keinen Weg auf Beiträge zu kommentieren und dem Ersteller auf diese Kommentare hinzuweisen.

HTTP ist primär ein Pull-Protokoll und es ist deshalb nicht so einfach möglich einen Kommentar an den Ersteller zu versenden². Normalerweise ist direkt am Ende eines Posts ein Kommentarformular eingebunden und kann verwendet werden, auch gibt es Techniken wie Trackback, Pingback oder Webmention die ein Kommentar auf einer anderen Seite Referenzieren können.

Was verwendet man hier nun? Mit Web-Formularen zu hantieren, ergibt wenig Sinn, wenn der Blog selbst eine statische Seite ist. Wobei es auch hier durchaus Möglichkeiten gibt das alles abzufangen.

Um alles möglichst einfach und simple zu halten, biete ich unterhalb jedes Posts ab jetzt ledliglich einen mailto-Link an, in welchem der Betreff bereits mit dem Titel des Posts vorgefüllt wird. Um Crawlern nach Mail-Adressen die Arbeit ein bisschen zu erschweren, ist der Link mit HTML-Entities encodiert³.

Eigentlich ein echt schlechter Grund eine Format-Entscheidung zu treffen. Ich bin also offen für richtige Argumente. ↩︎
Das Erstellen eines Kommentares mit fest definierten Feldern und einem POST-Request könnte eigentlich relativ einfach umgesetzt werden könnte. Wobei hier auch Spam Tür und Tor geöffnet werden. ↩︎
Ich hab keine Ahnung, ob das wirklich was bringt, aber ich würde es jetzt einfach mal testen. Mal schauen, ob überhaupt Spam bis zu mir vordringt, mein Mailprovider filtert ja sowieso den Posteingang. ↩︎

Der Gegenpol zum Commercial Web: Das Small Web

Cyd Noxzed — Sun, 04 Apr 2021 00:00:00 +0200

Als Gegenpol des »Commercial Web« haben sich in den letzten Jahren einige Alternativen herausgebildet, welchen man durchaus unter dem Begriff "Small Web" zusammenfassen kann.

Allen gemein ist, dass sie sich auf dezentralen Beinen gegen die aktuell vorherschenden Plattformen stellen und eine transparente und unabhängigere Alternative zum Austausch mit Gleichgesinnten bieten.

Besonders ins Auge gefallen sind mir hierbei:

Beim Indieweb liegen die Daten bei den Benutzern selbst auf den eigenen Servern, welche mit einer persönlichen Domain aufgerufen werden. Verbunden werden die einzelnen Inhalte durch Metadaten im HTML (Microformats) und Webmention.

ActivityPub ist der Versuch ein allumfassendes Soziales Netzwerk aufzubauen, welches die aktuellen Größen wie Facebook oder Twitter ersetzen soll. Obwohl die Grundlage durch die Benutzung von ActivityStreams ziemlich durchdacht und logisch wirkt, scheint es wohl langfristig stärkere Hürden bei der Implementierung zu geben. Einen ActivityPub-Client hab ich bisher gar nicht gefunden, nur Mastodon kompatible Clients.

Die Ableger des tilde.club folgen der Tradition der alten Unix-Shared-Hostings und sind allgemein sehr Retro angelegt (zB wird stark auf Gemini gesetzt) und auch eher was für Technerds.

Und das gibt es noch Solid. Ich habe aber bisher nicht ganz verstanden wie das genau läuft, jedoch finde ich die Möglichkeit im Besitz der eigenen Daten zu bleiben ziemlich interessant¹.

Hierzu noch ein paar weiterführende Links:

Wobei im Internet grundsätzlich alle Daten bei der Übertragung kopiert werden und man strenggenommen nicht der Besitzer der Daten dauerhaft bleibt. ↩︎

Webferea 2

Cyd Noxzed — Fri, 02 Apr 2021 00:00:00 +0200

Letztes Wochenende habe ich die freie Zeit genutzt, um einige Features bei Webferea zu implementieren und die ganze Codebasis auf einen schöneren Stand zu bringen.

Dabei ist eher eine neue Major-Version herausgekommen, da ich durch die langsam notwendige Modularisierung der Codebasis lieber gleich komplett neu angefangen habe.

Herausgekommen ist Webferea2.

Darin enthalten sind auch neue Features, wie:

syncen der liferea.db über https anstelle sftp
angenehmeres Layout/Design, welches auf water.css aufbaut
Posts ohne separaten Seitenreload als gelesen markieren und zur Liste zurückkehren
Markieren von Posts auf der Liste
eingebettete Youtube-Links/Iframes werden jetzt gefiltert und zerstören somit nicht mehr das HTML-Rendering
relative Bildlinks innerhalb von Posts werden zu absoluten Links umgewandelt

Hier sind die alte und neue Version im direkten Vergleich:

Geplant wäre jetzt noch eine "Bewertungs"-Funktion für einzelne Posts, damit ich langfristige Statistiken sammeln kann, ob sich das Abo eines Feeds lohnt oder nicht. Bin mir aber noch nicht sicher, wie ich die einzelnen Posts bewerten soll, damit ich am Ende auch zuverlässige Aussagen über einen Feed treffen kann. Eine einfache +1/-1 Bewertung reicht vermutlich nicht, ob einen Feed umfangreich kuratieren zu können.

Messenger 2021 - Anwärter

Cyd Noxzed — Sun, 14 Mar 2021 00:00:00 +0100

Dies ist ein Fortsetzungsartikel zu Messenger 2021 - Anforderungen.

Matrix und XMPP

Nach längerem Einlesen in diversen Posts und Artikeln waren mir die Favoriten nach kurzer Zeit klar: XMPP und Matrix.

Beide verfolgen leicht andere Ziele und unterscheiden sich in diesen Punkten auch entsprechend von technischer Seite voneinander. Während XMPP durchaus in der Tradition der Messenger aus den 2000ern steht, ist Matrix ein Kind der 2010er, welches das modernere Slack als Vorbild hat. Beide stehen sich jedoch in nichts nach, werden aktuell weiterentwickelt und haben jeweils eigene Vor- und Nachteile¹.

Auch ein Nachrichtenaustausch zwischen den beiden kann via Brücken realisiert werden.

Das Problem ist jedoch: Man bekommt das nicht technikafinen Menschen nicht leicht erklärt. Gerade, wenn diese aus der WhatsApp-Sphäre kommen.

Einen Account anlegen und alle Kontakte neu suchen?² Welchen Server soll ich verwenden? Welchen Client soll ich installieren und warum gibts so viele? Kann ich damit Feature-XY nutzen?

Signal

Signal ist hierfür die Antwort. Es funktioniert ähnlich genug wie die anderen großen Messenger, sodass die Bedienung für normale Benutzer keine große Hürde darstellt. Dabei unterscheidet es sich von anderen Markteilnehmern dadurch, dass nicht nur der Client quelloffen ist, sondern auch der Server. Somit hätte man (zumindest theoretisch) die Möglichkeit, das ganze Netzwerk zu forken, wenn die Macher hinter Signal einen anderen Weg einschlagen. Die Nachteile, die dabei gerne aufgezählt werden, lassen sich anhand der gewählten Strategie von Signal durchaus nachvollziehen. Volle Kontrolle über Client und Server zu haben, erlaubt es einen durchaus, schnell Änderungen und Fixes einzuspielen. Wobei man dies auch mit einem soliden Framework oder Library abdecken könnte, welche alle unterschiedlichen Clients und Server nutzen. Die Bindung an die Telefonnummer, wird dafür benutzt, die bereits aufgebaute Kontaktliste auf dem Handy mitzuverwenden, ohne das man hier nochmal extra Personen irgendwo hinzufügen muss.

Wer ist nun der Anwärter?

Langfristig bleibt zu hoffen, dass Signal vielleicht doch Föderation aktiviert und es somit auch XMPP, Matrix und IRC Brücken geben kann. Ein weiterer Signal Client für Handy und Desktop wären natürlich auch nicht schlecht.

Vielleicht braucht es auch nur ein neues einfaches Protokoll für genau diesen Anwendungszweck. Ähnlich wie es HTTP für das Web war, benötigen wir so ein simples und universelles Protokoll vielleicht nur für Chats. Wobei das woran ich hier denke vermutlich einfach nur die E-Mail ist.

Es ist schon irgendwie tragisch, dass die Netzwerke untereinander nicht operabel sind. Letzten Endes werden auch nur ein paar Texte, Bilder und Metadaten hin und her geschickt.

Eigentlich fasst es die Republik mit Kill The Messenger ganz gut zusammen. Auch wenn sich dadurch vermutlich einige neue Probleme auftun.

Update:

Der Code der Serversoftware wurde von Signal wohl schon länger nicht mehr auf Github gepushed.³ Damit fällt ein wichtiger Pluspunkt weg, weswegen mal Signal als Messenger der Wahl auf seinem Smartphone installieren sollte.

Vielleicht wird der Code ja in den nächsten Wochen mal gepushed oder man bekommt ein offizielles Statement, warum der Code veraltet ist.

404.city betreibt einen eigenen XMPP-Server. ↩︎
Quicksy versucht dieses Problem zu beheben, würde aber auch nur funktionieren, wenn die anderen Kontakte auch Quicksy nutzen. Matrix nutzt ihren zentralen Discovery-Server, bei dem man optional seine Handynummer mit seiner Matrix-ID verknüpfen kann. ↩︎
linuxnews.de: Server-Code des Signal-Messenger auf GitHub veraltet ↩︎

Messenger 2021 - Anforderungen

Cyd Noxzed — Mon, 08 Mar 2021 00:00:00 +0100

Die Anforderungen an einen Messenger haben sich aus meiner Sicht in den letzten 5 Jahren nicht groß verändert:

Verschlüsselung
Förderiert
Freie Software
Gruppenfähig
Mobil nutzbar
Multi-Client
Von Handynummer unabhängiger Identifier

Die gängigen Messenger¹ erfüllen diese Anforderungen recht unterschiedlich. Übersicht bieten diverse Vergleichsmatrizen.

Bei den FLOSS Messengern gibt es die drei Platzhirsche IRC, XMPP und Matrix.

Verschlüsselung

Ende-zu-Ende Verschlüsselung ist obligatorisch und muss per default aktiviert sein. Nach den Ereignissen um Snowden wäre alles andere ziemlich fahrlässig. Bei Postkarten will man ja auch nicht, dass diese von allen Behörden und der Post selbst gelesen werden können (und digital auch werden).

Förderiert

Um einen Messenger möglichst unabhängig zu haben, sollte es möglich sein einen eigenen Server aufzusetzen oder auch einfach den Homeserver zu wechseln, ohne dabei auch alle Kontakte zu verlieren.

Vorbild für einen föderierten Nachrichtenservice ist hier sicherlich E-Mail. Bei Messengern ist es allgemein akzeptiert, dass man als Threema-Nutzer keine Nachrichten an Whatsapp- oder Telegram-Nutzer senden kann. Bei E-Mail wäre aber vermutlich das unverständnis erstmal groß, warum man keine E-Mail von GMX.de nicht zu GMAIL.com senden kann.

Die E-Mail Infrastruktur ist hier aber leider auch nicht perfekt. Deutschlandweit konzentrieren sich die Postfächer bei einigen großen Providern. ²

Freie Software

Client und Server sollten selbst kompilierbar sein. Idealerweise gibt es dementsprechend auch unterschiedliche Implementationen und nicht nur eine.

Wenn der Code nicht öffentlich ist, spielt es auch keine Rolle ob der Messenger die Nachrichten verschlüsselt überträgt. Man kann nicht prüfen, ob die Nachricht nicht auch noch woanders hin übertragen worden ist.

Damit man überprüfen kann, ob das Programm, das gerade läuft auch aus dem veröffentlichen Code enstanden ist, können Reproducible builds helfen.

Gruppenfähig

Bei Gruppen spielen die Messenger ihre große Stärke aus und erzwingen hier auch die notwendigen Netzwerkeffekte. Einer Einzelperson kann man auch eine SMS oder MMS³ zuschicken. Beim Koordinieren von einer ganzen Gruppe an Personen ist die Möglichkeit an ein ganzes Set an Personen gleichzeitig zu schreiben eine enorme Erleichterung, gerade wenn die Leute auch an das gleiche Set ohne Probleme antworten können.

Mobil nutzbar

Soweit ich das sagen kann, findet die Kommunikation dieser Jahre primär über das Smartphone statt. Primär hier vor allem über die diversen Messenger.

Ein Messenger, muss hier zwangsläufig auch die mobilen Endgeräte und deren plötzlichen Online/Offline-Wechsel mitmachen.

Die dafür ausgelegten bekannten Messenger haben damit keine Probleme. Die FLOSS-Alternativen, welche teilweise noch aus der Zeit vor dem Smartphone kommen, jedoch schon.

Wenn man im IRC offline ist, dann ist man auch nichtmehr in den entsprechenden Gruppen (Channels) präsent und würde dort auch alle Nachrichten verpassen. Abhilfe würde hier erst ein Bouncer schaffen.

Bei XMPP hat die Unterstützung dafür ziemlich auf sich warten lassen. Doch mittlerweile sind einige XEPs speziell hierfür verfügbar und in den Clients integriert. Das sah 2014 noch ganz anders aus.

Verbindung mit mehreren Clients parallel

XMPP hat dies schön mit den Ressourcen gelöst. Diese Herangehensweise ist für den Durchschnittsbenutzer vermutlich zu kompliziert, könnte ihm aber durchaus auch vollkommen verborgen bleiben.

Die aktuellen mobilen Messenger haben sich mittlerweile Desktop-Apps etabliert. Diese sind - zwar dem Stand der Technik geschuldet - auf Electron basierende abgespeckte Browser, aber immerhin.

Von Handynummer unabhängiger Identifier

Bei vielen Plattformen wird mittlerweile eine 2FA mit einer gültigen Handynummer erzwungen. Hintergedanke ist vermutlich, dass hiermit eine bessere Identifikation des Benutzers möglich ist. E-Mailadressen kann man durchaus unendlich haben, bei Handynummern vermutlich selten mehr als zwei.

Eine Identifikation der dahinterstehenden Person wäre damit immernoch möglich. Mal davon abgesehen, das man mit seiner Handynummer auch unabhängig von einem Messenger via SMS oder telefonisch kontaktiert werden kann. Das muss nicht zwangsweise ein Nachteil sein.

WhatsApp, Telegram, Signal, Threema, etc ↩︎
Die größten deutschen Anbieter finden sich alle unter dem Dach von United Internet. ↩︎
Ich kenne ehrlich gesagt keinen, der mehr als eine Handvoll MMS verschickt und empfangen hat. ↩︎

Liferea mobil nutzen

Cyd Noxzed — Thu, 18 Feb 2021 00:00:00 +0100

Schon seit über 10 Jahren nutze ich zum Lesen von RSS-Feeds¹ Liferea.

Damals bestand mein Internetkontingent mangels DSL aus ungefähr 1500 MiB UMTS pro Monat² (Down- und Upload). Jedes Megabyte war da kostbar und ich habe mir da verschiedene Strategien überlegt, um möglichst viel Traffic zu sparen. Angefangen von extremen Caching über einen lokalen Proxy, bis hin zum Blocken von Bildern auf Webseiten und deren Nachladen erst auf Klick/Anfrage.

Gerade beim täglichen Abklappern der favorisierten Webseiten, bin ich früher oder später dann auf RSS gestoßen.

Erstmal hab ich in meinem damaligen Mailclient³ einige Feeds abonniert, aber so ganz praktikable war das Abrufen der Feeds im Mailclient nicht. Hat alles wunderbar funktioniert, aber gedanklich war es eben ein Programm für Mails und nicht für Feeds. Also ging ich auf die Suche nach einem Stand-Alone Programm. Als Gnome/GTK-User hab ich Liferea ausprobiert und bin dabei dann erstmal auch geblieben.

Irgendwann relativ spät, verspürte ich auch den Drang, meine ungelesenen Feeds am Smartphone weglesen zu können. Wichtig war mir hier eigentlich nur, dass ich keine separate Feedliste pflegen musste und die Flags (Gelesen und Markiert) an den Items jeweils synchronisiert werden. Die leichteste Variante wäre es vermutlich gewesen einfach selbst einen Feedreader auf meinem Server zu hosten und die bisherigen Liferea-Feeds dorthin zu synchronisieren. Am Rechner bevorzuge ich jedoch native Clients, weil ich nicht alles im Browser nutzen will (Electron-based Apps fallen da auch mit rein).

Auf dem Smartphone ist die Sachlage leider ein bisschen anders. Apps fokusieren sich meistens auf einen Cloud-Ansatz und sind oftmals auch nicht self-hosted nutzbar. Leider bin ich jetzt kein App-Entwickler, zumindest habe ich mich damit noch nie groß befasst. Die einfachste Lösung war es fürs Smartphone eine Webseite zu bauen, welche die Feeds lediglich auflistet und die Items öffnen/lesen lässt. Da Liferea, alle Feeds in einer SQLite-Datenbank verwaltet und ich mich sowieso mal mit Webprogrammierung in Python auseinandersetzen wollte, hab ich mich kurzerhand mal in Flask eingelesen.

Eine Loginseite war dank des Tutorial schnell geschrieben und auch eine Listen-, sowie eine Artikelansicht selbst war auch schnell als Template anglegt und gefüllt. Auf den Artikelseiten dann noch Buttons zum Flaggen von »Gelesen« und »Markieren« hinzugefügt und diese Infos dann wieder in die SQLite-Datenbank abpeichern und fertig.

In der letzten Dekade haben sich bei mir mittlerweile 150 Feeds angesammelt ⁴, wobei diese auch immer schon fluktuieren. Manchmal kommt was Neues hinzu und manchmal fliegen Feeds wieder aus dem Reader raus, je nach aktueller Interessenlage. Auf dem Smartphone will ich jedoch nur eine Auswahl an Feeds lesen (primär kurze Artikel, die man leicht zwischendrinn lesen kann). Also filtere ich die Liste der anzuzeigenen Feeds, um nur Artikel von ausgewählten Feeds angezeigt zu bekommen.

Um jetzt, die beiden SQLite-Datenbanken wieder in Einklang zu bringen führt ein Synchronisationsskript folgendes aus:

Download der SQLite-Datenbank vom Server
Übernahme aller veränderten Flags (gelesen, markiert) in die Datenbank des Desktoprechners
Upload der aktualisierten lokalen Datenbank auf den Server

Upload und Download funktioniert aktuell via SFTP, schöner wäre hier vermutlich eine Übertragung via HTTPS, für das Feature hatte ich jedoch noch keine Zeit und Muße. Generell hab ich hier die Entwicklung nicht weiter vorangetrieben, obwohl ich die Webseite fast täglich aufrufe und benutze.

Das Projekt nennt sich Webferea und ist auch auf Github zu finden.

Ein paar weitere Key-Features würden mir noch fehlen, aber alles läuft fast darauf hinaus einen kompletten Rewrite durchzuführen und am Ende hätte ich fast einen ganzen Feedreader für das Web geschrieben (was initial eigentlich nicht mein Ziel war). Eigentlich wäre es schön, wenn mir der Feedreader auch ein bisschen beim Kuratieren unterstützt. Wenn ich die Artikel eines Feeds gar nicht lese, könnte ich diesen auch mittelfristig entfernen. Die Aufmerksamkeitsökonomie macht auch bei den Feeds nicht halt und man muss sich schon ein bisschen Zügeln, um nicht den ganzen Tag im Feedreader zu verbringen.

Hierfür hätte ich auch einige Ideen im Hinterkopf. Vielleicht bringe ich diese auch mal hier im Blog unter.

Damit meine ich auch Atom- oder andere Web-Feeds. Das dass von technischer Seite nicht ganz passt, ist mir bewusst. ↩︎
Heutzutage übertrage ich schonmal 80 - 160 GiB pro Monat, auf meinem Desktoprechner allein. Der Großteil wird hierbei sicherlich aus Videos und Cloudanbindung bestehen. Sollte ich bei Gelegenheit vielleicht mal auswerten. ↩︎
Vermutlich Thunderbird, wenn mich meine Erinnerungen nicht täuschen. ↩︎
Von den 150 Feeds sind fast die Hälfte Feeds von Audio-Podcasts und YT-Videos. ↩︎

Post Folder

Cyd Noxzed — Sun, 14 Feb 2021 00:00:00 +0100

Der Zwang Speicherplatz zu sparen und Dateien ohne Umwege auf einen anderen Computer zu übertragen tragen zu ungewöhnlichen Lösungen bei.

Um neue Dateien von meinem Computer auf mein Mediaserver zu übertragen, muss dieses gerade laufen, andernfall kann ich keine Dateien rüberkopieren.

Im manuellen Modus heißt das: Wenn der Mediaserver läuft, mounte ich dessen SD-Karte und kopiere manuell die Videos/Bilder in den entsprechenden Ordner. Wenn dieser nicht läuft, kann ich auch nichts kopieren.

Um diesen Misstand zu beseitigen, habe ich mich letzten Jahr auf die Suche nach einer Lösung hierfür gemacht.

Lösung finden

Die einfachste aller Varianten wäre vermutlich Syncthing. Ein Folder auf beiden Geräten verbinden und automatisch synchronisieren lassen, wenn beide Geräte laufen. Der Haken an der Sache ist jedoch der, dass ich dann den gesamten Speicherverbrauch auf meinem Media-Server auch auf meinem Desktop-Rechner verursache.

Aus Backup-Sicht sicherlich ganz gut, aus der Sicht des Speicherplatzverbrauchs jedoch nicht ganz so gut.

Unidirektionaler Sync mit rsync? Dagegen habe ich mich auch entschieden, ich kann mich jedoch leider nicht an die Gründe hierfür erinnern. Vermutlich fiel rsync raus, da es die Daten lokal nicht löscht oder abändert und ich dann die Referenz verliere, welche Daten bereits übertragen worden sind.

Nachdem ich kein Tool finden konnte, welches meinen Anforderungen entsprach, habe ich mich hingesetz und schnell ein eigenes Skript geschrieben.
Das Ergebnis kann man sich weiter unten im Post anschauen.

Was macht es?

Man konfiguriert einen Ordner, dessen Dateien und Unterordner auf das andere System übertragen werden sollen. Aktuell ist das nur via SFTP möglich. Im zu übertragenen Ordner erstellt man eine Konfigurationsdatei .postfolderrc welche die Verbindungseinstellungen des Zielsystems enthalten, sowie den Zielordner für die Übertragung.

Das Skript bekommt den Quellordner als Parameter übergeben und sucht sich dort die Konfigurationsdatei. Danach werden alle darin enthaltenen Dateien und Ordner rekursiv in den Zielordner übertragen. Wenn eine Datei übertragen wurde, dann wird diese im Quellordner gelöscht und mit einer leeren Datei selben Namens ersetzt. Zur Unterscheidung bekommt diese leere Datei noch das Suffix ».postfolder«, um diese auch auf den ersten Blick als bereits übertragen zu erkennen.

Wenn das Skript als Cron gestartet wurde, wird jede Minute geprüft ob der Zielorder erreichbar ist und dann alle noch nicht übertragenen Dateien kopiert.

Damit es durch den Cron nicht mehrfach ausgeführt wird (zb. weil gerade eine größere Datei übertragen wird), wird in /tmp/ ein Pidfile gesetzt und somit die doppelte Ausführung des Skripts verhindert.

Das Skript loggt die Übertragung aller Dateien mit und schreibt am Ende der Übertragung noch den verbleibenden freien Speicherplatz auf dem Zielgerät in das Logfile.

Installation

Folgende Pakete müssen für das Skript installiert werden:

pysftp
yaml
pid

oder ganz einfach via pip:

$ pip install pysftp yaml pid

Das Skript selbst kann in einen beliebigen Ordner gelegt und
ausführbar ($ chmod +x post_folder.py) gemacht werden.

Konfiguration

Im Ordner der hochgeladen werden soll, muss die versteckte Datei .postfolderrc liegen. Folgender Inhalt muss enthalten sein:

adapter: sftp
adapter-config:
  username: rpi
  password: rpipassword
  host: 192.168.1.100
  port: 22
remote_directory: /home/rpi/remotedirectory

Falls die Dateien automatisch hochgeladen werden sollen (empfohlen), muss ein Eintrag in die Crontab erfolgen:

* * * * * /path/to/post_folder.py "/path/to/directory/that/should/be/uploaded/" >> ~/cron.log 2>&1

Code

# -*- coding: utf-8 -*-
#
# post_folder.py - Transfer files/folders to another remote server
# Copyright (C) 2021 Cyd Noxzed
# 
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# 
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

import os, sys
import glob
import logging

import yaml
import pysftp
from pid import PidFile, PidFileAlreadyLockedError


class GenericSyncer:
    def __init__(self, local_folder_path, path_to_remote_folder) -> None:
        super().__init__()
        self.reference_suffix = ".postfolder"
        self.temp_suffix = ".postfolder_tmp"
        self.local_folder_path = local_folder_path
        self.path_to_remote_folder = path_to_remote_folder

    def get_files_to_sync(self, path):
        files = []
        if not path.startswith("/"):
            path = './' + path
        for filename in glob.glob(path + '**', recursive=True):
            cleaned_filename = filename.replace(path, '', 1)
            if len(cleaned_filename) > 0 and os.path.isfile(filename) and not cleaned_filename.endswith(
                    self.reference_suffix):
                files.append(cleaned_filename)
        return files

    def replace_with_reference(self, file):
        os.remove(self.local_folder_path + file)
        open(self.local_folder_path + file + self.reference_suffix, 'a').close()

    def sync(self):
        pass


class SftpSyncer(GenericSyncer):
    def __init__(self, local_folder_path, path_to_remote_folder, adapter_configuration) -> None:
        super().__init__(local_folder_path, path_to_remote_folder)
        self.config = adapter_configuration
        self.connection = None

        logfile = local_folder_path + 'logfile' + self.reference_suffix
        logging.basicConfig(
            filename=logfile,
            level=logging.INFO,
            format='%(asctime)s | %(name)s | %(levelname)s | %(message)s',
            datefmt='%Y-%m-%d %H:%M:%S'
        )

    def sync(self):
        files = self.get_files_to_sync(self.local_folder_path)

        if len(files) > 0:
            with pysftp.Connection(**self.config) as sftp:
                for file in files:
                    self.upload_file(file, sftp)
                logging.info(
                    "finish upload - available space on remove device: {}".format(self.get_available_space(sftp, '/')))

    def get_available_space(self, sftp, device):
        output = sftp.execute("df -H --output=avail /")
        available = output[1].decode('utf8').strip()
        return available

    def upload_file(self, file, sftp):
        logging.info("upload [{}] -> [{}/{}]".format(file, self.path_to_remote_folder, file))
        sftp.chdir(self.path_to_remote_folder)  # chdir to remote folder
        self.create_parent_dirs(file, sftp)
        sftp.chdir(self.path_to_remote_folder)  # chdir to remote folder

        success = sftp.put(self.local_folder_path + file, file)
        remote_size = success.st_size
        local_size = os.path.getsize(self.local_folder_path + file)

        if local_size == remote_size:  # successfully transfered
            self.replace_with_reference(file)
            logging.info("upload finished: [{}]".format(file))

        return True

    def create_parent_dirs(self, file, sftp):
        parts = file.split('/')
        if len(parts) > 1:
            for p in parts[:-1]:  # dont use the last part as directory
                if not sftp.isdir(p):
                    sftp.mkdir(p)
                sftp.chdir(p)
        return True


def main():
    defaultrc = ".postfolderrc"

    if len(sys.argv) > 1:
        path_to_configuration = sys.argv[1]
        if os.path.isdir(path_to_configuration):
            path_to_configuration = path_to_configuration.rstrip('/') + '/' + defaultrc
    else:
        path_to_configuration = defaultrc

    path_to_local_folder = path_to_configuration[:(0 - len(defaultrc))]
    yamlfile = yaml.safe_load(open(path_to_configuration, 'r'))
    adapter_name = yamlfile['adapter']
    path_to_remote_folder = yamlfile['remote_directory']

    try:
        with PidFile(piddir='/tmp/post_folder.pid'):
            adapter = None
            if adapter_name == 'sftp':
                adapter = SftpSyncer(path_to_local_folder, path_to_remote_folder, yamlfile['adapter-config'])

            if adapter:
                adapter.sync()
    except PidFileAlreadyLockedError as e:
        pass
    except Exception as e:
        template = "An exception of type {0} occurred. Arguments: {1!r}"
        message = template.format(type(e).__name__, e.args)
        print(message)
        pass


if __name__ == '__main__':
    main()

Fazit

Nächster Step wäre vermutlich auch die Löschung der Daten auf dem Media-Server, wenn ich die Referenzdateien (*.postfolder) auf dem Desktop-PC entferne.

Da bin ich jedoch noch nicht dazu gekommen, bzw war es mir bisher noch nicht wichtig genug.

Für Anregungen oder Verbesserungsvorschläge an dem Skript oder dem System an sich wäre ich übrigens echt dankbar.

Entity-Component-System

Cyd Noxzed — Wed, 10 Feb 2021 00:00:00 +0100

Bei der Spieleentwicklung ist man dazu geneigt alles im Spiel objektorientiert umsetzen zu wollen. Es bietet sich ja eigentlich auch an. Eine Spielfigur, ein Healthpack oder ein Feuerball sind ja alles Objekte. Es gibt ein Hauptobjekt, von dem alle anderen Objekte abgeleitet und weiter spezialisiert werden.

Objekt-orientierter Ansatz

Auch ich hab das offensichtliche als gegeben hingenommen und so auch meine Entities im Spiel entsprechend aufgebaut:

Actor (Hauptobjekt)
- Pickups (aufsammelbare Gegenstände)
- Healthpack
- Ammo
- Pawn (Spielfigur)
  - Bot
    - Mob (Monster oder Beast)
  - Player (steuerbare Spielfigur)
- Projektil
  - Feuerball
  - Pfeil
- Navigation (funktionale Spielpunkte)
- Teleporter
- Spawn (Einstiegspunkt für Pawns)

Abhängig von der Größe und dem Umfang des Spiels wird sich mit so einem Design früher oder später eine Klasse herauskristallisieren, welche zu einem großen Blob wird. Bei einem späteren Design wollte ich sowas umgehen und bestimmte Charakteristika in eigene Subklassen (Traits) auslagern. Es gab dann so Traits wie Movable (für Velocity und Bewegung), Collidable (für die Kollisionsberechnung), Animation (für die grafische Ausgabe), oder Mortal (für Health und so).

Diese Trait-Klassen konnte ich dann – dank Mehrfachvererbung – einfach in die jeweiligen Klassen mit reinladen, der Ansatz ähnelt dabei Komposition:

class Pawn(Actor, Visible, Collidable, Movable, Equipable, Mortal):
    """ A Pawn is every character or mob in the world """

    def __init__(self) -> None:
        Actor.__init__(self)
        Visible.__init__(self)
        Collidable.__init__(self)
        Movable.__init__(self)
        Equipable.__init__(self)
        Mortal.__init__(self)

An sich konnte ich mit diesem Design gut arbeiten. Teilweise hatten die Traits noch aktiv Properties, um zB. diese Unsichtbar zu machen oder die Kollisionserkennung zu deaktivieren.

Probleme bekame ich erst dann, als ich die Objekte nach JSON serialisieren und im Anschluss wieder deserialisieren wollte. Notwendig wäre das für eine mögliche Implementierung eines Netzwerk-Multiplayers oder zum Speichern des Spielstandes. Für beides benötigte ich nicht zwangsläufig JSON und könnte es auch über Pickle durchführen, wobei das jetzt nicht der sicherste Weg wäre.

Serialisieren war nicht das Problem: Alle Properties auslesen (pawn.__dict__) und die Sache ist schon erledigt.
Funktioniert zumindest in 90 % der Fälle (wenn es sich um normale Datentypen handelt).

Die Deserialisierung gestaltete sich jedoch schwerer. Eine leere Pawn Klasse erstellen und diese dann Stück für Stück mit den jeweiligen Properties füllen? Position (zwei floats), Name der Figur (string) und Lebenspunkte (int) gehen ja noch. Aber wenn ein Trait Binärdaten (Bild) enthält (Visible), muss ich einen Sonderweg gehen und die abgespeicherte Referenz auf die Datei zum Laden der Animation nutzen. Das funktioniert für vielleicht ein paar Sonderwege, aber früher oder später ist der zusätzliche Aufwand zu groß, da diese bei fast jedem Feature berücksichtigt werden müssen.

Nach kurzen Recherchen bin ich bereits auf eine Lösung dieses Problems gekommen: Entity-Component-System.

Entity-Component-System

Es gibt im Netz bereits viele gute Beschreibungen der unterschiedlichsten Flavours von ECS (zB die von roguebasin.com), deswegen nur kurz die Grundlagen erklärt:

Entity: ID zur Kennzeichnung einer Entity in der Spielwelt (zb ein eindeutiger String oder eine aufsteigende Zahl)
Component: Ein einfacher Datencontainer, welcher die Daten für die jeweilige Domäne enthält (zB. eine einfache Klasse oder ein C-Struct)
System: Klassen/Handler, welche die Componenten abhängig zum Spielverlauf erstellen und modifizieren

Jede Entity kann somit eine Sammlung oder Zusammenstellung aus unterschiedlichen Components sein. Abhängig davon, ob diese Komponente für die jeweilige Entity benötigt wird. Das Entity Pickup ist Aufsammelbar (Collectible), aber unbeweglich (Movement).

	Position	Movement	Controls	Collision	Collectible
Player	X	X	X	X
Enemy	X	X		X
Pickup	X			X	X
Projectile	X	X		X

Jede Component hat ein oder mehrere Systeme, welche die Daten darin modifizieren können. Diese Systeme iterieren einfach über alle dafür zuständigen Componenten und verarbeiten diese. Durch das dynamische Hinzufügen oder Löschen von Componenten an einer Entity ist man extrem flexibel. Soll eine Entity nicht mehr dargestellt werden? Einfach die Grafik-Komponente entfernen. Soll die Steuerung vom Spieler auf den Gegener übergehen (Mind-Control o.ä.)? Dann muss die zuständige Komponente (im oberen Beispiel Controls) am Player gelöscht und am Enemy hinterlegen werden.

Das Upgrade auf ECS hat mich durch die bereits vorhandene Domänen-Trennung der Traits nicht groß an Zeit gekostet. Es ging mehr Zeit damit verloren eine geeignete Python-ECS-Library zu finden oder gar selbst eine zu schreiben. Ich habe mich letzten Endes für esper, da es genau meine Anforderungen erfüllte:

Component ist normales Objekt
die System Hauptklasse hat ein simples Interface
als Entities kann ich UUIDs verwenden (hierzu musste ich jedoch esper ein bisschen umbauen, da hier per Default ein Integer hochgezählt wird)

Der simple und elegante Ansatz macht ECS zu einem nicht zu unterschätzenden Pattern in der Spieleprogrammierung. Die domänenbasierte Trennung von Daten und Logik, hat es mir einfach gemacht, die ganze Spielewelt (alle Entities und die zugehörigen Components) zu serialisieren und daraus wieder eine komplette Spielewelt aufzubauen. Laden und Speichern konnte ich somit binnen kürzester Zeit implementieren.

Wobei ich auch dazu sagen muss, dass ich auf Binärdaten innerhalb der Components verzichtet habe. Die Render-Compontent enthält in meinem Ansatz lediglich den Namen der Animation, den aktuellen Frame, sowie die Restdauer des Frames. Mit der Serialisierung war auch die Erstellung eines rudimentären Netzwerkcodes keine gewaltige Aufgabe mehr.

Als weiterführendes Thema kann ich auch den Talk »Is There More to Game Architecture than ECS?« von Bob Nystrom auf der Roguelike Celebration 2018

Direktor und Szenen

Cyd Noxzed — Fri, 05 Feb 2021 00:00:00 +0100

Wie ein Theaterstück kann auch ein Spiel in mehrere Szenen unterteilt werden. Hierbei geht es jedoch weniger um einzelne Levelabschnitte, sondern um den allgemeinen Workflow.

Zum Beispiel:

 +-------+   +------+   +---------+   +-----------------+   +---------+   +------------+
 | Intro +-->+ Menu +-->+ Level 1 +-->+ Zwischensequenz +-->+ Level 2 +-->+ Endsequenz |
 +-------+   +------+   +---------+   +-----------------+   +---------+   +------------+
                ^            |                                    |             |
                |            |       +--------------+             |             |
                |            +------>+ Todessequenz +<------------+             |
                |                    +--------------+                           |
                |                                                               |
                |                +-----------+                                  |
                +--------------->+ Highscore +<---------------------------------+
                                 +-----------+

Wer sich hierbei an eine Statemaschine erinnert fühlt, hat das Grundprinzip vermutlich verstanden.

Jede Szene verarbeitet hierbei für sich den getätigten Input verarbeitet diesen zu einer Ausgabe. Als Objekt (oder Interface) sähe eine einfache Szene etwa so aus:

class Scene(object):
    def __init__(self):
        pass

    def process_input(self, input_events = None):
        """ Process the input of the current loop """
        pass

    def update(self, dt):
        """ Update the current scene based on the given delta time in milliseconds """
        pass

    def render(self, screen: pygame.Surface):
        """ Render the scene to the screen """
        pass

Um die ganzen verschiedenen Szenen zu verwalten wird ein Direktor benötigt. Jedes Spiel sollte nur einen davon haben, dieser enthält den normalen Gameloop und initialisiert auch das Fenster.

Ein einfacher Direktor könnte etwa so aussehen:

class Director(object):
    def __init__(self, display_size: list, fps: int = 30):

        self.display_size = display_size
        self.fps = fps

        self.window = None
        self.scenes = {}
        self.running_scene = ''

        self.quit_attempt = False

        pygame.init()
        self.display = pygame.display.set_mode(display_size, 0)

    def run(self):

        clock = pygame.time.Clock()

        while not self.quit_attempt:  # Main loop

            if self.running_scene not in self.scenes:
                continue
            scene = self.scenes[self.running_scene]

            dt = clock.tick(self.fps)

            # process input
            input_events = pygame.event.get()
            scene.process_input(input_events)

            # update
            scene.update(dt)

            # render
            self.display.fill((0, 0, 0))
            scene.render(self.display)
            pygame.display.flip()

Als Basis würden diese beiden Klassen erstmal ausreichen. Initialisieren und starten könnte man das ganze dann so:

scene1 = Scene()
scene2 = Scene()
director = Director((800, 600), 30)
director.scenes = {'1': scene1, '2': scene2}
director.running_scene = '1'
director.run()

Gewechselt kann die Szene dann einfach durch das abhändern der Variable director.running_scene = '2'.

Für das Speichern der Szenen reicht ein dict erstmal aus, schöner wäre es jedoch trotzdem wenn man hierfür eine geeignete collection verwendet und diese über eine separate Funktion director.add(scene1) füllt.
Der Name der Szene könnte auch in der Szene selbst gespeichert werden. Den Direktor könnte man auch an die Scene selbst mit übergeben und dann kann die Scene bei Bedarf die nächste Szene aufrufen.

Den Übergang von einer Szene in die Nächste kann man mit Transitions auch spannender gestalten. cocos2d's scenes Modul bietet hier einige coole und interessante Übergänge an. Prinzipiell basieren diese immer darauf ein Bild in ein anderes zu überführen.

Möglichkeiten zum Optimieren und Anpassen bieten die beiden Klassen definitiv.

Was für ein Spiel soll es sein?

Cyd Noxzed — Sun, 31 Jan 2021 00:00:00 +0100

Sich ein genaues Ziel für ein Spiel zu definieren ist üblicherweise der härteste Teil. Man sollte sich nicht zu viel vornehmen und alle möglichen kleinen Schritte vorher schon grob durchplanen.

Ich möchte ein Top-down Multiplayer Dungeon Crawler kreieren, bei dem man über LAN (oder ggf. Internet) gemeinsam mehrere Ebenen einer computergenerierten Dungeon überwinden muss. Zusätzlich soll das Spiel später um einen Deathmatch- oder CTF-Modus erweitert werden können.

In den letzten Jahren habe ich bereits mehrere Anläufe unternommen, so ein Spiel zu schreiben. Der erste Anlauf war straight-forward mit pygame. Aufgrund schlechtem Codedesigns wurde es immer schwieriger schnell und einfach neue Funktionalitäten in das bereits bestehende Spiel einzubauen. Mein Ziel konnte ich damit nicht erreichen.

Bei meinem zweiten Anlauf setzte ich auf cocos2d. Hauptgrund hierfür war die einfachere handhabe mit transparenten Grafiken und das einfache aber umfangreiche Actions-Submodule. Leider wurde die Bibliothek zu dieser Zeit nicht weiterentwickelt und es gab für einige Anwendungsfälle keine notwendigen Funktionalitäten. Beispielweise eine stärkere Unterstützung zum Lesen von Layern und Properties des tiled-Editors. Abgesehen davon ist python-cocos2d eine gute Bibliothek zum Schreiben von Spielen.

Der dritte Anlauf war dann der, alle notwendigen und umfangreicheren Funktionen aus bereits existierenden Libraries zu ziehen und diese in ein Framework einzubauen, welches ich dann dazu benutze das Spiel selbst umzusetzen. Hierzu habe ich wieder auf pygame zugegriffen, da es hierfür eine größere und aktiviere Community gibt, auf deren gepflegten Code man aufbauen kann. Mit dem Framework wollte ich dann auch einen großen Wurf machen (umfangreiche Dokumentation und alles auch eine 100%ige Testcoverage).

Mit diesem Vorhaben habe ich mich übernommen, auch wenn ich hierbei viel gelernt habe, bei der Implementation der einzelnen Subsysteme. Ziel sollte es defintiv nicht sein, eine »Engine« zu schreiben, sondern das Spiel muss das Ziel sein¹. Das habe ich dann nach einiger Zeit auch gemerkt.

Der Fokus liegt jetzt jedenfalls auf ein Spiel, auch wenn ich mich auch stark mit dem dahinterliegenden Design auseinandersetze. Immerhin will ich ja später auch ganz leicht und schnell neue Elemente einfügen können. Den genauen Umfang hab ich bisher aber leider auch noch nicht definiert.

Write Games, Not Engines ↩︎

Hello World

Cyd Noxzed — Sat, 23 Jan 2021 00:00:00 +0100

Nach längerem Überlegen habe ich mir nun doch einen Blog aufgesetzt und diesen auch Online gestellt¹.

Der Blog dient dazu meine Gedanken zu verschiedenen Themen zu ordnen und mir auch beim Reflektieren zu helfen. Außerdem kann es ganz interessant sein, Jahre später diese Posts mal wieder zu lesen. Vielleicht lösen meine Texte auch den einen oder anderen Gedankengang beim Leser aus.

Ich habe mich dazu entschieden den Blog auf Deutsch zu schreiben, da ich für mich selbst die Hemmschwelle möglichst niedrig halten wollte. Wobei ich mir beim Formulieren von Sätzen im deutschen nicht unbedingt leichter tue, zu oft beginne ich damit einen englischen Satz zu formulieren.

Der Blog selbst besteht technisch aus statischen HTML-Seiten, welche direct vom Webserver ausgeliefert werden. Kein PHP, MySQL, CGI, etc ist hierfür notwendig. Um die Seite bei jeder Änderung neu zu bauen, wird im Hintergrund Pelican, ein »Static Site Generator«, verwendet.

Wenn der Leser dies im WWW liest, dann deutet dass jedenfalls stark darauf hin. ↩︎