Tower Defense mit .NET Core

Die Projektidee

Für unser CodeCamp haben Basti, Ben und ich uns zusammengefunden, um ein simples Spiel mit .NET Core zu entwickeln. Wir entschieden uns aufgrund der relativ leichten Umsetzung für ein Tower Defense-Spiel auf einem Hex-Grid.

Die Spielregeln von Tower Defense sind schnell erklärt: Jedes Hexagon stellt eine Position auf dem Spielfeld dar. Jeder Spieler hat seine Base auf dem Spielfeld, die es vor den Angreifern des anderen zu verteidigen gilt. Zur Verteidigung werden Türme auf dem Spielfeld platziert, die die Angreifer abwehren. Der Weg der Angreifer wird durch die Zwischenräume zwischen den Türmen definiert. Zwischen den Türmen muss also immer ein Weg frei bleiben.

Die Entwicklung

Das Besondere an unserer Entwicklung war die Verwendung einer Redux-Architektur, die wir normalerweise für unsere Web-Apps im Frontend nutzen. Für das Spiel wollten wir sie erstmals in einem verteilten Szenario einsetzen. Der Server sollte dabei als „Single Source of Truth“ gelten und den Zustand des Spiels verwalten. Die Spiel-Clients hatten so nur noch die Aufgabe, den aktuellen Zustand darzustellen und Aktionen der Spieler an den Server zu senden.

Die Entwicklung der Serverkomponente mit dem noch ganz neuen .NET Core 1.0 habe ich mir als Aufgabe ausgesucht. Mir war dabei wichtig, möglichst viel vom neuen .NET zu lernen, weswegen ich auf eine fertige Server-Bibliothek verzichtet habe. Für die Darstellung des Spiels hat Basti einen Client auf JavaScript-Basis mit Phaser.io umgesetzt. Phaser bietet viele Features, um ein 2D-Spiel umzusetzen, und stand schon länger auf Bastis „will-ich-mal-was-mit-machen"-Liste.

Neben der Programmierung ist gerade bei einem Spiel das Design besonders wichtig. Hier haben wir uns anfangs von Googles Material Design Guidelines inspirieren lassen, aber Ben hat da schnell was ganz Eigenes draus gemacht.

Fazit

Etwas so richtig Spielbares war in der kurzen Zeit nicht zu schaffen. Vor allem, weil wir neue Technologien getestet haben. Der Versuch, die Redux-Architektur auf ein Multiplayer-Spiel anzuwenden, hat mich aber voll überzeugt. Der größte Vorteil an einer solchen Architektur ist, dass man kaum noch verteilte Logik benötigt. Alle anfallenden Events werden zentral auf dem Server abgearbeitet und der neue, als Ergebnis entstandene, Spielzustand wird wieder über das Netzwerk an alle verbundenen Spieler geschickt. Das macht auch die Entwicklung des Clients entsprechend einfach, da dieser für nicht viel mehr als das Rendering zuständig ist.

Der Einsatz von .NET Core war zu diesem frühen Zeitpunkt so kurz nach dem Release eher eine Bremse. Der Kern ist zwar fertig, und damit kann auch schon sehr gut entwickelt werden, aber die vielen Bibliotheken, die man sonst gewohnt ist zu nutzen, fehlen zum großen Teil noch. Mit dem produktiven Einsatz von .NET Core sollte also noch ein bisschen gewartet werden. Ich vermute, dass es im Laufe des nächsten Jahres soweit sein wird, dass es sich lohnt umzusteigen.