Sieht mir sehr nach GDI aus. Warum kein XNA?

Morgen,

ich find das ganze recht interessant.. Erinnert mich ganz entfernt schon an so einfache RPG - Maker etc. - Geschichten.

Lauft auch unter Linux (find ich gut ^^). Ich fänds nicht schlecht wenn eine solche Engine, gerade wenn Sie per GDI läuft (also nicht mit Windows.Forms etc. zusammenhängt), auch auf Linux mittels Mono laufen würde.

Die Figur sollte sich nocht von Feld zu Feld teleportieren.
Und wenn du für dein "Alles in der Map-System" einen guten Editor schreibst, geht doch alles in Ordnung

Hey, ich habe mal einen richtig guten Artikel über ein Pokemonspiel mit dem RPG-Maker XP gelesen. Nicht gleich abschrecken lassen, der Typ hat wirklich was drauf gehabt und sich nicht nur was zusammengeklickt^^ Habe leider keinen Link zu dem Artikel, darum erzähl ich einfach mal:

Es gab mehrere Mapausschnitte die zusammen die gesamtmap ergeben. NPCs konnten so nur in ihrem Map-Bereich existieren, was aber auch gut war denn in Pokemon interessiert der NPC fünf Dörfer weiter nicht - die Rechenlast kann man sich sparen. Verknüpft waren die Karten (nicht nur die einzelnen Bereiche, auch die Häuser) durch Teleport-Einträge in einer Datei, die nur für den aktuellen Bereich gültig ist. Vorteil: Ebenfalls interessiert der Hauseingang fünf Dörfer weiter nicht und es muss nur eine minimale Anzahl abgefragt werden. Die Einträge in der Teleport-Datei haben informationen wie Blickrichtung, Position und KartenID enthalten.
Es gab eigentlich für alles eine eigene Listen-Datei, für die Gebiete in denen man Pokemon antreffen konnte gab es eine spezielle Datei, für jeden Bereich gibt es eine (darf man Fahrrad fahren? Hintergrundmusik, etc).
Großer Vorteil von vielen Dateien ist, dass man sehr leicht erweitern kann und alles übersichtlich bleibt da man sehr gezielt nach den benötigten Infos suchen/debuggen kann. Nachteil ist eben, dass es viele Dateien gibt, aber als zip sollte das kein Problem darstellen.

Die Tiles hatten auch allerlei Informationen: Kollision (erweitert, man könnte es als "Begehbarkeit" bezeichnen da die Gehrichtung eine Rolle spielt. so kann man die Hänge beispielsweise herunterspringen aber nicht hochklettern), Texur und TerrainID (sehr nützlich um z.B. Surfer/Bootfahren zu realisieren - prüfen ob das nebenfeld wasser ist, wenn ja, dann kann los geschiffert werden. Kann/Sollte desshalb mit in die Kollisionsprüfung einfließen). Es gibt also wieder eine Liste, die auskunft darüber gibt wie ein Tile auszusehen hat und welche Eigenschaften es hat. Die Map besteht dann nur noch aus TileIDs und ggf ein paar Zusatzinfos (erzwungene Kollision etc).

Ich denke mal ein solches System würde sich viel leichter warten lassen und bleibt sehr übersichtlich. All diese Infos in jedes Tile zu hinterlegen würde zwar auch funktionieren, dann hast du aber später (wenn du vllt einen Editor programmierst) viel Arbeit um einfachste Probleme zu lösen: Vereinfacht gesagt ist ein Fangebiet ein Rectangle, ein Eintrag und das Fangebiet ist da oder wieder gelöscht. Du müsstest jede Information (welches Gebiet? Welche Pokemon laufen da rum?) jedem Tile zuweisen... viel arbeit, schwer zu warten und aktuell zu halten.

Tipp von mir um das Sprunghafte gehen in den Griff zu bekommen:
In meiner 2.5D Engine (die ja streng genommen auch auf einer 2D tilebasierenden Welt basiert) speichere ich Positionen als PointF (also x und y angaben als Single statt Integer). So sind zwischenschritte ganz einfach möglich: 2.34 ; 1.9 bedeutet dann, dass man sich auf Tile 2;1 befindet (=> math.ceiling benutzen) und um 0.34 Einheiten nach rechts und 0.9 Einheiten nach unten verschoben ist. Eine Einheit ist dabei das Kantenmaß des (quadratischen) Tiles in Pixeln. Schon kann man kreuz und quer herumlaufen (zwar nicht exakt wie in Vampires Dawn aber ich denke mal das tut der Sache keinen Abbruch).
Das du die Zeichenzeit mit angibts zeigt, dass du schon auf dem richtigen Weg bist. Der Gameloop läuft ja in etwa so ab:

do
Update (neue Positionen berechnen etc)
Zeichnen
ggf ausbremsen um z.b. eine konstante Framerate von 50 zu erhalten
loop

nun könntest du mittels Stopwatch die zeit die seit dem Letzten update vergangen ist messen und den loop gezielt ausbremsen. Die vergangene Zeit (die entweder konstant ist oder mal steigt, da die Framerate performancebedingt abfällt) übergibts du dem Update-Sub und ermöglichst so, dass sich alle NPCs (und animierten Vorgänge) immer (also unabhängig von der Framerate) gleichschnell abspielen.
Die Berechnungen sind so auch sehr einfach zu machen, schau einfach mal hier: [VB 2010] Auto fahren mit Richtung

so genug geschrieben xD
gn8 und viel spass beim weiterentwickeln! Ich hoffe den ein oder anderen Gedanken kann man brauchen^^
lg

Edit: Warum steigt die Zeichenzeit (am anfang = 3ms) linear auf ca. 20ms wenn man nach rechts unten geht? xDD
Edit2: CreateGrahpics?

Würdest du mit XNA arbeiten, könntest du die Positionen einfach über nen kurzen Zeitraum hinweg lerpen.

Kannst du mich mit der Updateloop aufklären, ist das einfach ein Timer, der alle 60ms, alles Invalidet?

jein, das ist eine schleife, welche versucht auf 60 fps zu kommen, dafuer musst du die zeit messen die beim zeichnen vergeht, und nach dem zeichnen den thread so lange warten dassen, dass zeichnen + warten 16 ms gedauert haben. wenn das zeichnen halt >16 ms gedauert hat geht das ncht, dann lässt du das warten halt weg.

Hi
VD ist ja mit dem RPG Maker gemacht und es ist ja üblich, dass man genau wie bei dir von Tile zu Tile geht - es werden allerdings ein paar zwischenschritte gemacht damit es wie eine Bewegung aussieht.
Dein Zeichnen-System hat noch einen weiteren Nachteil: spätestens wenn es einen bewegten Bildausschnitt gibt (die Map wird ja denke ich größer werden als es der Bildschirm anzeigen kann - darum immer nur ein kleiner Ausschnitt sichtbar und die Spielerfigur in der Mitte) muss ja nach jedem neuberechnen der Positionen bzw wenn sich auch nur der Spieler ein wenig bewegt ALLES neugezeichnet werden. Ist also kein Performancegewinn, ein Spiel sollte eine konstante Framerate haben, dann hat man die wenigsten Probleme.

Kinsi wird da glaubeich eine etwas andere Meinung vertreten aber für einen Gameloop halte ich folgendes System für am sinnvollsten:



Großer vorteil von meinem System: wenn sich der Spieler bewegt, wird sich bei jedem Frame (egal ob unter 20 FPS oder 60FPS) der Spieler:
- gleichschnell Bewegen (+/- eine kleine Toleranz, da die Zeiten von ca. 20ms als Integer gehandhabt werden und ein Rundungsfehler da schon +/- 5% ausmacht)
- in jedem(!) Frame wird der Spieler sich ein kleines Stück bewegen. Es gibt niemals Frames indenen keine Positionsveränderung festzustellen ist UND es werden nur soviele Updates (also Positionserneuerungen) durchgeführt wie nötig.

Kinsi baut lieber auf 2 Threads auf - einer Zeichnet, der andere Updatet die Positionen ständig. Da hat man dann allerdings das Problem, dass:
- mehr Updates gemacht werden als notwendig / oder weniger. Folge: Keine Positionsänderungen sichtbar bzw manche Updates gehen "ins leere" und werden letzen endes nicht sichtbar
- der UpdateThread verändert die Daten während dem Zeichnen. Bei meiner Engine wurde dieser Effekt besonders bei geringen Frameraten sichtbar: Annahme: Man dreht sich. In der Zeichenroutine werden zuerst die Wände gezeichnet, dann Objekte. Ändert sich nun der Kamerawinkel während dem Zeichnen, passiert es, dass die Objekte unter einem anderen Blickwinkel gezeichnet werden wie die Wände - wirkt so als ob die Objekte nicht so richtig fest an ihrem Platz stehen würden xD

diese Probleme entfallen bei meinem System komplett da Update und Render strikt nacheinander ausgeführt werden und nicht zwischendrin. Vorteil von Kinsi's System ist ein Performancegewinn. Sollte imo aber nicht so stark ins Gewicht fallen.

lg

Bei XNA wird Update() auch öfter aufgerufen als Draw(), erst recht dann, wenn das System mit dem Zeichnen nicht hinterherkommt.
Das wäre die bessere Lösung.

@ Samus Aran
warum? xD da bin ich anderer Meinung^^
Wenn ich update 10 mal aufrufe und Draw dagegen nur einmal, dann sind 9 Updatevorgänge für die Katz, da sie ja nicht "sichtbar" werden. Da sich die Updatevorgänge ja eh nach der Zeit die seit dem letzten Update und Draw verstrichen ist richten, erhält man immer die passenden Ergebnisse.
Wenn das System mit dem zeichnen nicht hinterher kommt wird die übergebene GameTime automatisch größer, die Sprünge der Figuren auch. Logisch, da man ja nur noch z.b. 10 Frames die Sekunde macht und die zwischenschritte nichtmehr erkennen kann..

Nur weil die Dinge, die in der Update-Methode passieren, nicht sichtbar sind, sind sie nicht "für die Katz".
Stell dir vor, das Spiel läuft mit 3 FPS. Bei dir wird Update() 3-mal pro Sekunde aufgerufen. Das heißt, dass Tastendrücke wie z.B. Escape nur 3-mal pro Sekunde registriert werden können, und deshalb oft nicht registriert werden. Und wenn die Knöpfe die Bewegung des Spielers steuern, ists noch schlimmer, da die Bewegung nur 3-mal pro Sekunde aktualisiert wird. Das wäre noch schlimmer als Lag wegen ner schlechten Internetverbindung.

in einem spiel hatte ich dein system ja mal getestet, das probldm dabei ist dass du es nicht hinkriegen kannst, das es immer gleich schnell ist. des weiteren, wenn es nun sagen wkr mal nur 10 fps gibt, und dann ein spieler fällt, hast du ne hohe cance dass der apieler z.b. durch einen block durchclippt weil der spieler bei niedrigen framerates mehr bloecke pro cycle fällt und dadurch z.b. durch nen block durchfsllen kann. und ob es nun unsichtbare updates gibt(mein system) oder es per berechnung auf den wert gebracht wird, der gefallen wird(nicht genau moeglich) ist doch ziemlich egal.

@Samus Aran
@kinsi

verdammt, da habt ihr recht!

Problem ist, dass beides nur ein ein Problem mit dem anderen vertauscht:
- Update-Rate = FrameRate: bei geringen Frameraten Clipping und Tastenbugs
- Update-Rate > FrameRate: bei geringen Frameraten Grafikfehler

Wie könne man BEIDE Probleme (die ja auch nur bei sehr geringen Frameraten sichtbar werden) aus der Welt schaffen? Mein System wird da scheitern, die Kollisionsfehler könnte man noch herausrechnen (Pfad zwischen Punkt A und B prüfen) - spätestens wenn es um die Tastenauswertung geht wars das dann aber..

Man müsste (wie kinsi auch schon lange sagt xD) die Mapdaten extra für den Zeichenvorgang clonen, damit der Update-Part da nicht reinpfuschen kann. Das will ich aber möglichst umgehen! Alternative in aussicht?

@ThuCommix
Ja sry, dass ich soviel schreib xD
Wenn du auf die KeyBoard-Events reagierst wird die Geschwindigkeit theoretisch stark schwanken können. Wenn du auf die Events reagierst und Boolean-Variablen wie "Key_Up/Down/Left/.." auf True oder False setzt jenachdem ob die Taste gedrückt ist, kannst du im Update-Part damit weiterarbeiten: Wenn Key_Up gedrückt, dann soll sich der Spieler in Blickrichtung nach oben bewegen. Du hast die vergangene Zeit seit dem letzen update, die gewünschte Gehgeschwindigkeit und kannst so die neue Position berechnen:

'XNeu = XAlt + Geschwindigkeit * Zeit * math.Cos(winkel)
'YNeu = YAlt + Geschwindigkeit * Zeit * Math.Sin(winkel)

Grafikfehler? wat?

Bei meiner 2.5D Engine ist mir das sehr stark aufgefallen. Im Render-Part ist es nunmal so, dass zuerst die Wände und Böden berechnet und "gezeichnet" werden und erst dann die Sprites (also Figuren und Objekte wie Bäume). Wenn man nun mehr Updates als Draws macht, dann kann/wird es unter einer geringen Framerate vorkommen, dass bei einem Kameraschwenk die Objekte unter anderem Winkel dargestellt werden als Boden/Wände. Das wirkt dann so also ob die Sprites irgendwo "festkleben" würden und verzögert ihre richtige Position auf dem Bild einnehmen.
Das passiert also nur, weil ein häufigeres Updaten dazu führt, dass sich die Positionen während dem zeichnen verändern - quasie mehrere verschiedene Situationen auf einem Bild dargestellt werden.

Ist aber auch nur ein Effekt - wie die clipping und tastatur-bugs - der bei geringen Frameraten vorkommt. Unter dem Gesichtspunkt würde ich Grafikfehler eher hinnehmen können als einen Fehler in der Spielmechanik. Wer versucht bei weniger als 30FPS zu spielen muss dann eben mit rechnen...

Der einzige brauchbare Lösungsansatz wäre wohl vor dem Zeichnen eine komplette Kopie aller Informationen anzulegen - so würde das Update da nichtmehr reinpfuschen können. Das failt imo aber hart und drückt die Performance vermutlich ein gutes Stück nach unten..

Ich denke mal, dass in einem reinen 2D-Spiel diese Grafikfehler garnicht auffallen würden - also ist die 2-Thread-Variante die bessere. 2.5D ist da ja was anderes.

Sieht aus eigene Auge besser lesbar aus, was aber eig. egal ist sobald man einmal einen funktionierenden Editor/Parser geschrieben hat.
Wobei ich nicht glaube das man beim einlesen der Map auf performance o.ä. legen muss
(Außer wenn du wirklich nur eine große Map erstellen wilst, wo nur die Häuser und Höhlen etc. in eine extra Datei kommen)

Edit: Ok, und es kommt natürlich auf die Anzahl der Layer in verbindung mit der Kartengröße an.
Eine 50.000 x 50.000 Tile große Map mit 8 Layer, könnte schon heftig werden
(Fragt mich nicht wiso 8 Layer, hab ich aber schon von einigen gehört).