spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Check. Du verschiebst also einfach die Logik und die dazugehörenden Werte eine Schicht weiter. Den Ansatz habe ich so noch nicht benutzt. Bei mir waren Controller bis jetzt immer eine Schicht über den Models. Der Controller hatte also zum Beispiel einen Spieler und nicht anders herum. Ist aber ein interessanter Ansatz und wenn ich Zeit habe werde ich das ganze mal testen.

Ist gerade bei Rollenspielen eigentlich üblich, weil dort viele Eigenschaften eines Chars durch komplexe Kalkulationen durch die Items, Buffs und Basis-Eigenschaften der Spieler berechnet werden.

Man lernt ja nie aus Wie würdest du denn in dieses Design andere für den Controller benötigte Objekte integrieren. Als Beispiel wieder der MoveController. Der Spieler hat nun diesen MoveController. Für die Kollisionserkennung müsste dieser ja die Map kennen. Würdest du die Karte dann jedes mal als Parameter über den Spieler an den Controller weiterreichen? Normal würde es ja sinnig sein. Dadurch könnte man die Map auch schön austauschbar halten. Oder würdest du die Map dann als Member in den Controller stecken? Andernfalls könnte der Controller natürlich auch ein Objekt kennen, welches ihm die aktuelle Map etc geben kann. Wie setzt du das im Normalfall um? Werde mich nach den letzten Klausuren mal dran setzen und das Konzept selbst ausprobieren. Wirklich sinnvoll und scheint auf den ersten Blick vieles zu vereinfachen.

Spiel 1: Der Controller kennt die Map nicht, alle Kollisionen werden durch Spielelemente vorberechnet und zu den Zeitpunkten gehandhabt. Geht natürlich nicht überall.

Spiel 2: Der Controller kennt die Map nicht, da nur Kollisionen relevant sind, aber kein Pathfinding. Kollisionen werden hier extern berechnet. Jeder Controller bietet dafür über seine Animation eine Menge von Bounding-Boxen und Bounding-Maps an.

Spiel 3: Die Map blendet in ihrem Script-Scope die notwendigen Funktionen ein, die der Code des Scripts dann verwendet. Im Quellcode kennt der Controller die Map daher noch immer nicht, sie ist aber im Scope ein Owner in der Kette und tiefer im Baum hängt das Objekt mit seinem Controller. Schwer zu erklären, komplexer Aufbau. Jedenfalls kann das Script des Controllers auf gewisse Funktionen der Map zugreifen, weil sie alle Scripte untergeordneter Elemente besitzt. Die Besitz- und Zugriffsverhältnisse kann man sich vielleicht vorstellen wie ein Stück C-Code:

Ist nur ein abstraktes Beispiel, die Aufrufe und Properties sehen natürlich anders aus, auch die Erstellung der Berechnung der Bewegung erfolgt per Klicks im Editor, nicht per Script-Code (oder programmatisch im Game-Code basierend auf Tasteneingaben, etc).
Der Kern des Beispiels ist: p kann auf m und g zugreifen, m kann auf g zugreifen. Innerhalb des Spiel-Quellcodes kennt p aber m nicht und m kennt g nicht, es ist also genau umgekehrt zum Script. Im Quellcode besitzt g ein oder mehrere m und m ein oder mehrere p.

erst einmal will ich Schorsch zustimmen: es ist gut, sich auch mal die Herangehensweise anderer anzusehen und ggf. daraus zu lernen =)


unter Beziehung verstehe ich am ehesten das, was auch in UML-(Klassen-)Diagrammen mit Beziehungen gemeint ist
im einfachsten Fall würde zwischen 2 Klassen eine Beziehung bestehen, wenn eine der beiden Klassen eine oder mehr Referenzen auf die anderen speichern kann
in dem Fall wäre es die Map, die alle Spieler (und andere Objekte) speichern würde und wodurch eine Beziehung zwischen Spieler und Map besteht
(genauso würde ich von einer Beziehung sprechen, wenn sich nur die Spieler merken, wo sie sind oder wenn beide Seiten die Gegenseite speichern, wobei letzteres meines Wissens gemieden wird)

die Eigenschaften, die der Beziehung zuzuordnen sind, sollten also an der Stelle gespeichert werden, an der auch der/die Beziehungspartner gespeichert wird/werden
in dem Fall wäre das, da die Spieler von der Map gespeichert werden (dürften) auch bei der Map sein
dies könnte beispielsweise durch eine zusätzliche Klasse geschehen, die die Informationen beinhält und mit dem Beziehungspartner (Spieler) durch ein Assoziatives Array in Zusammenhang gebracht wird
oder durch eine Klasse mit den zusätzlichen Informationen, die ebenfalls den Spieler beinhaltet
(eine zusätzliche Klasse ist nur dann erforderlich, wenn man mehr als eine Information speichern will)
man könnte sich auch die Position und die Spieler in einem assoziativem Array halten

nur dann, wenn der Spieler sich in nur einer Umgebung/einem Kontext befinden kann, welche(r) bestimmt, wie die Werte zu interpretieren sind, können die Werte auch unterhalb des Spielers gespeichert werden
(i. d. R. ist das zwar gegeben, es könnte aber beispielsweise 2D-Spiele geben, bei denen einerseits eine Draufsicht verwendet wird und der spieler sich in alle Himmelsrichtungen bewegen kann, andererseits könnte an anderer Stelle auch eine Seitenansicht verwendet werden, bei der man nach links und rechts laufen und springen kann - Beispiele: ein paar Zelda Teile oder Contra III)
so könnte entweder die Position direkt im Spieler oder innerhalb einer Klasse sein, von der sich ein Objekt im Spieler befindet
letzteres der beiden würde wiederum, bei richtiger Umsetzung, dafür sorgen, dass der Spieler die enthaltenen Informationen "nicht kennt" (sondern nur ein Objekt, welches eine bestimmte Schnittstelle implementiert, welches von der Umgebung kommt)

worin wir uns einig zu sein scheinen: der Spieler sollte nicht selbst wissen, wie er sich zu bewegen hat
damit du verstehst, warum ich davon ausgehe übertrage ich das von mir geschriebene einfach mal auf deine Umsetzung:


ich gehe davon aus, dass deine Klassenstruktur im Groben so aussieht:
es gibt ein Interface für den Controller
es gibt die Klasse Spieler, die dieses Interface kennt
es gibt eine Implementierung des Controllers, die das Interface kennt (ob sie den Sppieler kennt, bin ich mir gerade nicht ganz sicher)
und es gibt eine Klasse für die Umgebung (Map), die den Spieler kennt und ihm den Controller zuweisen kann

wenn man von der Funktionalität absieht (also ersteinmal nur die Daten betrachtet), dann ist die Implementierung des Interface (der Controller) im Prinzip die Klasse für die Speicherung der Daten (Position) des Spielers
diese liegt nicht auf der Seite der Map (assoziatives Array oder Liste von Controllern, die den Spieler kennen), sondern auf der Seite des Spielers (was unter der Voraussetzung, dass es sich nur in einer Umgebung befinden kann, nicht so verkehrt ist

wenn man den Controller auf die Seite der Umgebung verlegt (und ihm für seine Arbeit dann auch den Spieler bekannt macht), hätte man somit die Speicherung der Eigenschaften der Beziehung, wie ich sie gemeint habe
man könnte den Controller als "Teil" der Map sehen, der zur besseren Unterteilung dient (woran ich bisher noch nicht so richtig gedacht hatte...)
und das nicht nur der Daten, sondern auch der Funktionalität, so zum Beispiel wird innerhalb des Controllers ja die Berechnung (mit dem darin liegenden Skript) durchgeführt


sollte ich irgendwas übersehen/vergessen haben, dann weise mich bitte darauf hin
(und ich hoffe, dass die Antwort nicht mal wieder an der Frage vorbei ging... =/ )


was mich selbst interessieren würde:
die Skripte haben Zugriff auf die Eigenschaften der Map (oder allgemein der darüber liegenden Elemente), obwohl dies über die Klassenstruktur für den normalen Code nicht gegeben ist
wie kommt es dazu?
und überhaupt: was ist in dem Zusammenhang mit "Skript" gemeint?
vermutlich ein Stück Quellcode einer anderen Sprache, die an der entsprechenden Stelle zur Ausführung gebracht wird (vielleicht Lua?)

Ja, die Antwort war wie ich mir das in etwa schon gedacht hatte und passt zu dem, was ich gern an Infos wissen wollte.

Mit der Beschreibung meiner Klassen-Struktur hast Du ebenfalls in etwa Recht, wenn man es grob vereinfacht. Der Controller selbst kennt übrigens den Spieler nicht auch die Map nicht. Das von ihm ausgeführte Script kann aber auf gewisse Properties der Owner, sprich in diesem Fall des Spielers und der Map, zugreifen.
Das heißt: Jedes Element, welches einen Controller besitzt, blendet eventuell auch Properties in den Scope des Controller-Scripts ein. Darüber kann das Script auf notwendige Informationen zugreifen. Eine Abhängigkeit im Code zwischen beiden gibt es aber nicht. Das hat folgende Vorteile:

1) Ich kann die Map jederzeit austauschen oder weglassen. Je nach Spiel kann ich sie ändern, ohne den Code der darunter liegenden Elemente anfassen zu müssen. Ich muss Spieler nicht ändern. Klingt erst mal so, als ob man da auch einfach ein Interface für die Map hätte nehmen können. Was aber, wenn es gar keine Map gibt? Dann wäre diese Property "Map" des Spielers unsinnig. Worin der Spieler oder generell das Spiel-Element also enthalten ist, das ist nicht festgelegt. Das kann alles mögliche sein.

2) Ich kann die Controller überall verwenden, ohne irgend etwas über die Umgebung zu wissen. Auch hier muss ich wieder keinerlei Code anfassen. Ich nehme einen Controller, schreibe ein Script dazu und pappe den an ein Element, was ich bewegen oder animieren will. Ich verwende sie bei Spielern, ich verwende sie bei Enemies, ich verwende sie bei Bällen in einem Spiel, bei Schüssen, bei Partikel-Systemen, bei GUI-Elementen und weiß der Geier bei was noch so. Die Properties, auf die ich im Script zugreife, die muss ich natürlich kennen, aber die weiß ich ja, weil ich weiß, welche Elemente in meinem Spiel wen besitzen. Die Controller-Klasse selbst kennt also niemanden, der eine Ebene höher in der Abstraktion liegt, nur die Elemente, aus denen er selbst aufgebaut ist und natürlich die Interfaces, deren Eigenschaften oder Methoden er anbietet.

"Skript" in diesem Zusammenhang ist ein komplexes Gebilde in Baum-Struktur, was vom Prinzip her einem Stück Quellcode ähnelt, aber statt reiner logischer Abfolge von Befehlen zu jeder Ausführung auch eine Animation mappt. Sie ist (eben durch den Baum) beliebig iterativ oder sogar parallel, leider aber nie rekursiv. Das ganze ließe sich in einer Sprache sehr schwer ausdrücken und daher basiert das Scripting auf einem visuellen Editor. Man stelle sich das in etwa so vor: Es gibt einfache Befehle, bedingte Befehle, Schleifen und Parallele Tasks. Viele davon laufen über einen gewissen Zeitraum, in welchem sie Position, Ausrichtung und Animationen für den direkten Owner repräsentieren. Die, die nicht über einen Zeitraum laufen, die haben keine grafische Repräsentation, sie triggern Events, berechnen oder setzen Werte oder steuern unsichtbar den eigenen "Programmfluss" (if, while, sleep, parallel, stop, event, set/call, ...).

um das Bekanntmachen der Eigenschaften der Umgebung, des Spielers etc. (alles, was über dem Controller liegt) nochmal mit eigenen Worten zu umschreiben (auch wenn es evtl. leicht abweichend ist):
wenn ein Aufruf des Controller-Scripts und somit eine Aktualisierung der Spielerposition/Rotation/... bevor steht (also der regelmäßige Update), wird erst die Map dazu aufgerufen, dies durchzuführen
diese erhält dafür den "Ausführungskontext" für das Skript, welcher diverse Informationen enthält (ggf. auch Referenzen auf diverse Funktionen, die für das Skript relevant sein könnten)
fügt eigene Informationen (die eigenen Eigenschaften) an und reicht ihn an alle Elemente weiter, die es verwaltet (u. A. der Spieler), welche ggf. ebenfalls Informationen hinzufügen und ihn weiter reichen
nach dem Spieler dürfte es bereits den Controller erreichen, der sich dann um die Ausführung des Skripts kümmert
da bei diesem weiterreichen von Oben nach unten die Informationen hinzugefügt wurden, sind diese auch dem Skript also letztendlich bekannt

mal sehen, wie viel ich evtl. für mein eigenes Projekt verwenden werde, allerdings habe ich da noch einige Dinge, die überarbeitet werden müssen und noch mehr, die überhaupt erst integriert werden müssen... (aber das ist eine andere Sache)

in gewisser Weise würde mich auch interessieren, was der Controller alles wissen (welche Klassen er kennen und welche Objekte "besitzen") muss, um das Skript zur Ausführung zu bringen
allerdings würde ich das für meinen Code nicht direkt übernehmen, da die "Skripte" bei mir Code sind, der beim "aktivieren" eines Objekts ausgeführt werden (bei den Objekten kann es sich um "physische" Objekte, wie andere Charaktere, Truhen, Türen etc. handeln, gegen die er gegen laufen oder ansprechen kann oder um "Trigger", die beim Betreten ausgelöst werden)
dieses Eventhandling ist allerdings auch noch nicht final und es wird sich bestimmt noch einiges daran ändern, aber das nur am Rande


die Weise, in der du es gelöst hast, ist selbstverständlich gut durchdacht

Na ja, es gibt schon ein paar Probleme, so ist's nicht. Was ich auch gern korrigieren würde ist die "Idee" dessen, dass jedes Objekt Informationen oder Eigenschaften "hinzufügt". Es wird nirgendwo etwas hinzugepackt. Da würde man sonst ständig Informationen/Instanzen hin und her schaufeln, die gar nicht benutzt werden. Statt dessen werden durch die Skripte aktiv Eigenschaften abgefragt durch "Identifier" (sind keine, könnte man aber unter Umständen so verstehen). Das büßt minimal Performance ein im Fall einer konkrete Abfrage oder bei einem Call, spart aber massiv in all den Fällen, wo nichts abgefragt wird.

Nachteil des ganzen Verfahrens ist, dass ich langsam den Überblick darüber verliere, welche Elemente welche Properties einblenden. Aber dazu gibt es für mich ein eigenes Wiki und nun bald auch einen Dialog, mit dem ich die bereitgestellten Properties direkt anzeigen lassen kann.