spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Naja meine Eventbeispiele waren nicht so dolle Sollten nur dumme Beispiele sein. Das ganze System dahinter habe ich aus mehreren Büchern zusammengesetzt. Zum Teil wird es mal mit irgendwelchen Nachrichten gelöst und zum Teil halt mal über Events. Die Codes dazu waren bis jetzt immer in C++ weshalb ich noch garnicht drüber nachgedacht habe da mit den C# eigenen Events zu arbeiten. Aber darum gehts auch erstmal nicht Der EventManager macht für mich insofern Sinn, als dass ich dadurch eine gut erweiterbare Basis besitze. Dazu aber gleich mehr. Wenn ich zum Beispiel eine Viewklasse habe, sollte diese natürlich auf so gut wie alles reagieren. Zum Beispiel würde bei einem Schuss ein Sound abgespielt. Dazu vielleicht noch ein Partikelsystem. Zusätzlich müsste bei dem Event natürlich ein Objekt für den Schuss erzeugt werden. Wären 2 kleine Beispiele für Klassen die es interessieren würde über so etwas informiert zu werden. Wenn ich jetzt den Methodenaufruf direkt einbaue, dann müsste bei jedem Schuss jede Klasse informiert werden, die sich dafür interessieren könnte. Das könnte man dann natürlich über einen einfachen Observer regeln, dafür müsste dann jedoch jede Klasse die sich dafür interessiert die Klasse kennen, die den Schuss auslöst. Da diese Klassen sich natürlich für mehrere "Events" interessieren wären dadurch unschöne Abhängigkeiten drin. Vorallem eine Viewklasse müsste zu viel über andere Klassen wissen. Der weitere Vorteil ist, dass wenn die Steuerung etc über diese "Events" geregelt wird, eine Netzwerkkomponente relativ einfach zu implementieren ist. Ob ein Event nun von einer lokalen Komponente oder aus dem Netzwerk kommt, ist ja erstmal völlig egal. Zusätzlich habe ich dann durch die Queue im Eventmanager den Vorteil, dass nicht jedes Event direkt gesendet werden muss, sondern einmal pro Zyklus die alles gepackt werden kann und gesendet wird. Der Eventmanager bietet zusätzlich eine Schnittstelle, um alle Events und somit den gesamten Workflow zu loggen, was meiner Meinung nach auch sehr von Vorteil ist. Für mich sind die Vorteile von einer Schnittstelle für die Events doch recht klar. Lasse mich aber auch gerne von anderem Überzeugen.
Also vom Prinzip:

Objekt sendet Event an EventManager.
EventManager löst einmal pro Zyklus alle enthaltenen Events aus und benachrichtigt für jedes Event die registrierten Eventlistener.
Die Eventlistener verarbeiten die Events weiter und reichen sie an die untergeordneten Objekte weiter.

Meiner Meinung nach ein sehr lose gekoppeltes System, mit großem Potential zur Erweiterung. Das sollte das meiste geklärt haben.

Habe grad nochmal die Posts überflogen. Zero beschreibt das Problem ganz gut. Beim registrieren sollen nicht alle Sender bekannt sein. Ich melde mich lieber beim EventManager an und bekomme dann die gewünschten Events und mir ist egal woher. Ein Event kann ja von verschiedenen Sendern die teils auch verschiedene Typen haben kommen. Und natürlich werden nicht bei jedem Event alle Listener benachrichtigt, sondern nur die die sich für das Event eingetragen haben. Sowas wie EventManager(Listener, EventType) mit dem der Listener sagen kann, dass er bei allen Events von diesem Typ benachrichtigt werden will. Ich denke der Manager ist schon recht Sinnvoll. Nach ein wenig Überlegung zu den Callbacks fällt mir jedoch keine Sinnvolle Möglichkeit ein, diese zu benutzen. Ist zugegeben auch ein Thema, mit dem ich mich bis jetzt wenig auseinandersetzen musste. Aber sollte so in das System schwer zu integrieren sein. Naja mal abwarten. Vielleicht habt ihr ja noch die Idee