Gravitation

[Lachsen]

@Dhan

Realistische Gravitation sieht (etwas genähert) in etwa so aus:

...

Mit "etwas genähert" hab ich eben das Weglassen der Reibung durch die Luft gemeint. xD
Praktisch gesehen sollte man für sowas einfach eine Max-Geschwindigkeit einbauen. (Technisch ist das sowieso notwendig, für den RPG-Maker)

Außerdem bezog ich mich nur auf die Gravitation, was für mich nur die Fallgeschwindigkeit ist, über die Seitwärtsbewegung wollte ich keine Aussage machen ^^°

Praktisch gesehen hast du recht: Eine realistische Seitwärtsbewegung im Sprung ist für ein Jump'n RUn ungeeignet, beim Springen/Fallen seh ich das allerdings anders)

@übelster Held

Ich hab es bereits geschafft, nen vollständig funktionierendes Jump'n Run mit Pixelbewegung (sogar mit Bewegung auf schrägen Ebenen) hinzubekommen, sonst würde ich hier auch nicht so große Töne spucken vonwegen Schwierigkeitsgrad o__° (genauer gesagt hab ich sowas schon zweimal gemacht - der erste Versuch hatte ein paar Macken und keine schrägbewegung, hat aber vom Prinzip her auch schon geklappt - nur ohne Scroll Bewegung im Level - das ganze ist auch schon einige Jahre her...(eventuell noch vor Vsb))

Es gibt da in der Tat einige probleme wegen der Pixelbewegung und der Kollisionsabfrage mit den Tiles, weshalb es auch eben so schwer ist.
Eine Lösung des Problems ist, dass man die Heldenfigur mit einer sehr hohen Frequenz mit ganz kleinen MovePicture Bewegungen (die kürzer als 0,1 Sekunden gehen - dafür gibts nen Trick) durch das Level bewegt.
Erste Regel ist nämlich, dass die Bewegung MAXIMAL von einem Teil ins Nächste gehen darf in einer Rechnungsrunde. Sollte ein Tile in einer Bewegungsrunde übersprungen werden ist schon ende. Deswegen sollte die Geschwindigkeit maximal 16 Pixel (vertikal und horinzontal) sein, pro Berechnungsdurchlauf.

Die Kollisionsabfrage macht man dann in der Tat, wie Dhan schon sagte, mit Terrain-ID (und mit Event-ID für bewegte Objekte).

Dann muss man viele sonderfälle bei der Kollisionsabfrage beachten (bewegung von einem Tile direkt in das nächste Schräg gegenüber etc.), weshalb das Skript dafür bei mir zumindest immer eine ganz ordentliche Länge hatte.

Ich könnte das Jump'n Run Skript irgendwann mal hochladen, aber naja, muss das noch mit jemanden besprechen dann (ist eigentlich nen Team-Projekt gewesen ^^°)

Naja, soviel nochmal dazu.

C ya

Lachsen

Edit: Das Scrollen ist auch ein Problem, man muss erstmal zusehen, dass die Pixelbewegungsgeschwindigkeit mit der von Events übereinstimmt, beim Rest muss der Bildschirm halt einfach sich so passend bewegen wie es geht. (ist nicht immer perfekt, aber übersichtlich genug)

[Dhan]

dafür gibts nen Trick

...

*neugierig bin* ^^
Ich nahm bisher an, Move Event führt grundsätzlich dazu, dass man sich in ganzen Tiles vorbewegt... hmmm ich weiß jetz net, wie dein Trick aussieht, aber ginge dann auch eine halbe Pixelorientierung in normalen RPGs?

@übelster Held: Mein ich ja gerade ^^
Die meisten Jump´n Runs ham eben keine realistische Gravitation, auch nicht im Sinne von v -tg, da steigt und fällt man immer mit der gleichen Geschwindigkeit (vy, wenn man Seitwärtsbewegung vx einrechnet, kommt natürlich unterschiedliche vs raus) und das is gut so, genau wie mit den Pilzen und Pflanzen, die einen stark machen und die sprechenden Schildkröten mit Flügeln... ach ne halt, das warn Drogen, oder?

[Lachsen]

*neugierig bin* ^^
Ich nahm bisher an, Move Event führt grundsätzlich dazu, dass man sich in ganzen Tiles vorbewegt... hmmm ich weiß jetz net, wie dein Trick aussieht, aber ginge dann auch eine halbe Pixelorientierung in normalen RPGs?

...

Ich meinte, dass es einen Trick gibt, dass man Move-Picture Befehle in einer kürzeren Zeitperiode als 0,1 Sekunden ausführt. (zum Beispiel ein MovePicture, dass 0,05 Sekunden dauert)
Das ganze geht nur mit Bewegung und vielleicht mit transparenzänderungen, beim zoomen könnte es problematisch werden.
Beim BEwegen geht es wie folgt:
1. Man bestimmt start und Zielposition und bildet die Differenz der beiden Punkte für x und y.
2. Man nimmt die Differenzen *x, wenn das Move-Event 0,1/x-Sekunden dauern soll (praktisch möglich sind da nur noch: x=6/5, 3/2, 2/1, 3/1 und 6/1).
3. Man addiert die Differenzen wieder zu den Startcoordinaten (bzw. subtrahiert, je nachdem wie man gerechnet hat)
4. Nun bewegt man das Picture mit einer Dauer von 0,1 Sekunden. Zur Berechneten Position (die nicht direkt die Zielposition ist)
5. Nun wartet man halt 0,1/x Sekunden (bei x=3/1 wären das z.B. 0,1/3= 2x 0.0 Sekunden)
6. Man führt ein weiteres MovePicture aus, dass mit einer Wartezeit von 0.0 Sekunden (heisst: auf der Stelle) das Pic an die richtigen Startcoordination setzt.

So hat man man ne Flüssige Bewegung eines Pictures von a nach b, die schneller als 0,1 Sekunden geht.

Und nochwas hinterher:

Die meisten Jump´n Runs ham eben keine realistische Gravitation, auch nicht im Sinne von v -tg, da steigt und fällt man immer mit der gleichen Geschwindigkeit

...

Bist du sicher? Soweit ich weiß, ist es schon in ansätzen so wie bei einer normale Sprungbewegung, nur dass halt die Sprunggeschwindigkeit am Anfang und Ende länger Konstant sind. An der Spitze des Sprunges macht der Charakter aufjedenfall nicht plötzlich stopp und fällt dann wieder runter, sondern wird schon allmälich langsamer und fällt dann anfangs etwas langsam, dann aber recht bald wieder schnell. Zumindest glaube ich mich daran zu erinnern, dass in Yoshi's Island nicht in Dreiecken und Trapezen gesprungen wurde, in Valkyrie Profile kann ich dies sogar mit Sicherheit bestätigen :P


Soviel von meiner Seite

C ya

Lachsen