spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ja Zero du beschreibst quasi genau das System Habe mich da vielleicht etwas ungünstig ausgedrückt. Ob man jetzt von Aktionen oder Events sprechen möchte, darüber lässt sich sicherlich streiten, wobei ich den Begriff Event ganz passend finde, da es eigentlich mehr beinhaltet als reine Aktionen. Warum das Konzept gegen den Sinn der Objektorientierung gehen soll ist mir nicht ganz klar. Warum soll nicht eine zentrale Schnittstelle vorhanden sein? Es gibt ja auch Entwurfsmuster die genau auf so eine Schnittstelle setzen. Naja aber davon mal abgesehen. Ich versuche wie gesagt das Umzusetzen, was Zero beschreibt. Dabei baue ich jedoch nicht auf das Eventsystem von C# auf. Habe damit relativ wenig Erfahrung und wüsste nicht genau wie ich damit in dem Fall umgehen sollte.

Zitat von »BlueCobold«

2) Ein Sound-Manager registriert sich beim "OnPlay"-Event des Sounds, wenn ein Sound über den Manager erstellt wird. Er wird somit immer per Callback informiert, wenn der Sound abgespielt werden soll und übernimmt das Sampling.

Das ist ja in etwa das was passieren soll. Nur wie du schon sagst ist es relativ "unschön", und aus dem Grund habe ich eine Klasse die alles verwaltet. Dass ich dadurch die Events nicht direkt feuern muss, sondern zuerst speichere, um sie einmal pro Update zu feuern sehe ich auch als Vorteil. Das mit dem Netzwerk war eben nur ein Beispiel. Das System im Netzwerk zum laufen zu bringen ist halb so wild. Das Problem ist vielmehr, dass so ein Eventsystem im Netzwerk sehr unsicher ist. Es sicher umzusetzen ist das Problem Aber davon auch mal abgesehen, da es nur ein Beispiel war.
Das Konzept dahinter kommt größtenteils aus dem Buch "Game Coding Complete" von Mike McShaffry. Vielleicht kennt ja jemand das Buch. Das Design ist bei mir eh noch in der Planungsphase, weshalb ich mich auch gern von Änderungen überzeugen lasse.

Ist auch relativ egal Nein. Über Callbacks würde ich das Problem halt umgehen. Habe heute aber auch nochmal bei der Arbeit mit ein paar Kollegen gesprochen und die wussten auch keine wirklich schöne Alternative. Habe es mal testweise mit den casts umgesetzt. Funktionieren tuts. Werde mal eine Variante mit Callbacks schreiben und danach entscheiden welche mir nun besser gefällt. Trotzdem danke an alle

Edit: Naja und den Vorteil den die Queue mit sich bringt, ist dass Events dann zum einen gepackt werden könnten um sie über das Netzwerk zu versenden, und zum anderen müsste man natürlich nicht alle Events pro Update auch behandeln. Wenn Update mal zu lange braucht könnte man erstmal nur wichtige Events bearbeiten. Wäre mit einer PriorityQueue relativ simpel umgesetzt und man könnte sich ein bisschen Zeit sparen. Dabei muss natürlich gewährleistet sein, dass die Events natürlich alle gefeuert werden und einige nicht einfach wegfallen, weil sie eine zu niedrige Priorität haben, aber dafür gibts ja genügend Konzepte. Zusätzlich müsste man dann natürlich gucken welche Events denn nun überhaupt sofort gefeuert werden müssen, und bei welche verzögert kommen dürfen, aber mir gefällt die Freiheit die ich dadurch habe. Naja wie gesagt ist das erste mal das ich mit so etwas arbeite. Hinterher kann ich ja vielleicht mehr dazu sagen Gruß