Welt bewegt sich um Spieler

[fui-tak]

Ich würde das ganze ähnlich wie Medium beschrieben hat angehen, nur anstatt der speziellen Liste einfach ein Zweidimensionales Array nehmen, etwa so:
level: array of array of TFeldElement; Ein Objekt des Typs FeldElement (oder wahlweise statt Klasse ein Record nehmen) beinhaltet, dann die einzelnen Eigenschaften

Hier mal mit einem Record:

Delphi-Quellcode:

TFeldElement = record
  teleporterXPos, teleporterYPos: integer;//speichert, wo hingesprungen werden soll
  inhalt: byte;//begehbar, nicht begehbar oder Teleporter
  textur: string;//den Namen der Textur
end;

Zeichnen würde ich dann irgendwie so:

Delphi-Quellcode:

   for i := 0 to high(level) do 
     for k := 0 to high(level[0]) do
       case level[i,k].inhalt of
        1: ..... //begehbares Feld an der Position (i * Breite eines Feldes + xLevel/ k * Breite eines Feldes + yLevel)
        ...
       end;

xLevel und yLevel sind dann die Koordinaten des Levels.
Wenn du deine Figur bewegts, muss du dann beispielsweise beim nach unten gehen folgendes machen:

Delphi-Quellcode:

figur.yPos := figur.yPos + 25;//der Spieler wird nach unten verschoben
yLevel := yLevel - 25; //das Level wird nach oben verschoben

Insgesamt hat sich nun also deine Karte nach oben gescrollt und deine Figur ist immer noch in der Mitte des Bildschirms

[s.h.a.r.k]

Such hier im Forum mal nach Andorra. Ich glaube, das dürfte etwas für dich sein.

[Memnarch]

Fui-Tak's Methode ist schon ganz gut, Aber ich würde zb anstatt Texturname, ne ID verwenden oder direkt XY koordinaten für die Tile, da es bei Tilefgames für gewöhnlich gebräuchlich ist, eine Datei zu haben, in der alle für den/das Level benötigten statischen grafiken sind.

Hinzu kommt noch, dass es vielleicht praktischer wäre, anstatt die map zu scrollen, eine neue Komponennte abzuleiten.

z.B. von TImage(nehm ich immer fürs zeichnen ).
Die nennst du VIEW, und die besitzt auch gleichzeitig die zwei neuen Attribute Pos_X/Pos_Y.
Alle Views werden in einer Liste gespeichert.

Dann bastellst du dir eine Render routine. Dieser Routine wird der View übergeben(also pro zyklus ein aufruf pro View in der liste). Die routine zeichnet dann in Abhängigkeit der View Attribute Pos_X/Pos_Y die Map und deren Objekte auf den Übergebenen View. Das gibt dir z.B. automatisch die Möglichkeit Splitscreens zu erstellen(vielleicht brauchst dus jetzt nicht, aber mal nen denkanstoss).
Anhand der View Position und der Größe der View in Pixeln kannst du mithilfe der Tile größe ersteinmal unter anderem bestimmen, wieviele Tiles überhaupt in den View passen UND darauf einfach die angegebenen tiles um die Viewposition zum rendern abfragen und Somit jedemenge rechenleistung sparen.

Dank des 2d Arrays aus dem die Map erstellt wurde, sind auch automatisch die nachbarfelder bekannt, was das suchen nach Soliden blöcken unter anderem für Kollision erleichtert.

Gleichzeitig sollte deine Map nocheinmal in grobe regionen unterteilt werden(z.B. 32*32 Tiles, jenachdem wie gross ein tile ist). Wenn ein Objekt erstellt wird(item oder sonstiges dass sich zur laufzeit ändert, also auch spielerfigur) Wird es anhand seiner Position in die Region eingeordnet(jede region hat zb ne liste mit den beinhaltenden objekten), so ist es leichter und performanter nach dynamischen beweglichen objekten zu suchen, um events oder kollision auszulösen)
Verlässt ein Objekt seine aktuelle region, muss es selbstverständlich in die neue eingeordnet und aus der alten entfernt werden.

Und jetzt habe ich wieder von allem und nichts erzählt

Also wiegesagt, das obrige sind nocheinmal ein paar techniken die es dir vereinfachen sollten das Spiel zu verwalten, und somit sogar ne kleine enginen Bilden(DAs obige sind zb Strukturen die ich nutze wenn ich 2d/ 2dTileengines Schreibe)


MFG
Memnarch

[RedShakal]

Das heißt wenn ich deine Methode richtig verstehe, erstelle ich mir die entsprechenden Map files und muss dann über den Record nurnoch das entsprechende Feld mit den angegebenen X Y Koordinaten aus der Map Datei laden? Oder habe ich das falsch verstanden?

[Memnarch]

So ungefähr.
Gehen wir davon aus du hast wie gesagt eine 2DPosition(camera genannt).

Die position ist direkt in PIxel angegeben.

Wenn du jetzt Tiles von 32p größe hast, teilst du die Position der camera durch 32, und bekommst so die position der camera auf dem tilegrid.


Danach renderst du die Tiles die sich in einem definierten Radius um die Camera befinden, der rest is ja eh nicht sichtbar

Hiernochmal nen Schaubild:

beispiel.png

Das schwarze gitter stellt deine gesammte Map dar. Der blaue punkt die momentane Position der Camera in PIXELN. Teils du dass durch die größe der Tiles, bekommst du die Tile Position der Camera. Von dort aus renderst du nur die tiles die auch sichtbar wären(der rote rahmen zeigt den Bildschirm, alles was außerhalb ist muss nicht gezeichnet werden)

DU lädst also ALLES(von einer welt), zeigst aber nur was dur brauchst

[RedShakal]

Das führt mich dann aber wieder zu dem Problem das ich die gesamte Map mit einem Schlag laden müsste was bei kleinen Maps Problemlos funktioniert, bei größeren Maps später aber nichtmehr unbedingt so vorteilhaft. Gerade bei älteren Rechnern würde die Ladezeit hochschießen. Oder irre ich mich da?

[mkinzler]

Ein derrtiges Level sollte eigentlich nicht allzuviel Speicher belegen

http://sourceforge.net/projects/jedi-isoax/
http://code.google.com/p/delphi-dire...tric-2dmmorpg/