Guten Tag euch allen!
Also ich suche jemand der mir eine Gravitation erklären kann oder mir ein Script dafür bastelt!Aber ich meine eine richtige Gravitation wie z.B. bei Megaman 1 Reborn! Aber bitte kein normalen J&R Sprünge weil ich die auch selber basteln kann!
Also bitte schnell antworten! Und thx schonmal im Voraus!
ääh...
du meinst jetzt in Jump&Run Seitenansicht? Oder in Vogelperspektive
Wie meinst du das?
So, das Gegenstände runterfallen und so weiter...?
Ne gravitations-engine?
erklär mal genauer aber ich glaube kaum, das der Maker für sowas richtig komplexes geeignet ist
Bitte bei solchen Anfragen etwas mehr Details rausrücken! Es wäre zum Beispiel schön mal zu erfahren welchen Maker du benutzt und ob du jetzt ein Klickscript oder eins für Ruby suchst. Wenn hier jeder erst dreimal nachfragen muß was genau du wofür brauchst wirst du wahrscheinlich noch lange auf eine Lösung deines Problems warten!
Das Prinzip ist einfach:
Du hast ja irgendwo ne Sprung-Abfrage, mit Tastenbelegung etc.
Der Rest geht ja eigentlich fast von selber... wenn der Sprung gestartet wird, musst du eigentlich nur nen Switch anschalten, der dann ein Event auslöst welches dafür sorgt das der Held sich langsam nach oben bewegt, und wenn er den Höhepunkt erreicht hat wieder nach unten.
Hierbei eine Flüssige Bewegung hinzukriegen dürfte eher das Problem sein als das Bewegen an sich. Sinnvoll wäre es auch wenn der Chara beim nach oben Springen langsamer wird und beim Fallen schneller. Aber wozu gibts denn "Move Speed Up" und "Move Speed Down"?
Selbes System für sämtliche Gegner und Objekte.
Genauer kann ich es nicht erklären da ich es noch nicht gemacht habe. Feinheiten müsstest du selber raustüfteln. (das ist halt immer das problem bei so komplexen sachen....) Wenn du in der Lage bist mit dem Keypatch selber n Sprungscript zu bauen dann dürfte das was ich beschrieben habe wohl ne kleinigkeit sein.
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Wenn du -nebenbei angemerkt - eine realistische Gravitation in einem Jump'n Run haben willst, musst du Zwangsläufig mit Pixelbewegung arbeiten.
Mit Movevente erreich man nämlich in der Regel nur eine Zackige Hoch - Pause -Runter bewegen, d.H. die Bewegung nach oben hat permanent die gleiche Geschwindigkeit, hört dann aufeinmal auf, und geht dann mit alter Geschwindigkeit wieder runter.
Realistische Gravitation sieht (etwas genähert) in etwa so aus:
Beim Sprung hat der Charakter eine Startgeschwindigkeit nach oben. Nennen wir die mal v.
Durch diese GEschwindifkeit bewegt sich der Charakter nach oben.
Allerdings wirkt gegen diese Geschwindigkeit die Gravitationskraft g.
Zwischen Kraft und Geschwindigkeit besteht allerdings ein kleiner Unterschied:
Während die Geschwindigkeit einmal da ist und an sich konstant bleibt, sorgt die Kraft dafür, dass die Geschwindigkeit in Richtung der Kraft mit der Zeit zunimmt.
Im Falle vom Sprung wirkt die Gravtitation gegen die Startgeschwindigkeit.
Praktisch auf den Sprung bezogen heisst das:
Jede Sekunde sorgt g dafür, dass die Geschwindigkeit geringer wird und sich irgendwann nach unten richtet.
Mathematisch lässt sich das so ausdrücken:
Aktuelle Geschwindigkeit= v - t*g (wobei t die aktuelle Zeit ist)
So kommt ab einer bestimmten Zeit ein Vorzeichenwechsel in der Geschwindigkeit zustande. Das ist der Fall, wenn der Springer wieder zu Fallen beginnt. (d.h. wenn man davon ausgeht, dass negative GEschwindigkeit eine BEwegung nach unten bedeutet - das ist wiederum relativ und definitionssache o.o)
Die daraus resultierende Sprungbewegen ist (wenn man eine Konstante seitliche Bewegung dazu nimmt) einem Kreisbogen ähnlich (bzw. der Laufbahn einer umgedrehten Parabel), während die Sprungbahn über MoveEvents in der Regel einem Dreieck oder einem Trapez entspricht.
Wer diese Beschreibung der Gravitation nicht richtig versteht (eigentlich ist es Physik der Unterstufe - oder Oberstufe.... weiß ich nichtmehr genau), dem sei gesagt: Die Umsetzung ist noch viel schwerer.
Genauer gesagt ist ein Jump'n Run mit Pixelbewegung generell eines der schwersten Technischen Gebiete für den RM2k, zumindest nach meiner Erfahrung. (ein Kampfsystem oder Menu ist da nichts dagegen)
Dieser Post ist in gewisser Art und Weise unnötig, ich weiß o__°
Aber mir war einfach danach, tut mir Leid ^^°
C ya
Lachsen
PS: Und wer es nicht verstehen sollte - Das hat zu einem nicht unwesenlichen Teil mit meiner katastrophalen Ausdrucksweise zu tun. :3
PPS: Alle angaben zum Schwierigkeitsgrad hier beziehen sich auf dem RM2k. Es kann sein, dass all das mit dem RMXP viel leichter umzusetzen ist - ja - es ist sogar wahrscheinlich.
Aber irgendwie bezweifle ich dennoch, das es deshalb einfach ist.
hm Pixelbewegung? dann müsste man doch alles mit pictures machen, und dann muss auch z.B. wenn man rechts drückt das bild sich nur um einen pixelweiter bewegen...
ich denke sowas würde nur ruckeln o.O
wenn mir einer das gegenteil beweisen kann, dann nehm ich das mitm ruckeln zurück^^
EDIT:
hm vielleicht versuch ich das mal und schicke es als script ^^
Man muss ja nicht alles als Bild machen. Wenn man sich normal bewegt benutzt man ein Charset und beim Sprung tauscht man das gegen ein Bild.
btw: Oberstufe, Lachsen.
also das mit den realistischen sprung, das ist sch... nicht sehr schön...
ich hab zum tech-kontest im atelier sowas mal gebaut...
also man bewegt sich normal mit der tile-bewegung aber
der sprung wird mit pictures angelegt...
aber da gab es viele, viele probleme...
zuerst war es doddal sch... unschön zu spielen, wenn man
sich die sprung-nach-oben-geschwindigkeit ständig verringert hat...
dann hatte man noch das problem, dass man sich bei dem seitensprung
auch noch in eine richtung bewegt... aber der bildschirm will das
irgendwie nicht... ;__;
naja... wenn man das problem gelöst hat, kommt das nächste:
woher weiß der maker, beim runterfallen, wann stopp ist???
es gibt ja auch weitere ebenen in son sprung und renn spiel,
so das wenn man auf koordinate 5;1 startet mit den sprung
nicht zwingend auf 7;1 landen muss... sondern man vielleicht auf
7;5 landen kann... ;__;
ein ähnliches problem beim pixelspringen ist ebenfalls:
wie weit hoch darf ich denn überhaupt springen???
denn über 5;1 kann ja auch eine box oder sowas sein, so dass
man maximal bis 5;5 hochspringen kann, aber mit der beschleunigung
vielleicht locker bis 5;8 kommt...
diese zwei probleme sind natürlich auch zu lösen... und sogar mit einer
leichten möglichkeit, ohne irgendwo den maker mit dorthin-kann-ich-nicht-springen-koordinaten zu füttern...^^
hm... was gab es denn noch für schwierigkeiten...
genau...
wenn man pixelspringen einbaut, kann man ja auch zwischen den
tiles landen... °°... und da steht ja kein charset... ;__;
da könnte man als lösung vereinbaren, wann der hero noch aufs
vorherige tile landet und wann auf das nächste tile... naja...
wie man sieht, stößt man auf viele probleme...
aber so schwer wie lachsen die sache mit den formeln wieder
schildert ist das ganze nun auch wieder nicht...^^
wenn ihr unbedingt wollt, kann ich ja mal mein script hochladen...
ist aber für rm2k, weil ich nicht mit patches arbeite und man auf
den 2k dadurch nicht in genuss von schrägen sprüngen kommen kann...
na eigentlich schon... aber... egal...^^
--"Der einzige Unterschied zwischen einem Verrückten und mir ist der, dass ich nicht verrückt bin." Salvador Dalí
üH sein KS <<>> üH sein Kit
Also bei "echter Gravitation", also v - tg gibts 2 Probleme:
1. Das System funktioniert in einem Vakuum prima. Was aber in einer Atmosphäre dazukommt, sind Viskosität (wie zäh/dicht die Luft ist), Fläche der Person, Aerodynamik der Person, Windstärke und -richtung um mal die wirkungsvollsten Faktoren zu nennen
Und ja, die spielen durchaus eine bemerkbare Rolle.
2. Wenn man erstmal fällt und keine Steuerungsapparatur wie ein Segel hat, kann man während dem Fall seine Richtung nicht bestimmen, das geht nur beim Absprung. Gerade für ein Jump´n Run ist das scheiße, Super Mario kanns und so solls sein.
@übelster Held: Man kann Kollision-Masks mehr oder minder gut in der Terrain ID speichern, d.h. man prüft immer nach, auf welchen Koords sich der Held befindet und schaut nach, welche Terrain ID diese Koords ham
Dann schaut man auf die genaue Pixelkoordinate innerhalb der Mapkoordinate und macht die nächste Aktion von der zur ID passenden Kollision Mask abhängig... schon ein bisserl umständlich joa.
Der eigentliche "Held" ist unsichtbar und folgt dem Picture (ein Followerscript dürfte wohl net das Problem sein), das ihn darstellt, das folgen ist nur damit der Bildschirm mehr oder weniger automatisch scrollt
Geändert von Dhan (19.01.2006 um 16:15 Uhr)
^^...komisch, dass die ganzen münzen, die so groß sind wie man selbst, einfach so verschwinden, wenn man sie berührt... und dass wir plötzlichZitat von Dhan
mit feuer schießen können, wenn wir eine pflanze angucken...XD
also komm... wir wollen hier nicht die welt simmulieren...
und über kleine ungereimtheiten kann man (glaube ich) bei spielen
hinwegschauen... schließlich ist das nur ein jump`n run...
mit den terrain ID hab ich das auch gemacht... aber da kann man immer
noch nicht abfragen, ob ein gegner im weg ist oder nicht... und die
upper chipsets haben ja auch keine ID...
aber beim scrollen ist die schwierigkeit, WANN sich der unsichtbare held
bewegen soll... denn die links rechts bewegung ist ja auch pixelweiße...
hab da irgendwie keine flüssige möglichkeit gefunden...^^
aber hab auch keinen bock mehr eine zu finden...^^
--"Der einzige Unterschied zwischen einem Verrückten und mir ist der, dass ich nicht verrückt bin." Salvador Dalí
üH sein KS <<>> üH sein Kit
@Dhan
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)
Geändert von Lachsen (19.01.2006 um 19:43 Uhr)
@ laxi
ich habe nie behauptet, dass ein jump`n run spiel zu erstellen
leicht wäre... ich hab nur gesagt (oder jedenfalls versucht zu sagen...^^),
dass das mit den formel nicht sehr schwer ist... also die ganzen physikalischen formeln für die schwerkraft (ohne berücksichtigung der ganzen luftreibung ec...) in den maker zu pressen...
natürlich ist es ein übelster buckel, ein funktionierendes jump`n run
zu baun, aber halt das thema schwerkraft ist da nicht so die hürde,
woran man da scheitert... (wesst schoo wie ich das mein...^^)
mfg
üH
--"Der einzige Unterschied zwischen einem Verrückten und mir ist der, dass ich nicht verrückt bin." Salvador Dalí
üH sein KS <<>> üH sein Kit
Das Stimmt schon, so meinte ich es eigentlich auch nicht, (auch wenn es so rüber kam).
Ich meinte nur: Wenn man sowas einbauen will (relativ realistische Gravitation), brauch man ein Jump'n Run mit Pixelbewegung und das wiederum ist sehr schwer umzusetzen. (also so gesehen auch das, was du meintest)
C ya
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?
@ü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?
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:
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
@ Lachsen
Kannst du mir dein Jump n Run mal per E-Mail schicken? E-Mail findest du auf meiner Site unter Kontakt!
@ Dhan
Sei dir da mal nicht so sicher.Wie schon Lachsen gesagt hat ist in Yoshis Island auf jeden Fall eine Gravitation eingebaut. Dasselbe gilt auch für Sonic spiele. Hätte man früher in ein Sonic spiel einen billigen Dreieckssprung eingebaut dann währe Sonic heute nicht so berühmt! Aber wo du recht hast ist in den meisten RPG Maker Jump n Runs ein billiger Dreieckssprung eingebaut. Das liegt aber nicht daran das es nicht möglich währe sondern daran das die meisten nicht wissen wies geht!
--
Oh Leute....
Wenn ich mir das hier alles so durchlese, dann frage ich mich wirklich obs hier noch um den RPG-Maker oder irgendwelche anderen selbstgeproggten 2d-Spiele geht...
v=t*g und luftwiederstand und blubb.... ihr spinnt... da lässt sich mit DarkBasic leichter n Jump&Run bauen als mit dem Maker wenn ihr so etwas haben wollt.
Aber mal ehrlich.... ich finde für den RPG-Maker reicht es vollkommen aus den Kram mit MoveEvents zu machen, Eine flüssige Animation kann man mit etwas geschick trotzdem erzeugen... (hab ich nämlich bereits in meinem Spiel drin aber da hier alle meinen es geht nicht haben mich meine Augen wohl getäuscht....)
Zum Thema gute Beispiele für Gravitation mit Geschwindigkeitsänderung:
Schonmal wer MegaManX und X2 auf dem SNES gespielt? Ich meine dort war das so. Hab die Spiele leider nicht mehr, sonst hät ich vorher nochmal nachgesehen
--Aktuelles Projekt
"Uns're Ordnung ist das Chaos!
Verändern heißt zerstör'n!
Berechtigungen
Zitieren
