Hexer — Hexfeld-Karteneditor für Pen-and-Paper-Rollenspiele

Ausgangslage

Wer eine Hex-Crawl-Kampagne leitet, braucht eine Karte, mit der sich tatsächlich spielen lässt: Sie muss verbergen, was die Gruppe noch nicht entdeckt hat, Reisen über unterschiedliches Gelände nachhalten und sich während der Sitzung live teilen lassen. Vorhandene Werkzeuge sind entweder allgemeine Zeichenprogramme ohne Spiellogik oder virtuelle Spieltische, bei denen die Karte nur Beiwerk ist.

Hexer ist meine Antwort darauf — als Solo-Produkt gebaut und betrieben. Damit war der Umfang nie auf den Editor beschränkt: Es brauchte ebenso eine Nutzerverwaltung, eine Abrechnung, eine Deployment-Pipeline und eine Testabdeckung, auf die ich mich verlassen kann, wenn ich ohne zweites Augenpaar schnell etwas ändere.

Vorgehen

Die Anwendung läuft auf Astro 6 mit serverseitigem Rendering und Node-Standalone-Adapter, React 19 übernimmt die interaktiven Bereiche, die Memoisierung erledigt der React Compiler. Der Karteneditor selbst ist bewusst kein React: Er ist ein PixiJS-8-Canvas mit über zwanzig übereinandergelegten Layern — ein Hexfeld-Raster, das bei jedem Pinselstrich neu zeichnet, braucht direkte Kontrolle über das Rendering statt eines virtuellen DOM.

Der Client-State liegt in zehn thematisch getrennten Zustand-Stores, zundo liefert ein pro Strich gebündeltes Undo über zwanzig Schritte. Supabase stellt PostgreSQL, Authentifizierung und Realtime bereit, Stripe die Abonnements. Die Hexfeld-Geometrie basiert auf honeycomb-grid mit Pointy-Top- und Odd-r-Offset-Koordinaten, Regionsgrenzen entstehen über Polygon-Clipping.

Meine Rolle

Alles — Architektur, Umsetzung, Infrastruktur, Abrechnung und Support. Das Produkt umfasst:

Bearbeitung: 35 Geländetypen und über 55 Kartenobjekte, Pinselmalerei mit Größenwahl, ein Pfadwerkzeug, ein Regionswerkzeug mit berechneten Polygongrenzen sowie ein Notizwerkzeug auf Tiptap-Basis in frei platzierbaren, skalierbaren Fenstern.

Spielmechanik: eine Fog-of-War-Engine auf Bitfeld-Basis mit Abbrand-Animation und Pergament-Textur, ein dynamisches Sichtlinien-System, ein Reisewerkzeug mit Bewegungskosten und Reise-Heatmap sowie Unterwelt-Ebenen über vier Tiefen.

Prozedurale Generierung: Weltgenerierung auf Simplex-Noise-Basis mit Biom-Regeln und Nachbearbeitung der Übergänge, dazu eigene Generatoren für Höhlen, Flüsse (inklusive Zusammenflüssen und Auen) und Straßen.

Plattform: Supabase-Auth mit httpOnly-Cookie-Sessions, CSRF-Schutz und Rate Limiting; der komplette Stripe-Lebenszyklus mit Checkout, Webhooks, siebentägiger Testphase, Kulanzfristen und Self-Service-Portal; transaktionale E-Mails über Resend; Export nach JSON, SVG, PNG, Universal VTT/DD2VTT, Hex Key und Foundry VTT.

Technische Schwerpunkte

Rendering in Ebenen. Der Editor legt über zwanzig PixiJS-Layer übereinander — Gelände, Objekte, Pfade, Regionen, Fog, Sicht, Cursor — sodass jede Ebene unabhängig neu gezeichnet werden kann. Karten bis 200×200 Felder bleiben flüssig, weil ein Pinselstrich nur die Ebenen invalidiert, die er tatsächlich berührt.

Fog of War als Bitfeld. Der Erkundungsstand liegt als gepackte Bits statt als Objekt pro Feld vor. Das hält die Datenmenge klein genug, um sie bei jedem Autosave zu speichern und günstig zu vergleichen, wenn zu entscheiden ist, was ein Spieler sehen darf.

Echtzeit-Multiplayer über SSE. Live-Cursor und Freihandzeichnen laufen über einen Presence-Hub auf Server-Sent-Events-Basis — mit strikter Trennung zwischen Spielleiter- und Spieleransicht, damit Fog und private Notizen nie beim falschen Client ankommen.

Tests als Absicherung im Alleingang. Über 380 Testdateien aus Vitest-Unit- und Integrationstests sowie Playwright-E2E-Specs, bei rund 80 % Statement-Coverage und einem Pre-commit-Hook, der jede neue Quelldatei ohne zugehörigen Test blockiert. Testgetrieben zu arbeiten — mit Claude Code als Pair-Programming-Werkzeug — ist der Grund, warum sich dieses Tempo ohne Review-Partner halten lässt.

Ergebnis

Hexer läuft produktiv unter hexermap.com mit kostenlosem und kostenpflichtigem Tarif und vollständigem Zahlungsprozess, ausgeliefert über GitHub Actions nach Azure hinter einem Caddy-Reverse-Proxy mit TLS und HTTP/3. Es ist das Projekt, in dem ich jede Entscheidung selbst verantworte — Produkt, Architektur, Code, Infrastruktur und die Kundschaft, die sich meldet, wenn etwas klemmt.