Beste möglichkeit statistiken aufzunehmen

Hi!

Ich habe ein einigermaßen fortgeschrittenes Spiel geschrieben und möchte nun Statistiken aufnehmen. Darunter z.B. wie oft ein Level gespielt wurde, wie oft ein Spieler was gemacht hat etc. .Da die Datenerhebung für die Statistik sich nun über viele Klassen und Ebenen erstrecken würde, wie löse ich das am besten(Strukturell)?

Kann natürlich auch noch mehr ins Detail gehen, müsste aber wissen was sinnvoll ist zu erwähnen.

Danke!

MfG
Dudeldu

Th69

Mit welcher Programmiersprache? Generell würde ich dann wohl das Observer-Pattern einsetzen (in C# beispielsweise mittels Events).

Ich verwende Flash ActionScript 3. Ich werde mir dann erstmal den Artikel anschauen.

hustbaer

So etwas über das Observer Pattern zu lösen ist zwar vielleicht gutes Design (vielleicht aber auch nicht) -- auf jeden Fall aber eher mühsam.
Die Arbeit die man damit bei der Implementierung (und auch bei Änderungen) oft hat wiegt nach meiner Erfahrung oft schwerer als die Vorteile die man durch "Flexibilität" und "schwache Kopplung" bekommt. (Jetzt nicht grundsätzlich, sondern speziell bezogen auf das Observer Pattern bei solchen oder Ähnlichen Vorhaben.)

Ich würde eher in die Richtung denken:

Klasse/Interface basteln die/das für die Erfassung von Statistikdaten zuständig ist. Das Ding hat dann für alles Mögliche Memberfunktionen, also NotifyXOccured , NotifyYChanged , NotifyZShown etc.

Und dann einen möglichst einfachen Mechanismus schaffen wie dieses Ding allen Objekten zugänglich gemacht werden kann die da Daten reinstecken können müssen. Kann ein Singleton sein (pfui), kann Teil des "Game" Objekts sein, Teil des Player Objekts -- irgendwo passt es schon rein. Wenn man das Service Locator Pattern bzw. ein Derivat davon verwendet vermutlich dort.

Und die einzelnen Objekte rufen dann einfach die Entsprechenden Notify/Track Funktionen der Statistikdatenerfassungsklasse auf. Dort wo die Information entsteht, ohne weiteren Umweg über Signals/Observer/... .

Was die konkreten Details angeht kann man erst mehr dazu sagen wenn man das Projekt etwas genauer kennt.

Th69

Worin siehst du jetzt einen Unterschied zwischen deiner und dem generellen Observer-Pattern (auch dieses ist eine schwache Kopplung)? Ich meine natürlich nicht die Java-Lösung mittels Vererbung!
Für ActionScript 3 würde ich wohl Introduction to event handling in ActionScript 3.0 verwenden...

Th69 schrieb:

Worin siehst du jetzt einen Unterschied zwischen deiner und dem generellen Observer-Pattern (auch dieses ist eine schwache Kopplung)? Ich meine natürlich nicht die Java-Lösung mittels Vererbung!
Für ActionScript 3 würde ich wohl Introduction to event handling in ActionScript 3.0 verwenden...

Mit Observer Pattern muss man jetzt lauter neue Methoden in alle Klassen einbauen damit man sich für alle möglichen Signal subscriben kann. Dann muss man auch noch immer schauen, dass das Ding das die Statistik erstellen soll sich bei allen Klassen subscribt, wenn diese erstellt werden. Wenn das Design nicht von Anfang an dafür ausgelegt war, kann das ganzschön aufwendig werden.
Da kann globaler Logger deutlich einfacher sein, vorallem wenn man weiß, dass man nicht mehr viel an dem Game ändern wird.

hustbaer

@Th69
Was drdrplease geschrieben hat ist schonmal ein für mich wichtiger Punkt: Grosse Mengen an Boilerplate-Code. Und wenn ich *nix* davon habe, dann schreib' ich die nicht.

Ein weiterer Punkte den man auch nicht ganz vernachlässigen sollte: man dreht hier etwas um - es kommt zu einer "Inversion of Control".
Das ist zwar oft eine Gute Sache (tm), aber eben nicht immer.

Bei meiner Variante entscheidet z.B. das Spiel (oder Spiel-Objekt - z.B. Gegner, Spieler, ...) wann genau die "Schreib das in die Statistik" Funktion der Statistik-schreibe-Klasse aufgerufen wird.
Also welche Dinge vorher gemacht werden und welche danach.
Weiters kann man davon ausgehen dass die Funktionen der Statistik-schreibe-Klasse niemals Funktionen des Spiels oder von Spiel-Objekten aufrufen wird -- ausser vielleicht ein paar blöde Getter-Funktionen.
Der stats->NotifyXYZ(...) Aufruf ist also fast so unproblematisch wie ein printf(...) .

Sobald man Observer oder Events verwendet ändert sich hier einiges.
Ich gehe mal davon aus dass es kaum Sinn macht Observer oder Events zu verwenden, wenn man nicht vor hat auf wenigstens einige dieser Events auch in anderen Klassen zu reagieren.
D.h. das Event-sendende Objekt hat keine Kontrolle mehr darüber in welcher Reihenfolge andere Objekte benachrichtigt werden.
Das kann dann dazu führen dass Dinge in der falschen Reihenfolge passieren.
Was ein generelles Problem von "wir verdrahten lusitg Events" ist.
(Im schlimmsten Fall baut man damit Rekursionen, und das ganze Spiel hängt sich weg. Bzw. im noch schlimmeren Fall läuft alles durch bloss das Ergebnis stimmt nicht mehr.)

Wenn die Statistiken der Statistik-schreibe-Klasse ausreichend "dumm" sind wird das vermutlich egal sein, aber Argument für Observer/Events sehe ich darin auf jeden Fall keines.

Davon abgesehen finde ich im Moment keine guten Argumente - es sagt mir einfach nur mein Bauch "mach das lieber nicht so"