Eine einfachere Variante ist es, nicht verschiedene Bots für verschiedene Strategien zu schreiben, sondern die Strategie selbst in einer Klasse zu kapseln und dem Konstructor des Bot eine konkrete Instanz zu übergeben, die er verwenden soll. Damit ließe sich die Strategie sogar während des Spiels wechseln bzw. abfragen oder ihre Parameter ändern. Ich meine — was interessiert die Klasse Bot, wie die Strategie zu ihren Entscheidungen kommt? Die Methode decide bekommt einfach das aktuelle Gebot und liefert bool zurück. Die vergangene Liste kann dann intern gespeichert werden oder nicht. Das gleiche mit Spieler und Bot, beide könnten als Spezialisierungen einer allgemeinen Klasse Mitspieler angesehen werden. Das Spiel bekommt zwei Instanzen dieser Klassen und dann spielen eben auch mal zwei Bots oder zwei Spieler gegeneinander, am Prinzip ändert sich dabei nichts.
Wenn man das ganze weiter treibt, kann man fast alle Eigenschaften der Bots über solche dynamisch hinzufügbaren Komponenten realisieren (Position, Physik, KI, aber auch andere Ressourcen, die mit dem Bot verknüpft sind). Das ganze nennt sich dann CBSE (Component Based Software Engineering) und wird gerade in Computerspielen sehr gerne verwendet um allen Spiel-Entitäten komplexe Eigenschaftskombinationen zuzuweisen, ohne auf umständliche und starre Objekthierarchien wie bei OOP angewiesen zu sein.
Bei größeren Projekten kann das ganz schnell dazu führen, dass der Code unverständlich wird, wenn die Konfigurationen verstreut sind (geht schneller, als man denkt). Außerdem kann es sein, dass man (zur Laufzeit) in verschiedenen Komponenten unterschiedliche Abhängigkeiten braucht. Holt man sich dann die Abhängigkeiten über das Ändern der Konfiguration, kriegen evtl. die anderen Komponenten nicht mehr die Abhängigkeiten, die sie eig. haben sollten. Die Lösung wäre, die Konfigurationen selber wieder zu entkoppeln, was aber auf das ursprüngliche Problem (dass so ein Framwork eig. lösen sollte) hinausläuft. Vor dem steht man dann wieder und hat dazu noch Overhead (durch das Framework).
Um das Problem deutlicher zu machen, überspitz ichs mal:
Das obige Problem ließe sich lösen, wenn man für die entsprechenden Zweige im Code einfach unterschiedliche Konfigurationen einführt. Es kann aber sein, dass ein paar Abhängigkeiten in allen Konfigs gleich sind und auch gleich sein sollen. Tatsächlich hat man dann Abhängigkeiten unter den Konfigs. (ob nur logisch, oder direkt im Code ist egal). Um diese zu Verwalten könnte man wieder das Framework verwenden und schwupps hat man das Problem dupliziert, anstatt es zu lösen. Theoretisch kann man das beliebig oft machen, bis man tatsächlich mal das eig. Problem gelöst hat.
Falls dann mal jemand neues sich mit dem Code befassen soll, wird der einige Nächte nicht mehr ruhig schlafen können.
Man sollte, wenn überhaupt, solche Frameworks wirklich nur mit oberster Vorsicht verwenden und den Einsatz gut durchplanen. Meiner Meinung nach kann man dann auch gleich das Projekt besser planen und den Einsatz solcher Frameworks vermeiden. Halbwegs gute Sprachen bieten ja auf Sprachebene genug Möglichkeiten, z.B. Entwurfsmuster wie aus GoF da einzusetzen, wo sie Sinn machen.
Achja :D Zum ursprünglichen Post: Strategy wäre jetzt auch meine Wahl gewesen
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 13. Apr 2012 um 00:18.
Eine einfachere Variante ist es, nicht verschiedene Bots für verschiedene Strategien zu schreiben, sondern die Strategie selbst in einer Klasse zu kapseln und dem Konstructor des Bot eine konkrete Instanz zu übergeben, die er verwenden soll. Damit ließe sich die Strategie sogar während des Spiels wechseln bzw. abfragen oder ihre Parameter ändern. Ich meine — was interessiert die Klasse Bot, wie die Strategie zu ihren Entscheidungen kommt? Die Methode decide bekommt einfach das aktuelle Gebot und liefert bool zurück. Die vergangene Liste kann dann intern gespeichert werden oder nicht.
Das gleiche mit Spieler und Bot, beide könnten als Spezialisierungen einer allgemeinen Klasse Mitspieler angesehen werden. Das Spiel bekommt zwei Instanzen dieser Klassen und dann spielen eben auch mal zwei Bots oder zwei Spieler gegeneinander, am Prinzip ändert sich dabei nichts.
Man könnte sogar an Metastrategien denken, die die "richtige" zur Laufzeit wechseln bzw. kombinieren.
Wenn man das ganze weiter treibt, kann man fast alle Eigenschaften der Bots über solche dynamisch hinzufügbaren Komponenten realisieren (Position, Physik, KI, aber auch andere Ressourcen, die mit dem Bot verknüpft sind). Das ganze nennt sich dann CBSE (Component Based Software Engineering) und wird gerade in Computerspielen sehr gerne verwendet um allen Spiel-Entitäten komplexe Eigenschaftskombinationen zuzuweisen, ohne auf umständliche und starre Objekthierarchien wie bei OOP angewiesen zu sein.
Das wäre dann das berühmte Strategy-Pattern.
Für eine lose Kopplung würde sich dann als Verbesserung der Einsatz eines IoC-Frameworks empfehlen. Ist ja derzeit der letzte Schrei.
Mit den IoC-Frameworks wäre ich sehr vorsichtig!
Bei größeren Projekten kann das ganz schnell dazu führen, dass der Code unverständlich wird, wenn die Konfigurationen verstreut sind (geht schneller, als man denkt). Außerdem kann es sein, dass man (zur Laufzeit) in verschiedenen Komponenten unterschiedliche Abhängigkeiten braucht. Holt man sich dann die Abhängigkeiten über das Ändern der Konfiguration, kriegen evtl. die anderen Komponenten nicht mehr die Abhängigkeiten, die sie eig. haben sollten. Die Lösung wäre, die Konfigurationen selber wieder zu entkoppeln, was aber auf das ursprüngliche Problem (dass so ein Framwork eig. lösen sollte) hinausläuft. Vor dem steht man dann wieder und hat dazu noch Overhead (durch das Framework).
Um das Problem deutlicher zu machen, überspitz ichs mal:
Das obige Problem ließe sich lösen, wenn man für die entsprechenden Zweige im Code einfach unterschiedliche Konfigurationen einführt. Es kann aber sein, dass ein paar Abhängigkeiten in allen Konfigs gleich sind und auch gleich sein sollen. Tatsächlich hat man dann Abhängigkeiten unter den Konfigs. (ob nur logisch, oder direkt im Code ist egal). Um diese zu Verwalten könnte man wieder das Framework verwenden und schwupps hat man das Problem dupliziert, anstatt es zu lösen. Theoretisch kann man das beliebig oft machen, bis man tatsächlich mal das eig. Problem gelöst hat.
Falls dann mal jemand neues sich mit dem Code befassen soll, wird der einige Nächte nicht mehr ruhig schlafen können.
Man sollte, wenn überhaupt, solche Frameworks wirklich nur mit oberster Vorsicht verwenden und den Einsatz gut durchplanen. Meiner Meinung nach kann man dann auch gleich das Projekt besser planen und den Einsatz solcher Frameworks vermeiden. Halbwegs gute Sprachen bieten ja auf Sprachebene genug Möglichkeiten, z.B. Entwurfsmuster wie aus GoF da einzusetzen, wo sie Sinn machen.
Achja :D
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 13. Apr 2012 um 00:18.Zum ursprünglichen Post: Strategy wäre jetzt auch meine Wahl gewesen
hat einen Namen. Nennt sich Dependency Injection.