Softwarearchitektur

Den Softwareaspekt mal außen vorgelassen, so weckt der Begriff „Architektur“ doch gewisse Vorstellungen in uns. Der Architekt – hochgebildet und erfahren – plant und entwirft Bauwerke nach praktischen und ästhetischen Gesichtspunkten und überwacht die korrekte Ausführung. Doch so sehr sich die Konstruktion von Bauwerken und die von Software auf den ersten Blick ähneln mögen und so sehr sich entsprechende Metaphern aufdrängen, so gibt es doch insbesondere einen entscheidenden Unterschied: Bauwerke sind vorwiegend statisch. Es sind Immobilien (lateinisch im-mobilis ‚unbeweglich‘). Software ist soft, weich, veränderbar. Und so sehr man sich auch einbilden mag, den Use Case zu kennen, allein das Wissen um diese Veränderbarkeit sorgt dafür, dass stets Bedarf für Veränderung gefunden wird.

Dies gilt umso mehr für Entwicklung von Videospielen. Hier ist das Ziel der Spielspaß, der schwer zu messen und höchst subjektiv ist. Im Folgenden sollen einige wichtige Grundsätze vermittelt werden, jedoch immer unter der Prämisse, dass diese abhängig vom Team und vom konkreten Produkt angepasst und ignoriert werden dürfen.

Der Nutzen guter Architektur

Gute Architektur ist kein Selbstzweck! Es geht nicht darum, möglichst viele Design Patterns zu verwenden. Um nochmals die hinkende Metapher zum Bau zu ziehen: Gebäude sollen ihren praktischen Nutzen erfüllen (Schutz bieten und das Leben erleichtern) sowie ästhetischen Anforderungen genügen (gut aussehen und sich in die Umgebungsbebauung einfügen2). Was heißt das für Software? Hier ist der tatsächliche Code meist vor dem Endanwender verborgen. Funktionale Software kann also durchaus mit schlechter Architektur gelingen. Die wahren Nutznießer guter Architektur sind also die Entwickler selbst. Eine gute und „ästhetische“ Architektur erleichtert die Entwicklung, vor allem in den Aspekten:

• Verständnis vorhandener Funktionalität
• Veränderungen vornehmen
• Testen

Und eben diese Aspekte nehmen die meiste Zeit in Anspruch, je größer ein Softwareprojekt wird.

Besonderheiten bei der Entwicklung von Videospielen

Videospiele nehmen in der Softwarewelt eine Besonderheit ein. Nicht nur technologisch, da unterschiedlichste Subsysteme in Echtzeit zusammenarbeiten müssen. Auch die Entwicklung ist davon geprägt, dass es sich um an sich um ein verbrauchbares Konsumgut handelt (die meisten Videospiele hat man irgendwann ausgespielt). Entsprechend unwichtiger ist langfristige Wartbarkeit, da sich der Lebenszyklus des Spiels kaum vorhersehen lässt. Dies äußert sich natürlich auch in der Architektur:

• Auf Applikationsebene (also der Code, der unmittelbar für das Spielgeschehen verantwortlich ist) möchte man flexibel bleiben. Hier muss es nicht immer hübsch und korrekt zugehen. Man möchte schnell herausfinden ob Dinge funktionieren und ob es Spaß macht.
• Auf Ebene der Engine selbst (betrifft Monogame, aber auch eigene spezifische Funktionen) sollte Stabilität im Vordergrund stehen. Damit ist nicht zwingend gemeint, dass der Code nicht verändert wird. Vielmehr geht es um das Interface und die Funktionsweise. Niemand will schließlich, dass neue Elemente plötzlich an den Anfang statt ans Ende einer Liste gehangen werden. Mehr als sonst lohnt sich hier die Beachtung der CleanCode Prinzipien.

Jedoch ist auch hier der Übergang fließend. Gerade Datenstrukturen (z.B. ein Quad-Tree) sollten definitiv so stabil wie möglich sein und entsprechender Aufwand rentiert sich durchaus. Sollten im Spiel viele verschiedene Einheitentypen vorkommen, ist die Nutzung von Design Patterns ebenfalls zu empfehlen, damit diese ohne viel Copy&Paste implementiert werden können. Einmalige Spezialfähigkeiten hingegen können auch gerne mal schnell reingepfuscht werden. Das wichtigste Clean Code Prinzip „Don‘t repeat yourself“ (DRY) darf also im Videospielbereich durchaus ab und zu ignoriert werden.

Vorsicht! Anforderungen ändern sich. Anfangs mögen z.B. wenige Einheitentypen geplant sein und entsprechend wird das irgendwie zurechtgehackt. Doch irgendwann wird doch beschlossen, dass man mehr möchte und dann werden Veränderungen schwierig. Ob und wo sich die Anforderungen verändern, lässt sich jedoch kaum vorhersehen.

Referenzen

• Amy Brown, Greg Wilson, editors. The Architecture of Open Source Applications. Volume I and II. 2014. https://www.aosabook.org