spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

was Bluecobold zum Ausdruck bringen wollte:
eine Methode sollte nur einem Zweck dienen, also nur 1 Sache erledigen (und diese sollte in der Regel am Namen erkennbar sein)
übertragen auf deinen Code heißt das: die Aktualisierung der Szene ist ein Zweck, der erfüllt werden muss (mit all seinen Unterschitten, wie die Bewegung der Spieler und damit die Kollisionserkennung, das Explodieren der Bomben, ...)
das Zeichnen ist ein ganz andere und somit völlig unabhängig davon

ein anderes Projekt hier im Forum (Bomb Rush) zeigt sehr gut, was eine saubere Trennung bringen kann:
man kann in einem Spiel ohne größere Probleme 2 oder mehr verschiedene Darstellungsformen anbieten

mal abgesehen von Dingen, wie, dass der Code übersichtlicher und leichter zu lesen(/verstehen) wird

@Sacaldur: Lies mal bitte noch mein Edit. Bin einfach neugierig, wie Du das lösen würdest.

zunächst einmal: ich wollte nicht behaupten, dass der übliche Weg (Position im Spieler speichern) grundsätzlich schlecht ist (ich habe es die meisten Male der Einfachheit aus so gehandhabt)

Geschwindigkeit: eine schwierige Frage, aber letztendlich kann der spieler nicht wissen, wie schnell er sich wirklich bewegt
mal angenommen, der Spieler ist enorm schwer und kommt dadurch eine 45° Schräge nicht hoch: die Geschwindigkeit in Richtung hoch wäre also 0
wenn er jedoch herunter rennt, dürfte er wesentlich schneller sein, als wenn er über eine Ebene läuft

mal angenommen der Spieler ist ein Auto (in einem Rennspiel)
bei Autos hängt die Geschwindigkeit von der Leistung des Motors, der aktuellen Anzahl an Umdrehungen pro Sekunde, dem Untergrund, dem Gang (und Getriebe) und noch ein paar andere Faktoren ab
die Geschwindigkeit ist also ein Wert, der sich aus vielen Faktoren ergibt
wenn man ein möglichst realistisches Ergebnis haben möchte, müsste sich die Geschwindigkeit errechnen (lassen) und nicht als fester Wert oder als Liste von Werten o. ä. gespeichert sein

allerdings wüsste ich nicht, dass bei Spielen ein ausreichend großer Wert auf den Realismus der Bewegungsgeschwindigkeit gelegt wird, weshalb immer ein Wert gespeichert wird
aber wie oben schon beschrieben: dieser stellt u. U. auch nur einen Faktor dar


Rotation/Richtung:
wenn man das, was ich geschrieben habe, konsequent weiter führt, könnte man darauf kommen, dass auch die Richtung nur eine Eigenschaft der Beziehung ist (was ich auch nicht als falsch bezeichnen will)


vielleicht hätte ich damit schon beginnen sollen, aber hier mal ein praktischeres Beispiel, wo das Speichern als Beziehung relevanz hat:
ich befinde mich gerade in einem Raum
ich befinde mich ebenfalls in einem Haus
meine Position relativ zum Raum kann eine ganz andere sein, als zum Haus
auch (auch wenn schwer vorstellbar, weil Häuser meist Rechteckig sind) kann meine Rotation im Verhältnis zum Raum eine andere sein als zum Haus (beispielsweise im Pentagon)

übertragen auf Spiele:
in Jump'n'Runs hat man sehr oft sich bewegende Plattformen
wenn der Spieler sich auf diesen befindet, soll sich seine Position passend zu der Bewegung der Plattformen verändern
da die Position aber grundsätzlich als relativ zur gesamten Umgebung aufgefasst wird, muss sie jedes Mal aktualisiert werden, wenn die Position der Plattform aktualisiert wird
es wäre zwar möglich, sie im Verhältnis zur Plattform zu interpretieren, während der Spieler sich darauf befindet, allerdings muss für den Spieler dann auch noch festgehalten werden, dass er sich auf einer sich bewegenden Plattform befindet und auf welcher
das gleiche gilt auch für die Rotation, als Beispiel hier: Contra III (alias Super Probotector)
dort hatte mein teilweise eine Draufsicht und in entsprechenden Gebieten gab es Unterdründe, die einen sich rotieren ließen
auch das ist wieder mit einer ständigen Aktualisierung umsetzbar, ja


Animation:
nein, die würde ich nicht unbedingt auslagern
welcher Fuß sich wo befindet hängt im einfachsten Fall davon ab, wann die Bewegung angefangen hat und wie viel Zeit seit dem Moment vergangen ist
die Map (oder der Gamestate oder ...) müsste den Spieler nur darüber informieren, dass der Spieler angefangen hat, sich zu bewegen oder dass der Spieler aufgehört hat, sich zu bewegen
dabei kann dann auch noch auf diverse Feinheiten geachtet werden, wie:
soll der Spieler anhalten, weil er Spieler (mit Tastatur und Maus/Gamepad) es so will oder weil er gegen eine Wand gelaufen ist (da dem Spieler vorher mitgeteilt wurde, dass er anfangen soll, zu rennen, könnte dies auch verschieden dargestellt werden)
dann könnte es noch einen Unterschied machen, ob der Spieler sich selbst bewegt, von der Umgebung (Untegrund, Bildschirmrand, ...) oder von einem anderen Objekt (Mitspieler oder NPC) bewegt wird


das Problem, welches vermutlich gesehen wird
so ziemlich alle Informationen, die Informationen der Beziehung sind, werden zum Rednern benötigt
allerdings kann man auch da so ran gehen, dass ein Spieler "über" seine Umgebung gezeichnet wird und somit von dieser die notwendigen Werte erhält


abschließend möchte ich sagen:
die Position (und Rotation etc.) im Spieler zu speichern, bietet eine gewisse Vereinfachung und ist somit nicht als falsch anzusehen (genauso wie das Speichern der Geschwindigkeit oder das Speichern eines Ergebnisses einer Rechnung)
allerdings würde ich es als sauberer ansehen, wenn es als Eigenschaft der Beziehung gespeichert wird


PS:
ich hatte eben ein wenig zu tun, weshalb das Schreiben des Beitrags ein wenig länger gedauert hat
sollten bereits weitere Beiträge geschrieben worden sein, habe ich diese also nicht berücksichtigt

Ich glaube ich hätte die Frage konkreter stellen sollen, du bist mir da etwas über das Ziel hinausgeschossen. Zum Beispiel die Sache mit der Steigung oder dem Auto, da sehe ich die Sache nämlich gleich deutlich mehr wie du.
Ich frag mal anders: Wie stellst Du Dir so eine "Beziehung" vor? Separate Klasse mit eigenen Instanzen irgendwo separat verwaltet? Oder eine Art "Calculator" als "Eigenschaft" des Spielers? Ich persönlich verwende z.B. Motion- und Animation-Controller als Eigenschaften von "Spielern", auch wenn das natürlich nicht ganz der Realität entspricht, sondern eher eine technische Modellierung ist. Diese berechnen dann anhand ihrer Parameter die Position, Ausrichtung und Animation eines Objekts, per extern erstelltem Script, welches sich auf vom Owner oder von der Welt bereitgestellte Properties bezieht, um die korrekten Werte zu berechnen.

Bei diesen Designfragen muss man aber ein bisschen aufpassen. An sich kann man über Codedesign streiten. Vor allem wenn es um OOP Fragen geht. Das was ihr hier vorstellt ist alles schön und gut, aber für einen Anfänger total überfordernd. Flutschi hat ja geschrieben, dass er das Design grad auf Klassen umstellt. Jedenfalls habe ich das so verstanden. Da sollte man es ruhig noch etwas einfacher halten. Nichtsdestotrotz ist die Diskussion über die Designfrage schon interessant. BlueCobold kannst du mal ein kleines Pseudocode Beispiel zu deinem Controlleransatz machen? Wo wird so ein Controller aufgerufen? Ist die Steuerung in eine Viewschicht gekapselt und leitet die Befehle dann über den Spieler an den Controller, oder wie stell ich mir das vor? Und der Controller würde dann das Skript aufrufen, und ihm den Spieler/die Map/etc mitgeben. Im Skript würden dann die Werte vom Spieler/Map/etc geholt, neu berechnet und wieder gesetzt? Verstehe ich das richtig oder?

@Flutschi:
Was wichtig für den Spieler ist, darf auch ruhig erst mal im Spieler gespeichert werden. Das bedeutet, Spielergrafik, Spielerposition, Geschwindigkeit und solche Werte. Der Spieler sollte seine Spiellogik und seine Renderlogik von einander trennen. Verpass ihm eine Methode Update und eine Methode Render. In Render wird der Spieler nur gezeichnet. Alles was der Spieler benötigt um sich selbst zu zeichnen, kannst du dieser Methode als Parameter übergeben. Normal hat er ja alles wie seine Richtung, seine Position, seine Grafik und sollte so vermutlich nur den Bildschirm als Parameter übergeben kriegen. Je nachdem mit welcher Engine du arbeitest.
In der Update Methode führst du die Logik des Spielers aus. Bei einem Jump N Run könntest du hier dafür sorgen, dass auf den Spieler eine Gravitation wirkt. Die Kollision ist so eine Sache. Eine Möglichkeit wäre dies in die Map auszulagern. Du hast zum Beispiel eine Funktion Kollision(Spieler) die zurück gibt, ob der Spieler mit einem Objekt auf der Karte kollidiert oder nicht. Dann kannst du beim Bewegen die neue Position des Spielers bestimmen, überprüfen ob eine Kollision auftritt und entweder ist alles gut oder du musst die Position noch zurück setzen. Dann müsste der Spieler in seiner Funktion zum bewegen natürlich die Instanz der Mapklasse bekommen.
Das wäre nur eine Möglichkeit wie du es umsetzen könntest. Sicherlich geht es auch alles schöner, aber als Anfänger soll man sich selbst nicht zu stark überfordern. Man soll die Konzepte Schritt für Schritt lernen und richtig verstehen. Der Rest kommt mit der Zeit.

@Schorsch:
Pseudo-Code, muss ich mal schauen, ob ich dazu heute Abend mal Zeit habe. Gesetzt werden die Werte der Owner in den Skripten/Controllern allerdings eher selten. Sie lesen nur Eigenschaften aus und berechnen daraus neue Werte für Position, Ausrichtung oder aktuelle Animation. Diese Eigenschaften des Spielers werden dann eben durch die Controller berechnet, die Spieler-Instanz selbst hat davon keinen Plan. Auch von der Animation nicht, die ist gekoppelt an den Controller. Ein Spieler (oder auch Non-Player-Objekt) bekommt halt einen oder mehrere Controller zugewiesen.

Und wenn so ein Spieler über den Movecontroller bewegt wird? Dann ist die Position also nicht im Spieler sondern im Controller gespeichert oder wie verstehe ich das? Oder aktualisiert der Controller nachdem die Skripte die Werte berechnet haben dann den Spieler? Finde es einfach interessant mal andere Ansätze zu sehen.

Jeder, der die Position ausliest, greift auf die Positions-Werte aus dem Controller zu. Der Controller wird aktualisiert, wenn der Spieler aktualisiert wird. Der Controller durchläuft beim Update die Skripte zur Berechnung. Die Skripte greifen auf Properties zu, die von den Ownern eingeblendet werden. Der Spieler ist ein direkter Owner des Controllers, aber die Map ist eventuell ein Owner des Spielers und das Game ist eventuell Owner der Map. Jeder blendet also Eigenschaften oder Methoden ein, auf die das Script des Controllers zugreifen kann. Die selben Controller gibt es übrigens auch für Menü-Elemente, Projektile, Partikel-Effekte und weiß der Geier was. Sie steuern Positionen, Verhalten, Animationen der jeweiligen Elemente.