Was ist bei einer guten Jump 'n' Run Engine zu beachten?

[PrinZZ]

Der Titel erklärt erigentlich schon alles.
Ich habe vor ein Jump 'n' Run mit dem RPG Maker zu Programmieren.
Was muss man beachten, wenn man will, dass alles flüssig von statten geht?

Danke im Voraus,

Tobi

[Davy Jones]

Ich würde erstmal einen Pixelmovement-Skript mit entsprechender Kollisionsabfrage proggen/kopieren und auf einer Testmap mir angucken, ob das alles so läuft wie ich mir das vorstelle. Zero Base hat schon gezeigt wie es geht, allerdings war das ein Shmup und bei Jump 'n Runs könnte das etwas komplexer werden.

Beim Springen sollte man btw Kontrolle in der Luft besitzen, d. h. nach vorne springen, aber durch Tastendruck nochmal etwas zurücksteuern können wie bei SMW.

[MagicMaker]

Kann ich so nur unterstreichen. Das ist auch ein technisch sehr komplexes Unterfangen aber es
funktioniert sogar sehr gut ohne Patcheskram (wie man an jp. Beispielen sieht (http://www.youtube.com/watch?v=IH99YtvxOjE)).


Beim Springen sollte man btw Kontrolle in der Luft besitzen, d. h. nach vorne springen, aber durch Tastendruck nochmal etwas zurücksteuern können wie bei SMW.
Gut da lässt sich noch eine Variation einbringen, wer Ghouls'n'Ghosts nachbauen will, braucht sich
darum weniger zu kümmern, da der Held abgesehen vom Doppelsprung genauso springt, wie man
zum Sprungstart lenkt, egal wie die Konsequenzen aussehen.

Dann muss das Leveldesign aber auch so konzipiert sein, dass es passt.

[Shadowsoul]

Pixelmovement ist auf jedenfall Pflicht, soviel steht fest.
Ob man nun die Kontrolle beim Sprung behalten sollte muss man für sich selbst entscheiden, ich finde es nicht zwingend notwendig.
Ich hätte hier mal 2 ältere Engines von mir wo du evtl mal reinschauen könntest:
JnR Engine ehemals für den 48h-Contest (http://dl.dropbox.com/u/5617908/48hContestEngineShadowsoul.rar)
eine auf SMW basierende JnR Engine (http://dl.dropbox.com/u/5617908/SuperKovoWorld.rar)

[Lord Malkom]

gibt es inzwischen ein script das man sich nicht mehr nur felderweise fortbewegt?
das finde ich immer bei den Zelda umsetzungen so grausam und unspielbar ^^

[PrinZZ]

Danke für die Antworten, Tipps und Scripts! ich schau mir das ganze mal in ruhe an.
Das mit dem Pixelmovement hab ich mir schon gedacht, hat einer von euch schonmal das erste Castlevania für die NES gespielt? da kann man sich auch nur felderweise bewegen und der sprung ist genau vorgegeben. Obwohl man sich sicherlich daran gewöhnt nach einer zeit, nimmt es dem ganzen doch sehr viel Dynamik!

[Shadowsoul]

Sicherlich nimmt so ein vorgegebener Sprung sehr viel Dynamik raus und bringt des öfteren Frust durch fehlgeschlagene Sprungversuche hervor, es macht das Gameplay oftmals einfach schwerer, aber wenn ich mich zum Beispiel an die Oddworld Teile für Playstation zurück erinnere ist die fehlende Dynamik nicht unbedingt verkehrt weil es einfach zum Charakter und Gameplay passt.
10102

[PrinZZ]

Okay, das macht mir Mut, das mit dem Pixelmovement, vorallem auch mit dem im Flug steuern stellt sich als echt schwer raus!
Damit das gescheit wirkt, muss man sozusagen machen, dass je länger man die taste drückt (links, rechts,..) desto mehr geschwindigkeit nimmt man im Flug auf, und um dann doch noch in die andere richtung zu lenken, muss man dem Moment (nennt man das so?) wieder entgegen wirken. Also die Geschwindigkeit in die eine Richtung nimmt ab, und am scheitelpunkt nimmt dann die geschwindigkeit in die andere Richtung wieder zu.
Alles recht kompliziert Schrägstrich aufwendig...
Da wäre ein vorgegebener Sprung doch um einiges einfacher! Um Dynamik reinzubringen könnte man sich ja auhc etwas anderes überlegen, z.B. dass andere Dinge den Sprung noch beeinflussen könnten wie ein zusätzlicher tastendruck einen "doppelsprung" auslöst, mit dem man noch die richtung ändern kann/weiter kommt oder ähnliches..

[MagicMaker]

Da wäre ein vorgegebener Sprung doch um einiges einfacher! Um Dynamik reinzubringen könnte man sich ja auhc etwas anderes überlegen, z.B. dass andere Dinge den Sprung noch beeinflussen könnten wie ein zusätzlicher tastendruck einen "doppelsprung" auslöst, mit dem man noch die richtung ändern kann/weiter kommt oder ähnliches..
Wie gesagt es gibt Spiele die damit auch gut zurechtkommen ~ Ghouls'n'Ghosts.

Aber die gehören selbst dann nicht zu meinen Lieblingen wenn das Spiel dieser steifen Steuerung
angepasst ist. Und ein negatives Makerbeispiel obendrauf: Duckworld.

[Shadowsoul]

so schwer ist das mit der Steuerung nicht in meinen Augen, man müsste lediglich eine Beschleunigung einbauen welche die Geschwindigkeit erhöht oder entgegen eben vermindert, das könnte man mit einer einfach gehalten mit einer Variable als Zähler und nen paar Bedingungen zum Beispiel umsetzen, kann man gut in X und Y Richtung anwenden, hatte ich in meinen ersten Jump n Run Spielen auch so gemacht, nur wurde dadurch das gezielte springen etwas schwierig ^^"
Ich bevorzuge immernoch die SMW Variante.

[PrinZZ]

Ja du nennst schon das nächste Problem, wenn es nämlich in der Umsetzung zu stark reagiert geht das gezielte springen den Bach runter, was dann auch nur nervig ist.
Und ja du hast recht, mit Variablen kann man ja ganz leicht den Picturescroll speed verändern.
Denkt ihr ich brauche für das game einen Tastenpatch? oder funktionieren Dinge wie ->Taste gedrückt halten und in regelmäßigen Abständen abfragen ob sie noch gedrückt sind.. auch ohne Patch?

[Shadowsoul]

ich für meinen Teil hatte Probleme mit dem Sprung ohne Patch, selbst bei gedrückter Taste ist der Sprung einfach hin und wieder abgebrochen, kann sein das es an meiner Makerweise liegt, aber deswegen sind 3 oder 4 meiner Spiele ziemlich unspielbar. Ich wüsste allerdings auch nicht wie man das anders machen sollte. Mittlerweile bin ich auf den Destiny Patch umgestiegen.

[CapSeb]

Zum Thema "Taste gedrückt halten" habe ich die Erfahrung gemacht, dass je nach PC, der zum Testen genutzt wird, es vorkommen kann, dass kurzzeitig ein Loslassen der Taste registriert werden kann, obwohl sie durchgehend festgehalten wird. Ich denke mal, dass das an der Tastatur leigen kann. Das Problem lässt sich aber umgehen (bei mir jetzt völlig fehlerfrei bisher), in dem sehr kurzes Loslassen der Taste trotzdem als durchgehendes Festhalten gewertet wird. Dazu zählt man in einer Variabe einfach 0,0wait-Durchläufe mit und verschachtelt die Abfragen entsprechend, sodass erst ab einer gewissen Durchlaufanzahl die Taste als Losgelassen gilt.
Also funktionieren tut es - auch ohne Patches, wenn man längere Zeit an den Problemen werkelt. Und Shadowsoul, bau das dochmal ein, damit deine Spiele wieder laufen. ^^

@Owly
Das Dokument finde ich sehr interessant, insbesondere die Analyse zu den Sprungverhalten bekannter Jump'n'Runs. Eine Anmerkung zu den vorgeschlagenen kürzeren Sprüngen: Bei kurzem Drücken der Sprungtaste lediglich den Gravitationsfaktor zu erhöhen, würde dazu führen, dass in der Aufwärtsbewegung ein schnelleres Abbremsen, also eine Verkleinerung der Sprungparabel, entstehen würde, statt ein Darstellen des oberen Stücks der Parabel. Während das nur Detailsache ist, ist der Verlauf in der Abwärtsbewegung etwas dramatischer: Liegt das Sprungziel tiefer als der Absprungort, würde man enorm schnell die maximale Fallgeschwindigkeit erreichen, falls eine solche existiert.

Falls man nicht an der Parabelspitze, also dem Hochpunkt, den Gravitationsfaktor ändern will (was einen Workaround darstellt), würde ich Folgendes vorschlagen:
Entweder (a), wenn erst nach Loslassen gesprungen werden soll, dass die Druckdauer auf die Taste die Sprungstärke speichert, also die vertikale Beschleunigung, und das diese im Verlauf des Sprungs abnimmt.
Oder (b), wenn mit Beginn des Drückens gesprungen werden soll (wie z.B. Mario es tut), dass ein Festhalten der Sprungtaste die - auch hier verwendete - Sprungstärke vor dem Verringern schützt, also bei Festhalten der Sprungtaste die Gravitation solange geringer ist. Dieses teilweise Aufheben der Gravitation ist auch genau der psychologische Aspekt den man spürt: Man kann die spielbare Figur noch etwas nach oben "drücken".

In Bezug auf Trägheit bin ich übrigens schon länger am Überlegen, wie das möglichst fundamental und ohne kompliziertere Formel lösbar ist. Bei deinem Ansatz erzeugt die simulierte Reibung keine Geschwindigkeitsgrenze. So habe ich den Ansatz "(momentaneGeschwindigkeit + konstanteBeschleunigung) * ReibungsFaktor" gewählt, mit Reibungsfaktor knapp unter eins. Aber ich muss immer wieder daran denken, dass ich irgendwo gehört habe, dass erst bei achtfacher Kraft die Maximalgeschwindigkeit verdoppelt ist, also die Reibung bzw. der Luftwiderstand kubisch wirkt. Kubisch ist nicht sehr elementar ... also falls jemand dazu mehr weiß (Physiker anwesend?).

[Shadowsoul]

Und Shadowsoul, bau das dochmal ein, damit deine Spiele wieder laufen. ^^

das mit dem 0,0s wait hatte mir R.D. schon mal vor langer Zeit erklärt, allerdings hatte sich dadurch die komplette Bewegungsgeschwindigkeit natürlich drastisch geändert, somit hätte ich wieder einiges umskripten müssen und da ich vor Jahren noch auf einen ordentlich gegliederten Skriptaufbau verzichtet hatte, war mir das zu umständlich und wirklich einwandfrei hatte es trotzdem nicht funktioniert.

@ Owly:
hab das Dokument bisher nur grob überflogen, sieht aber wirklich sehr interessant aus