DevLog #3 — Das OS bekommt ein echtes Betriebssystem

Von Einzelfenstern zum System

DevLog #2 hat gezeigt, dass einzelne Fenster oeffnen und schliessen funktioniert. Aber ein Betriebssystem ist mehr als eine Sammlung von Popups. Es ist ein System — und Systeme brauchen eine Architektur.

EPIC_015 ist diese Architektur.

Das Problem mit manuellem Wiring

Jede neue App im In-Game-OS braucht Zugriff auf denselben Satz von Managern: TimeManager, JobManager, PlayerStatsManager. Ohne ein durchdachtes Setup bedeutet das: Jede neue Klasse sucht manuell ihre Abhaengigkeiten im FindObjectOfType-Chaos.

Das skaliert nicht. Bei fuenf Apps noch handhabbar. Bei zwanzig Apps — ein Wartungsalptraum.

Die Loesung: Self-Wiring Architecture. Jede App-Klasse erbt von einer gemeinsamen Basisklasse OSApp, die beim Awake() automatisch alle notwendigen Referenzen injiziert. Neue Apps melden sich selbst bei einem zentralen AppRegistry an. Kein manuelles Verdrahten mehr.

Die Taskleiste als Herzschlag des OS

Das sichtbarste Element aus EPIC_015 ist die Taskleiste. Sie ist nicht nur Dekoration — sie ist der einzige persistente UI-Layer der immer sichtbar bleibt, egal welche App gerade im Vordergrund laeuft.

Technisch heisst das: Die Taskbar lebt auf einem separaten Canvas mit hoechster Sort-Order. Sie kennt alle registrierten Apps ueber den AppRegistry und aktualisiert ihre Icons per Event — nicht per Polling. Energie und Gesundheit werden in Echtzeit angezeigt, ohne dass ein Tick-System staendig den Zustand abfragt.

Das klingt nach einem Detail. Aber es ist der Unterschied zwischen einem UI das sich traege anfuehlt und einem das sofort reagiert.

Das Fenstersystem unter der Haube

Jedes App-Fenster in RiverTycoon folgt jetzt einem einheitlichen Chrome-Standard:

AppWindow.cs
├── TitleBar (Drag-Handle, App-Name, Close-Button)
├── ContentArea (Injizierter App-Content per Prefab)
└── WindowManager-Registration (Z-Order, Focus, Minimize)

Der WindowManager verwaltet alle offenen Fenster als Stack. Klick auf ein Fenster bringt es in den Vordergrund — SetAsLastSibling() auf dem Canvas, plus ein visuelles Highlight auf der Titelleiste. Kein Fenster kann ausserhalb des Bildschirms gezogen werden (RectTransform.Clamp gegen die Screen-Bounds).

Was das fuer den Spieler bedeutet

Noch keine neuen Inhalte in diesem Sprint. Aber das OS faengt an, sich wie ein echtes OS anzufuehlen:

• Du klickst auf ein Taskbar-Icon. Das Fenster oeffnet sich an einer sinnvollen Position.
• Du ziehst es woanders hin. Es bleibt dort.
• Du oeffnest eine zweite App. Beide existieren gleichzeitig.
• Du klickst auf die erste. Sie kommt nach vorne — sofort, ohne Verzoegerung.

Das ist kein Feature. Das ist Infrastruktur. Aber Infrastruktur die sich gut anfuehlt, macht den Unterschied ob ein Spiel polished wirkt oder nicht.

Der technische Schuldenberg den EPIC_015 tilgt

Solo-Entwicklung bedeutet: Man baut schnell, und manchmal baut man falsch. EPIC_015 war zu einem Drittel neues Feature — und zu zwei Dritteln Refactoring.

FindObjectOfType wurde in acht verschiedenen Klassen durch saubere Injection ersetzt. Drei redundante Canvas-Komponenten zusammengefuehrt. Der AppRegistry ersetzt ein halbfertiges, event-loses Notiz-System das ich in EPIC_014 provisorisch zusammengebaut hatte.

Refactoring-Sprints fuer ein Hobbyprojekt sind schwer zu rechtfertigen. Aber ohne EPIC_015 waere jeder folgende EPIC doppelt so aufwendig gewesen.

Was als naechstes kommt

Das OS steht. Jetzt bekommt es Inhalt.

EPIC_016 bringt das erste System das der Spieler aktiv benutzt: die 24-Stunden-Uhr und das Liefersystem. Damazon Crime klingelt an der Tuer. Das Essen kommt. Die Zeit laeuft.

Pixel River Studio · Solo Indie Dev · Horb am Neckar, Baden-Wuerttemberg Stack: Unity 6 · URP · C# · Canvas Architecture · Eleventy · Netlify