Größe und Position der Spielergrafik in RPG

[Kaeru Gaman]

ob dann quadratisch, ist auch wieder geschmackssache.
das wäre bei diesem chibi schon wieder ein ziemlich großer fußbereich.

richtig gut sieht das natürlich nur aus, wenn die mauern genauso angelegt sind,
also, der player ein stückchen hinter einer mauer verschwinden kann.

[ZeHa]

Naja quadratisch schon, aber das Quadrat muß nicht direkt an den Füßen sein, sondern das kann nochmal locker um 2 Pixel nach unten verschoben werden

Wie auch immer, das wichtigste ist eben, daß man ein funktionierendes Weltmodell hat. Hierfür ist es auch ganz nett, wenn man eigene Größen verwendet, z.B. 100x100 = 1 Feld. Dann kann man so tun, als wären das Zentimeter. Dann legt man sämtliche Größen im Zentimeter-Maß an, auch die BoundingBox einer Figur usw., und hat ein recht einfaches, leicht überschaubares Modell.

Wenn dann der Renderer dran ist, muß dieser einfach nur die Koordinaten in sein Pixelmaß umrechnen. Man ist dann vollkommen unabhängig, und selbst wenn man irgendwann die Auflösung verdoppeln will und auch die Figuren bzw. Tiles doppelt so groß zeichnen will, muß man dies einfach nur im Renderer entsprechend einstellen. Sogar alle zeitlich basierten Dinge passen noch einwandfrei. Denn wenn man z.B. immer in seinem 32x32-Modus denkt, und irgendwann mit 64x64 arbeiten will, wären ja im ersten Moment sämtliche Bewegungen nur noch halb so schnell. Wenn man aber völlig losgelöst vom Renderer ein "metrisches System" einführt und verwendet, dann ist das immer konsistend und es ist dem Renderer überlassen, wie er was zeichnen will. Man kann sogar ohne Probleme den Renderer austauschen, z.B. statt einem 2D-Renderer einen 3D- oder Iso-Renderer einbauen. Sogar ein Textmodus-Renderer ist möglich und das alles, ohne am Weltmodell etwas ändern zu müssen.

[Rubiko]

Gut, mein letztes Problem in Sachen Kollision... ich schwör's euch seit 7 uhr Morgens hock ich davor

Also ich erklähr ma:
für die Kollision muss ich ja alle 8 Eckpunkte berechnen, eigentlich ganz einfach... das Problem dabei ist jetzt, es geht alles von PlayerX aus, da Tilemapscrolling aber bereits drin ist, sich also nur die Koordinaten der Map verändern, verändert sich PlayerX nie, sprich ich kann nichts damit anfangen.

Erstmal zum scrolling selber: Funktioniert bei mir eigentlich genau wie das von Kaeru:
http://www.purebasic.fr/german/viewtopi ... 634#116634
(zweiter Code von ihm)

Nur wie komm ich hier an die pixelgenaue Position von PlayerX?

Es wäre kein Problem zu berechnen auf welchem Tile sich die Maus oder die Spielerfigur befindet, aber pixelgenau ist 'ne andere Sache

Hoffe ihr versteht was ich meine, allein das erklähren fiel mir jetzt etwas schwer

[ZeHa]

Ich zitiere mich mal selbst...

Jepp, schon klar

Aber mir geht's auch drum, daß man als Anfänger eben oft den Fehler macht, und sich zu stark an der Grafik orientiert. Da kann es auchmal vorkommen, daß jemand bei einem scrollenden Spiel jedes Background-Tile in seiner Position verschiebt, weil es ja scrollen soll

Daher merke: Das Weltmodell muß in sich stimmig sein, und die Grafik sitzt "obenauf" und orientiert sich an den Gegebenheiten

Es ist so oder so schonmal falsch, daß sich Deine Map verschiebt, wenn eigentlich der Player läuft. Wenn der Player läuft, dann muß sich auch die Position des Players verändern. Wenn Du aus dem Haus gehst, bleibt Dein Haus schließlich auch am selben Fleck stehen.

[Rubiko]

hm.. Verwirrung

Beides kann ich ja schlecht bewegen, wenn ich das tue is der Spieler doch bald vom Bild, egal in welche Richtung ich ihn noch bewege

[Zaphod]

Du verschiebst das Level entsprechend der Position des Spielers. Das ist also vollkommen egal. Wenn der Spieler sich bewegt, veränder sich seine Position auf der Karte. Das sich das Sprite nicht bewegt, sondern eine Feste Position auf dem Bildschirm hat, ist ja letztendlich nur eine Frage der interpretation.

Es sollte also kein Problem sein, die Koordinaten auszurechnen.

[ZeHa]

Jo, also nochmal kurz: Trenne Deine Daten von Deiner Anzeige.

Stell Dir mal vor, Du würdest aus Deiner momentanen Lösung eine 2-Spieler-Variante machen. Dann bräuchtest Du ja auch zwei Kamera-Ansichten. Und wie würdest Du das bitteschön machen, wenn Du jedesmal den Hintergrund bewegst statt dem Spieler?

Also im Klartext: Du hast ein Weltmodell (also eine Karte und Objekte und deren Positionen), und das muß stimmen. Wenn der Spieler sich bewegt, dann bewegt sich der Spieler. Wenn sich eine Wand bewegt, dann bewegt sich die Wand. Das erstmal zum einen, so ist es in der realen Welt schließlich auch.
Dann kommt die Ansicht dazu. Ob Du ein Foto von der Spitze des Eiffelturms schießt, oder ob Du unten vom Platz aus die Spitze des Turms fotografierst, hängt einzig und allein von der Kameraposition ab. Der Turm steht immer noch an der gleichen Stelle.

Das heißt, Deine Grafikroutinen müssen das ganze einfach nur in den richtigen Kontext bringen. Sie holen sich vom Weltmodell die Daten (also die tatsächliche Position des Spielers), und richten dann rein beim Anzeigen alles danach aus.
Wichtig ist, daß sich beim Anzeigen keine Daten im Weltmodell ändern. Das Weltmodell hat das Sagen

Im Grunde würdest Du also ungefähr so vorgehen (pseudo-code):

Code: Alles auswählen

cameraX = playerX - (screenWidth / 2) + (playerWidth / 2)
cameraY = playerY - (screenHeight / 2) + (playerHeight / 2)

for each tile or object:
    x = tileX - cameraX
    y = tileY - cameraY
    renderSprite(tileSprite, x, y)

Natürlich gehört auch der Player selbst zu den Objekten. Dieser wird völlig automatisch nun an der richtigen Stelle gezeichnet.

Behalte das auf jeden Fall im Hinterkopf: Daten und deren Anzeige sind was völlig verschiedenes und sollten nicht in einen Topf geworfen werden. Ganz einfaches Beispiel: Du hast eine Tabelle mit den Monatsgehältern Deiner Mitarbeiter. Jetzt willst Du die grafisch mit Balken darstellen. Aber nun ist es zu klein, und Du willst die Balken doppelt so groß machen. Dann ist das eine Sache der Anzeige. Du solltest möglichst NICHT auf die Idee kommen, einfach nur die Gehälter zu verdoppeln (es sei denn, Du willst Dich bei Deinen Mitarbeitern beliebt machen ).

[ZeHa]

Bin grad in Schreiblaune, und vielleicht mach ich auch mal einen längeren Artikel zum Thema "Spieleprogrammierung ohne Anfänger-Fehler". Hatte schonmal was angefangen, allerdings zu 'nem leicht anderen Thema, aber das wurde nie fertig...

Naja, jedenfalls, mir ist grad noch ein gutes Beispiel eingefallen. Du kennst ja sicherlich das Prinzip der Vektorgrafiken. Da hat jeder Punkt und jede Kurve seine absoluten Koordinaten. Wenn Du nun das Bild in einem entsprechenden Programm anschaust, und reinzoomst oder das "Blatt" hin- und herverschiebst, dann wird das ja entsprechend an einer anderen Stelle oder in einer anderen Größe gezeichnet. Allerdings ist das reine Interpretationssache für den Renderer. Die Koordinaten selbst ändern sich NICHT bzw. erst dann, wenn Du tatsächlich die Grafik auf dem Blatt verschiebst oder vergrößerst/verkleinerst. Aber solang Du nur herumnavigierst, bleiben die Daten immer die gleichen. Lediglich der Renderer setzt es etwas anders um.

Und noch ein neues Beispiel: Du kannst einen Text in jeder beliebigen Schriftgröße und Schriftart anzeigen. Der Text ändert sich dadurch aber nicht. Möglicherweise sehen die Buchstaben trotzdem völlig anders aus. Es gibt Schriften, wo alle Buchstaben als Großbuchstaben angezeigt werden. Manche Schriften bestehen sogar nur aus Symbolen. Aber der eigentliche Text - also der "String" - bleibt nach wie vor derselbe

Grundsätzlich gilt das für alle möglichen Programme - nicht nur für Spiele. Daten sind Daten, und Ausgabe ist Ausgabe. Gibt auch einen Begriff dafür, und zwar "MVC bzw. Model View Controller". Hier werden die Bereiche aufgeteilt in Datenmodell, Ansicht und Steuerung. Das sind drei verschiedene Dinge, und alle müssen für sich modular sein - sprich, austauschbar und ohne die anderen funktionierend.