Aufgaben von Model, View und Controller in Adventure

[Paratron]

Hi
ich entwickele aktuell an einem Adventure-Spiel und versuche das MVC-Pattern nach besten Gewissen anzuwenden. Jetzt wollte ich mich aber nochmal Rückversichern welche Funktionalitäten von vom implementiert werden sollte (Model View oder Controller). Ich habe nämlich das Gefühl zu viel Verantwortung auf die View zu legen und zu wenig aufs Model.

Also zum Beispiel. Mein Spiel umfasst 2 Screens. Einen Startscreen und einen Spielscreen. Hier erstmal was man so machen kann:

1. Ein Hintergrundbild wird angezeigt. Wenn man mit der Maus zur Seite kommt, scrollt das Hintergrundbild ein Stück.

2. Auf dem Hintergrund-Sprite werden visuelle Komponenten plaziert (Objekte zum Einsammeln).

3. Eine Instanz des Inventars wird angezeigt.

4. Wenn man manche Objekte aus 2.) anklickt wird eine Animation dieser Objekte oder ein Sound abgespielt.

5. Wenn man andere Objekte aus 2.) anklickt werden diese aus der Szene entfernt und stattdessen im Inventar verwaltet.

6. Wenn man wiederum andere Objekte aus 2.) anklickt werden andere Objekte freigeschaltet, d.h. diese Objekte erhalten ebenfalls eine Klick-listener.

7. Beim Klick auf einen Zurückbutton wird ein Event dispatched, dass veranlasst, dass der Startscreen angezeigt wird.

Wo muss welcher Code hin? Also alle visuellen Komponenten instanziiere ich derzeitig in der View, auch wenn diese Objekte (z.b. das Inventar) nicht nur einfach Sprites sind, sondern zusätzlich auch noch andere Methoden, z.b. zum Verwalten von Objekten in einer Liste beinhalten.

Dementspechend registriere ich auch alle Event-Listener in der View. Wo kommen die Listener-Funktionen hin? Ich dachte vll in den Controler, aber es wäre irgendwie unsinnig wenn die Listener-Funktion dann nur eine Animation startet.

Was würde man im Model machen?? Ich könnte mir höchstens vorstellen Status zu speichern ob ein Objekt schon freigeschaltet ist, oder noch nicht??

Hoffe jemand ist so nett mich ein bisschen einzuweisen.
Danke!

[malthoff]

Hallo.
Viel Spass beim Entwickeln des Adventures.
Im Model sollte der anwendungsweite Zustand gespeichert werden. Hat der Inhalt des Inventars über mehrere Views (also mehrere Schauplätze in deinem Spiel) Gültigkeit, dann speichere das im Modell. Gibt es in einer Ansicht eine Funktion, die den Ablauf in einer anderen Ansicht steuern (Betätigen eines Hebels, Ablegen eines Steins auf einer gewichtssensitiven Bodenplatte), speichere diesen Zustand im Model.

Hast Du allerdings nur auf die View bezogene Abläufe innerhalb eines Screens, dann kannst Du den Zustand auch in der View selber speichern - wenn sie keinerlei externe Auswirkung hat. Wenn Du eine Vase anklickst und diese dann vom Tisch fällt sollten die Listener auf die Vase und das Starten der Animation in der View liegen. Dafür braucht es keinen externen Controller oder Mediator, der auf das Event hört und nur wieder die Funktion in der View anstößt.

Generell eine gute Idee ist es, jedem Screen einen eigenen Mediator (Controller) zur Seite zu stellen, der auf Events der View hört, die für das Gesamtsystem von Bedeutung sind. Dieser Mediator kennt dein Model und kann dort die entscheidenden Werte speichern, also das Model beeinflussen. Deine View ist nur mit sich selbst beschäftigt und sendet Events, von denen sie aber nicht weiß, was im System damit passiert.

Nochmal: Hast Du Events, die nur zu Änderungen in der View führen, dann bleiben auch die Listener in der View.

[the binary]

hi..
das gute alte mvc mal wieder..
es gab bereits ausschweifende diskussionen darueber, vielleicht hilft es dir weiter..

oop-anfaengerfragen

gruessle
// b

[Paratron]

Danke ihr zwei. So ähnlich läuft es bei mir auch schon. Allerdings habe ich z.b. für jeden Screen auch ein eigenes Model, was aber schwachsinnig ist. ein "StatusModel" gefällt mir da schon viel besser.