spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich kann mich LetsGo nur anschließen: Man sollte ein bestimmtes Design Pattern nur dann verwenden, wenn es der gegebene Fall erfordert bzw. wenn die gegebene Problemstellung sich damit einfacher realisieren lässt.
Allerdings könnte es auch sein, dass Dude keinen besonders guten Überblick über die vorhandenen DesignPattern hat. Sollte das der Fall sein, wäre es gut, sich diverse Pattern mal allgemein, unabhängig vom Strategiespiel, anzusehen, um beim Umsetzen dann zu wissen, ob sich ein Design Pattern anbietet, welches man sich mal angeguckt hatte.

Da man für eine Problemstellung ein passendes Design Pattern finden kann, sollte man sich erstmal über die Probleme Gedanken machen (was wohl besser gehen dürfte, wenn man mit der Umsetzung angefangen hat).
Ein Beispiel wären dabei die Einheiten. Diese könnte man entweder (Codeseitig) in einer Vererbungshierarchie unterbringen oder ihnen über ein Komponentensystem ihre Eigenschaften zuweisen. Was in deinem konkreten Fall besser ist, kann ich nicht grundsätzlich sagen, da solltest du einfach mal mit beiden Möglichkeiten rumprobieren.
Eine andere mögliche Problemstellung könnte es sein, dass es verschiedene Schadensarten gibt, gegen die es unterschiedliche Arten von Verteidigungen gibt und die Kombinationen (ein Angriff einer bestimmten Art gegen eine Verteidigung einer bestimmten Art) liefern eine unterschiedliche Effektivität. Wie sollte die Effektivität eines Angriffs ermittelt werden? Wo im Code (Angreifer oder Verteidiger?) sollte dies stattfinden?
Ein weiteres Problem dürften die unterschiedlichen Unterfrünge darstellen, auf denen sich vlt. nicht jede Einheit bewegen kann oder auf der eine Einheit langsamer wird. Das ist aber nur dann relevant, wenn es in deinem Spiel enthalten sein soll.

Und damit nicht bereits am Anfang ein zu großer Aufwand in eine Mod-API gesteckt wird, deren Nutzen (in dieser Form) sich nur schwer einschätzen lässt, solltest du dir darum erstmal keine Gedanken machen und ein Strategiespiel ohne Modifizierbarkeit entwickeln.

Zum Thema Patterns wurde ja eigentlich schon alles wichtige gesagt. Patentrezepte gibts da nicht und ja, man könnte das so machen wie du vorschlägst, das hängt dann aber vom Rest deines Codes ab. Design Patterns machen eben nur Sinn wenn sie in dein restliches Design passen. Das kennen wir nicht also können wir nur raten. Ich könnte dir vermutlich für ziemlich viele Design Patterns Beispielanwendungsfälle in Strategiespielen geben. Das heißt aber nicht dass die am Ende auch alle sinnvoll sind. Lieber einfach erst mal entwickeln und dann gucken was sinn ergibt. Was die Erweiterbarkeit angeht, da macht es sinn wenn du die grundlegenden Komponenten deines Spiels in einer "normalen" Sprache deiner Wahl schreibst und die veränderbare Spiellogik etc in eine Skriptsprache auslagerst. Für mich hört es sich aber grad ein wenig so an als wenn dich das ganze noch etwas überfordern würde. Möge ich mich aber vielleicht auch irren. Eine einfache Möglichkeit für Mods kann man schon schaffen wenn man einfache Werte in Textdateien auslagert. Zum Beispiel Werte für Einheiten. Eine Datei könnte so aufgebaut sein:

Das sind nur einige Werte. Möglicherweise beitet es sich auch an XML, JSON oder irgendein anderes Format für die Dateien zu wählen. Nur je einfacher, desto einfacher kann es ein Laie erweitern. Eine Fähigkeit könnte hier auch wieder ein Pfad zu einer Datei sein welche die Fähigkeit beschreibt. Diese Datei speichert dann den Namen, die Textur und was halt so benötigt wird. Das was die Fähigkeit auslöst könnte dann entweder durch einfache Stichworte beschrieben werden, oder durch den Verweis auf ein auszuführendes Skript. Hier kann man halt wieder beliebig komplex werden. Für den Anfang würde ich es erst mal einfach halten damit du selbst den für dich besten Weg findest. Danach kannst du das ganze immer noch erweitern.

Erweiterbarkeit war für mich in meinem aktuellen Projekt auch wichtig. Ich wollte für mein TD Spiel die Möglichkeit offen halten Waffen und Gegner ohne das Projekt zu kompilieren einzubauen. Da ich schon einmal mit XML Dateien probiert hatte wollte ich XML nutzen, mir wurde dann Linq ans Herz gelegt (C#). Umgesetzt hab ich das ganze bisher so:



Die XML wird ausgelesen, Buttons werden in eine Liste geladen und eine Instanz für die jeweilige Waffe. Wenn man den Button für eine Waffe klickt wird die Waffe im Turm gespeichert




Das selbe Prinzip hab ich für Gegner benutzt

In meinem ersten Strategiespiel habe ich alles ohne jemals irgendwas von Designpatterns gehört zuhaben, programmiert. Es hat auch getan. Versuch nicht overengineering zu betreiben. Klar helfen Designpatterns und erzeugen richtig eingesetzt schöne Lösungen, aber letzten Endes willst du ein Spiel machen und solange keine anderen an den Code ran sollen, oder das Spiel erweitern sollen, helfen auch einfache Ansätze ohne Designpatterns.
Du hast zwar geschrieben, dass das Spiel einfach erweiterbar sein soll und der Code gut strukturiert und lesbar sein soll. Allein Designpatterns nehmen dir das aber nicht ab. Auf die Erweiterbarkeit würde ich im Zweifel erstmal verzichten, sondern schauen, dass du dein Spiel erstmal fertig bekommst.
Sorry wenn ich etwas pessimistisch klinge, aber ich habe in den Jahren schon so viele Projekte kommen und gehen sehen (meine eingeschlossen ), dass ich denke, dass zu oft das Spiel von der falschen Ecke angegangen wird.
Und in letzter Konsequenz kann man kleine Spiele(wozu ein RTS jetzt nicht gerade gehört) auch nach dem Konzept "Coding without Concept" entwickeln. Gute, kleine Beispiele dafür gibt es.

P.S.: Mein erstes Strategiespiel war zwar spielbar, wurde aber nie fertig. Das lag aber nicht daran, dass ich keine Designpatterns verwendet habe, sondern eher an dem HD-Crash, der mir den Code gekillt hat. Tja hätte ich damals schon mal über Backups nachgedacht.