Umsetzung von Forschungs - Effekten

Hi,
in so gut wie jedem BG gibt es Forschungen und/oder Gebäude usw. die z.B die Stärke von Schiffen, Einheiten und was weiß ich noch alles beeinflussen.
Ich bin gerade am Überlegen wie man diese Auswirkungen von was auch immer relativ gut erweiterbar machen kann. Irgendwie stehe ich dazu aber aufm Schlauch, und wollte mal von euch höhren wie ihr das so umsetzt (keine Sorge ich werde es nicht 1:1 umsetzten, macht ja keinen Spaß was zu kopieren, aber ein paar Anregungen wären nicht schlecht).
Damit ihr auch seht, dass ich nicht nur schmarotzen möchte:
Jede Forschung ect. hat eine Eigenschaft (wahrscheinlich über Delegaten umgesetzt, aber das weiß ich noch net so genau), die dann eine "Effekten-Klasse" beeinflusst. Und immer wenn ich dann einen Effekt brauche kucke ich einfach in dieser Klasse nach. Eine andere Variante wäre, jedesmal diese Klasse neuberechnen zu lassen.
Oder man speichert alles direkt im betreffenden Objekt (Schiff, Produktion,...)
Also schreibt wie ihr es macht und was euch daran gefällt/stört!

Ich löse dies über Interfaces. Daher ich mache ein Interface mit einer Methode für den speziellen Effekt (zum Beispiel Gebäudebauzeit manipulieren). Die Methode würde in diesem Beispiel die Bauzeit bekommen und manipuliert wieder zurück geben.
Jeder der diese Zeit manipulieren will, sei es andere Gebäude oder Forschungen etc. hängt sich via eigene Klasse dran, die das jeweilige Interface implementiert. In der Methode kann er dann die Bauzeit beliebig manipulieren.
Da wo ich die Effekte dann benötige hole ich mir von jeder Klasse, die dieses Interface implementiert haben, ein Objekt und kann diese dann benutzen.
Vorteile:

• Die Implementierung der Auswirkung auf die Effekte ist getrennt vom Einsatzort
• Es können beliebg viele Klassen implementiert werden, die diesen Effekt beeinflussen ohne am Ort des Effektes Änderungen machen zu müssen
• Eine Klasse kann auch mehrere Effekte auslösen durch die Implementierung mehrere Interfaces

Nachteile:

• Pro Effekt wird immer ein Interface benötigt und pro Bestandteil, der darauf einwirkt eine Klasse die dieses Interface implementiert

Das Konzept hab ich noch nicht in der Praxis getestet, aber ich denke damit habe ich ausreichende Flexibilität bei Erweiterungen und eine schöne Trennung der Logik.

grrrrrr vergessen zu kopieren, dann halt nochmal in Kurzfassung
Super Idee DrakeL!
Wie machst du das nur wenn z.B. 2 Forschungen die Bauzeit um 10% minimieren? Dann würde die 2. Forschung nur die Bauzeit nach der 1. Forschung um 10% minimieren, aber nicht die Ausgangszeit?
100 Std = Ausgang
90 Std nach Manipulation mit der 1. Forschung (dient als neuer Ausgangswert für 2. Forschung)
81 Std nach 2. Forschung (anstatt der 80)
Außerdem weiß ich nicht, wie ich das implementieren über das Admin-Tool laufen lassen kann (wird dann wohl nicht so einfach möglich sein). Außerdem find ich es etwas doof, dass man auch für jedes Gebäude eine eigene Klasse braucht, bisher war bei mir jedes Gebäude eine Instanz einer Klasse.
Evt. kann man die Interfaces durch Enums (für die "Art" des Effektes, z.B. Bauzeit mininmieren) verbunden mit einer Größe für das Ausmaß (z.B. 10%) ersetzten.
Dabei würden jedoch auch kompliziertere Möglichkeiten (Fallunterscheidungen, ...), die mit den Interfaces einfach möglich sind, wegfallen.
Ich suche also weiter

Original von altertoby
Wie machst du das nur wenn z.B. 2 Forschungen die Bauzeit um 10% minimieren? Dann würde die 2. Forschung nur die Bauzeit nach der 1. Forschung um 10% minimieren, aber nicht die Ausgangszeit?

Da müsstest du den Ausgangswert auch mit übergeben und dir anhand diesem die abzuziehende Differenz berechnen und dann vom aktuellen Wert abziehen.
100h - Ausgang
Erste Manipulation gibt einmal folgendes zurück:
$var1 = 100
$var2 = 90
Bei den folgenden Durchläufen berechnest die Verkürzung mit Hilfe von $var1 und ziehst sie von $var2 ab.

Original von altertoby

Außerdem weiß ich nicht, wie ich das implementieren über das Admin-Tool laufen lassen kann (wird dann wohl nicht so einfach möglich sein). Außerdem find ich es etwas doof
Meinst du damit, das Erstellen neuer Gebäude über dein Admin-Tool?

Original von altertoby

Außerdem find ich es etwas doof, dass man auch für jedes Gebäude eine eigene Klasse braucht, bisher war bei mir jedes Gebäude eine Instanz einer Klasse.
Du könntest das auch weiterhin über Instanzen von einer Klasse lösen. Es würde an sich dann je eine Klasse für Gebäude, Forschungen und ähnliches ausreichen. Jedoch bist du dann etwas beschränkter in den Möglichkeiten, weil du dann mit übergebenen Argumenten auskommen must, um die Zeit zu manipulieren.
Wenn du es so löst ist das ganze aber dann auch nichtmehr abhängig von jeweils einer eigenen Klasse und du hättest dein Problem mit der Adminpanel gelöst.
Von was ist denn bei dir der jeweilige %Satz abhängig? Wenn er von so gut wie nichts abhängig ist würde ich es über eine SQL Tabelle lösen.
Dass du dann beispielhaft die Tabelle Effekte hast, mit u.a. den Feldern ForschungsId, GebäudeId und Prozentsatz.
Dann holst dir an Hand deines Gebäudes und der erforschten Forschungen den summierten Prozentsatz.
Vorteil dabei ist, dass es recht wenig Aufwand ist und du alles direkt in einem Query lösen könntest. Nachteil ist dabei ganz klar, dass du sehr wenig Möglichkeiten hast von sonst was von Abhängigkeiten die Zeit mit zu beeinflussen.

Original von altertoby
...
Ich suche also weiter

War nur ein Beispiel von mir.
Du müsstest dann halt das Interface und die Methode anpassen. Das einzige was bei mir definiert wird ist dass es Interfaces gibt und beliebig viele Objekte von Klassen die dieses implementieren. Die Stelle wo ein Interface benötigt wird können alle vorher hinzugefügten Objekte geholt werden.
Jetzt müsste man nur die richtigen Interfaces und Klassen definieren. Das obliegt der Freiheit der Anwender.