spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das ist dann möglicherweise einer der Fälle, wo man tatsächlich Objekte dynamisch anlegen musst. Die Frage ist dann aber wieder, ob man nun tatsächlich eine Factory braucht, die den Besitz abgibt. Man könnte auch hinter dem Factory Interface einen Container befüllen und evtl. macht es sogar Sinn, den Besitz bei der "Factory" zu lassen!? Ich persönlich verwend jedenfalls relativ selten traditionelle Factories. Der Builder Pattern wird imo viel zu gerne übersehen, zumindest für mich hat der sich, im Gegensatz zur Factory, als einer der nützlichsten Pattern überhaupt herausgestellt...

Zitat von »dot«

Zitat von »BlueCobold«

Alle erzeugten Objekte sollen in denselben Container, der nur ihren Interface-Typ, aber nicht die konkrete Implementierung kennt.

Das ist eine Mögliche Lösung, aber eben nicht die einzige. Ich sehe keinen zwingenden Grund, wieso hier alle Objekte unbedingt in den selben Container müssen!?

Weil es Schwachsinn ist, wenn man 20 Container für 20 verschiedene NPC-Implementierungen hat?
Es geht auch gar nicht um eine Factory, sondern eben darum, dass jeder spezielle Untertyp seine eigene Parse-Methode hat statt eine gigantische mit Spaghetti-Code zu produzieren. Da kommt dann jeweils eine konkrete Implementierung als Objekt bei raus und zurück. Schon so gesehen eine Art von Factory, aber ich stelle mir unter einer Factory üblicherweise etwas leicht anderes vor. Ich weiß jetzt aber noch immer nicht, wie man die Objekte wohl auf dem Stack so erstellt, dass sie trotzdem nur per Interface in den Container gepackt werden können.

Die Objekte würden natürlich in den Containern erstellt und nicht auf dem Stack. Ich behaupte auch nicht, dass dies die einzig wahre Lösung sei, hat alles seine Vor- und Nachteile. Ich beobachte nur, dass ich wirklich extrem selten tatsächlich einzelne Objekte auf dem Heap anlegen muss...

Zitat von »BlueCobold«

Weil es Schwachsinn ist, wenn man 20 Container für 20 verschiedene NPC-Implementierungen hat?

Nicht unbedingt, oft ist es sogar von Vorteil. Wenn ich beispielsweise schnell mal über alle Instanzen einer bestimmten Art von NPC iterieren will, kann ich das so einfach, natürlich und effizient lösen. Wenn ich eine Liste mit Zeigern auf alle polymorphen NPC Objekte brauch, kann ich die immer noch machen. Hätte ich nur diese Liste, bräuchte ich nun Double Dispatch oder gar dynamic_cast...

Zitat von »dot«

Die Objekte würden natürlich in den Containern erstellt und nicht auf dem Stack.

Das heißt aber natürlich auch, dass die Methode, die die Objekte erstellt, schon wissen muss, in was für einem Container sie mal landen sollen. Das finde ich sehr ungünstig bis schlecht.

Zitat von »dot«

Nicht unbedingt, oft ist es sogar von Vorteil. Wenn ich beispielsweise schnell mal über alle Instanzen einer bestimmten Art von NPC iterieren will, kann ich das so einfach, natürlich und effizient lösen. Wenn ich eine Liste mit Zeigern auf alle polymorphen NPC Objekte brauch, kann ich die immer noch machen. Hätte ich nur diese Liste, bräuchte ich nun Double Dispatch oder gar dynamic_cast...

Auch wenn du mit der einfacheren Iteration Recht hast, habe ich noch nie gesehen, dass jemand so einen Unsinn von Code verzapft und zwei Dutzend verschiedene Container erstellt. Das klingt für mich einfach kontraproduktiv. Dann auch noch mehrere zu verwalten, damit ich auch noch über alle gleichzeitig iterieren kann, das macht den Code zu wahren If/Switch-Hölle.

Zitat von »BlueCobold«

Dann auch noch mehrere zu verwalten, damit ich auch noch über alle gleichzeitig iterieren kann, das macht den Code zu wahren If/Switch-Hölle.

Wüsste nicht, wieso man da nun eine "If/Switch-Hölle" brauchen sollte. Bleiben wir beim Beispiel mit den NPCs. Was für Arten von NPC soll es denn geben und wer genau besitzt welchen NPC?

Boar, was weiß ich. Die World besitzt die NPCs. Es gibt Händer, Guardians, Minions, fliegende, laufende, schwimmende, ... sagen wir auch, dass ein NPC in den (logischen) Besitz eines Spielers übergehen kann durch zähmen, anheuern, Quests, whatever.
Alle NPCs können attackiert oder anvisiert werden und die Optionen mit den NPCs zu agieren sind somit unterschiedlich und ihre Fähigkeiten wirken sich auf andere Zielgruppen aus. Ich kann mir nicht vorstellen, dass irgendein Entwickler da anfangen will für diesen Quatsch mehrere Container zu führen. Das ist schlicht Unfug.

Wir auf der Arbeit stellen unsere Container darauf um. Der Aufwand vom Dispatching war schlicht astronomisch geworden; das Hangeln durch die Klassenhierarchien beim Debugging eine Qual und in jeder Schleife standen zig Ausnahmen ("jetzt über alles iterieren außer Lichter, Kameras, unselektierte Objekte, und Objekte des Typs C").

Der Knackpunkt ist, auch einen Container für das anzulegen, was normalerweise in die Basisklasse wandert. Im Falle deiner NPCs hättest du die Basisdaten wie Position und Name in einem Container, und jeder Eintrag verwies zusätzlich auf einen der anderen Container, in denen die laufenden oder fliegenden Eigenschaften gespeichert sind. Die laufenden verwiesen wiederum auf Container speziell für Menschen, Orks, usw; die fliegenden auf Container für Drachen, Engel, blabla.

Wenn du Physik auf alle NPCs auf einmal anwenden willst, kannst du das weiterhin mit einem einzigen for-each über deinen Basis-Container tun. Wenn du Drachen mit Orks interagieren lassen willst, lässt du in einem geschachtelten for-each deinen Drachen-Container gegen deinen Ork-Container antreten. Der entstehende Quelltext ist geradezu banal, und deutlich einfacher nachvollziehbar als das Dispatching durch virtuelle Funktionen, die dann nicht nur den Fall Drache-Ork behandeln müssen, sondern auch Ork-Drache. Wenn man es richtig gemacht hat kann man die Drache-Ork-Interaktion dann sogar über die öffentliche Schnittstelle der beteiligten Typen abrollen an der Stelle wo die Interaktion benötigt wird – und nicht in der Klasse –; der Typ Drache braucht also nicht mehr den Typ Ork zu kennen bloß weil die Spielmechanik 100 km weit weg will, dass sich die beiden anpöbeln (was die Abhängigkeiten stark vereinfacht und den Quelltext reduziert).

Hatte ich mir gerade mal reingezogen: