Solarpunk Wiki

Ausgangslage

Solarpunk ist ein Survival-Crafting-Game mit Erscheinungsdatum Q2 2026. Schon vor dem Launch hatte sich eine aktive Community aus Alpha-Footage und Entwickler-Updates herausgebildet - aber es gab keine strukturierte Referenz für die Spielmechaniken. Items, Gebäude, Pflanzen, Tiere, Energiesysteme und der Tech-Tree mussten so dokumentiert werden, dass das Wiki pünktlich zum Spielstart live gehen kann.

Die Anforderung war klar: ein Wiki, das beim Launch 600+ Datenbank-Einträge verwaltet, mit einem Design das zur visuellen Identität des Spiels passt, einer Navigation die mit wachsendem Inhalt skaliert, und einem Codebase den ein Nicht-Entwickler nach der Übergabe selbst erweitern kann.

Was gebaut wurde

Das Solarpunk Wiki ist eine statisch generierte Referenzseite auf Basis von Next.js 15 mit React 19 und TypeScript. Die gesamte Datenschicht liegt in /src/data/ als typisierte TypeScript-Dateien - kein CMS, keine Datenbank, keine API-Calls zur Laufzeit. Jeder Eintrag ist ein TypeScript-Objekt mit definiertem Schema: fehlerhafte Daten schlagen beim Build fehl, nicht in der Produktion.

Datenkategorien beim Launch:

• Items - Verbrauchsgüter, Materialien, Crafting-Komponenten
• Buildings - Strukturen mit Ressourcenanforderungen und Freischaltbedingungen
• Crops - Wachstumsphasen, Ertrag, Bodenanforderungen
• Animals - zähmbare Tierarten, Produkte, Habitatanforderungen
• Energy - Energiequellen, Speicher, Verbrauchsraten
• Technology - der vollständige Tech-Tree mit Voraussetzungen und Freischaltpfaden

Jede Kategorie hat ihre eigene Seitenstruktur, Such- und Filterfunktion sowie Querverweise zu verwandten Einträgen. Eine Tierseite verlinkt auf die Pflanzen, die es frisst; eine Gebäudeseite auf die Items, die es produziert.

Architektur

Statische Generierung: Next.js 15 mit generateStaticParams erzeugt zur Build-Zeit eine Route pro Eintrag. Mit 600+ Einträgen über sechs Kategorien hält Turbopack den Build schnell, auch wenn der Datensatz wächst. Das Ergebnis ist eine Site ohne Runtime-Datenabrufe - jede Seite ist reines HTML und CSS.

Datenschicht: Alle Einträge sind typisierte TypeScript-Objekte in /src/data/. Jede Kategorie hat ihre eigene Typdefinition. Der TypeScript-Compiler erkennt fehlende Pflichtfelder und Typfehler vor dem Deployment. Neue Einträge hinzufügen bedeutet eine TypeScript-Datei bearbeiten - keine Datenbankmigrationen, kein Admin-Interface.

Design-System: Die visuelle Sprache nutzt eine eigene Tailwind-v4-Palette mit acht Farbfamilien aus der Spielgrafik: Golden Hour (warme Gelbtöne), Leaf (Grüntöne), Sky (Blautöne), Terra (Erdtöne), Brass (metallisches Amber), Dusk (tiefe Lila), Ash (Neutraltöne) und Ember (Akzentrot). Jede Inhaltskategorie ist einer Farbfamilie zugeordnet - Navigation wird intuitiv, bevor man die Labels liest.

Navigation: Archipel-Struktur - die Startseite ist eine Kategoriekarte, jede Kategorie ein Index, jeder Eintrag eine Detailseite. Die Hierarchie ist immer im Breadcrumb sichtbar. Keine Seitennavigation, die mit wachsendem Inhalt unübersichtlich wird.

Technische Entscheidungen

TypeScript als CMS. Die Alternative war ein Headless-CMS oder ein Flat-File-System wie MDX. Beide fügen eine Indirektionsschicht zwischen Daten und Typen ein. Mit TypeScript-Objekten ist das Schema die einzige Quelle der Wahrheit. Ein Feldname umbenennen ist ein Find-and-Replace mit Compiler-Verifikation - keine Datenmigration.

Statisch statt dynamisch. Ein Wiki, das für jede Anfrage einen Server benötigt, ist beim Launch ein Zuverlässigkeitsrisiko. Wenn das Spiel erscheint und der Traffic anschwillt, verarbeitet eine statisch generierte Site hinter einem CDN die Last ohne Autoscaling, Datenbankverbindungslimits oder Cold Starts. Der Kompromiss: Inhaltsupdates erfordern einen Rebuild - bei einem Game-Wiki akzeptabel, da Daten sich vorhersehbar mit Game-Patches ändern.

Turbopack für Entwicklungsgeschwindigkeit. Mit 600+ Routen war der Dev-Server-Start mit Standard-Webpack langsam genug, um den Flow zu unterbrechen. Turbopack bringt den Dev-Server unabhängig von der Eintragsanzahl in unter 3 Sekunden in einen funktionsfähigen Zustand.

Status

Design-System, Datenstruktur und Routing-Architektur sind fertig. Alle 600+ Einträge sind typisiert und validiert. Die Site befindet sich im Pre-Launch-Review bis zum Q2-2026-Erscheinungsdatum des Spiels. Am Launch-Tag bringt ein einziges Deployment das vollständige Wiki live.