Druckbare Version
Guten Tag euch allen!:D
Also ich suche jemand der mir eine Gravitation erklären kann oder mir ein Script dafür bastelt!http://www.multimediaxis.de/images/s.../old/s_009.gif 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!:D
ää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
Ja also ich mein Seitenansicht! Also ein J&R! Und das ist möglich!:D
Siehe die Beispiel Demo bei Inelukis keypatch(Jump and Runbeispiel)!
Und eben wie gesagt Megaman 1 Reborn von Neo23!http://www.multimediaxis.de/images/s.../old/s_009.gif
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!
Nun ähm verzeiht bitte die Belästigung! Ich hatte die Lösung die ganze Zeit vor Augen! Sah sie aber nicht!:D Also Problem gelöst!;) Entschuldigt nochma!http://www.multimediaxis.de/images/s.../old/sm_12.gif
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.
Ne schon gut wie gesagt hat sich geklärt! Aber damit hät ich nix anfangen können weil das ja nur ein Standartjump wäre! Den normalen Jump hab ich aber ja schon bis zur perfektion ausgereizt!:D Egal trotzdem thx!;) Aber wie gesagt hat sich erledigt!
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...^^
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
^^...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:
Zitat 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...^^
@Dhan
Mit "etwas genähert" hab ich eben das Weglassen der Reibung durch die Luft gemeint. xDZitat:
Realistische Gravitation sieht (etwas genähert) in etwa so aus:
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)
@ 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
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* ^^Zitat:
Zitat von Lachsen
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)Zitat:
Zitat von Dhan
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 :PZitat:
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
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 -_-
Ähm ja also das hat alles mit dem RPG Maker zu tun! Und ob ich schon mal Megaman X gespielt habe? Hehe rat mal wofür ich die Gravitation brauche!:D
Aber ich hab nun eine Lösung die viel Arbeit erfordert aber auch viele Möglichkeiten bietet! Ich poste die jetzt lieber nicht weils die simpelste und auch scriptuntauglichste ist! Und ein Standardjump reicht beim besten Willen nicht für MMX oder überhaupt irgendein Jump and Run aus!;)
@Lachsen: hmm hab's jetzt nicht 100% kapiert aba klingt interessant... braucht man das um den Helden schneller bewegen zu können ohne zu viel Pixelgenauigkeit einzubüßen? (wenn ich den Helden in einem PP-Event mit einem 0.0Wait pro Durchlauf um einen Pixel bewege, entspricht das doch afaik schon "normal" Eventgeschwindigkeit oder? .. weiß nicht mehr genau..-> wird dann nähmlich schwierig den Helden schneller laufen zu lassen, da ja bei jeder Bewegung die Kollisionsabfragen anspringen. Das ruckelt dann recht schnell, wenn man den Helden mit 2x oder 4x faster bewegen will).
Obwohl man theoretisch auch die Kollisionsabfragen kürzen könnte.. hatte ich damals aus Faulheit nicht gemacht xD
Um flüssiges Scrolling zu ermöglichen, sollte man btw die komplette Umgebungsgrafik als Pictures darstellen. Nur dann kann man wirklich immer pixelgenau in alle Richtungen scrollen.
Ansonsten wird's wie Lachsen gesagt hat, etwas knifflig, da man die PanScreens (oder halt Bewegungen vom Standard-Hero, der den Screen zum Scrollen bringt) mit der Pixellaufgeschwindigkeit synchronisieren muss und nicht wirklich immer scrollen kann, wenn sich der "Pixelheld" bewegt.
Was mir allerdings die meisten Kopfschmerzen bereitete in letzter Zeit, waren feinere Geschwindigkeitsabstufungen als das herkömmliche 4xslower, 2xslower, normal, usw. was bei pixelgenauen Bewegungen etwas zu ungenau ist imo.
Wenn da jemand ne tolle Lösung parat hat, imer her damit xD
@Ryo Saeba
Es ist prinzipiell wie du sagst, nur dass es nicht ganz so extrem sein muss (es kann ruhig mehr sein als 1 Pixel pro Berechnungsschritt).
Ich wollte im Jump'n Run skript damit einfach erreichen, dass ich mit einer Pixel-Bewegung von max. 15 Pixeln pro Berechnungsschritt hinkomme.
Wenn ich da 0,1 Sekunden Wartezeit gewählt hätte pro Berechnungsschritt, wäre die Maximale Bewegungsgeschwindigkeit nicht hoch genug gewesen.
(im endeffekt habe ich glaube ich 3x 0.0 Sekunden verwendet, was also 0,05 Sekunden entspricht)
ein Pixel pro 0.0 Wait entspricht der 2x Slower geschwindigkeit. Schneller kriegt man es also pixelgenau nichtmehr mit dem RPG-Maker hin. Deswegen ist es auch nicht möglich, pixel für pixel zu berechnen, mal ganz abgesehen von der Tatsache, dass es eben SEHR Rechner-Belastend wäre (andererseits würden durch Pixelgenaue Bewegungen viele Extra-Abfragen wegfallen)Zitat:
(wenn ich den Helden in einem PP-Event mit einem 0.0Wait pro Durchlauf um einen Pixel bewege, entspricht das doch afaik schon "normal" Eventgeschwindigkeit oder? .. weiß nicht mehr genau..-> wird dann nähmlich schwierig den Helden schneller laufen zu lassen, da ja bei jeder Bewegung die Kollisionsabfragen anspringen. Das ruckelt dann recht schnell, wenn man den Helden mit 2x oder 4x faster bewegen will).
Im Endeffekt sollte man die Bewegungsscritte so weit einschränken, dass sich der Charakter immer um maximal ein Tile (bzw. zwei Tiles, wenn er sich schräg bewegt) fortbewegen kann. Bewegt sich der Charakter in einem Berechnungsschritt in x oder y-Richtung über 2 Tiles hinweg (was der Fall ist, wenn er sich in x oder y Richtung um mehr als 16 Pixel bewegt), so wird die Berechnung pro Berechnungschritt nochmal deutlich erschwert, weshalb man es vermeiden sollte.
Ansonsten sieht das ganze einfach so aus:
1. Man hat de aktuellen Coordinaten der Figur.
2. Man addiert die aktuelle x- und y-Geschwindigkeit zu den Coordinaten
3. Nun kommen zahlreiche abfragen, die abtasten, ob die Bewegung so auch legitim ist (bei mir artetet das leider immer in ziemlich viele sonderfälle aus, die durch viel rumprobiererei entstanden - eine richtig Saubere Abfrage hab ich hier noch nicht hinbekommen, bisher). Sollte etwas nicht stimmen, werden die neuen Coordinten nochmal umgeändert, damit es passt.
4. Mit diesen Coordianten wird nun schließlich die BEwegung angezeigt.
Der 3. Schritt ist hierbei der mit abstand aufwändigste, ja.
Im Prinzip muss man nur ein etwas tolerantes Pan-Screen-Scirpt schreiben, so kompliziert ist es von der Grundidee her nicht, es benötigt nur viel feinabstimmung, bis man eine weiche, nicht nervige Screenbewegung zustande bekommt. Im Endeffekt geht es nur darum, die SzenX und SzenY-Werte der steuerbaren Figure zu berechnen (die in abhängigkeit zum Bildschirm stehen) und mit hilfe von denen zu bestimmen, ob und wohin der Screen scrollen muss. Einige kleine Tricks dabei sind:Zitat:
Um flüssiges Scrolling zu ermöglichen, sollte man btw die komplette Umgebungsgrafik als Pictures darstellen. Nur dann kann man wirklich immer pixelgenau in alle Richtungen scrollen.
Ansonsten wird's wie Lachsen gesagt hat, etwas knifflig, da man die PanScreens (oder halt Bewegungen vom Standard-Hero, der den Screen zum Scrollen bringt) mit der Pixellaufgeschwindigkeit synchronisieren muss und nicht wirklich immer scrollen kann, wenn sich der "Pixelheld" bewegt.
Der Screen sollte sich nicht bei der aller kleinsten Bewegung sofort bewegen.
Stattdessen sollte es eine kleine Toleranz-Zone geben, die in der Mitte des Screens liegt. Befindet sich der Held innerhalb von dieser, wird nichts gescrollt.
Läuft die Figur in eine Richtung, sollte sich die "Toleranz-Zone" einige Felder VOR der Figur (in Richtung seiner Blickrichtung) bewegen, damit der Bildschirm nicht so weit hinterher hinkt.
Wenn der Held springt sollte die Kamera nicht gleich hochzoomen. Eine sehr gute Lösung (abgeschaut von Yoshi's Island) ist die, dass die Höhe erst dann justiert wird, wenn der Charakter sich auf dem Boden befindet (es sei denn natürlich, er befindet sich ZU nah am Seitenrand, dann muss natürlich sofort nachgescrollt werden)
Mit all diesen Tricks lässt sich auch mit Pan-Screen eine ganz passable Screen-Bewegung erreichen. Es ist imho aufjedenfall die bessere Lösung, als die gesamte Umgebung mit Pictures dazustellen oO (wenn man dies tut, kann man überhaupt nichts mehr mit Events anzeigen, auch keine schwebenden Plattformen usw. und das wäre recht hart)
Achja, und hier das Jump'n Run Skript, von dem ich die ganze Zeit rede, hab mich entschieden es mal hochzuladen:
http://ipx22052.ipxserver.de/rpg-mak.../VP-Fanfic.rar
(die Grafiken der Figur sind btw. auch selber gepixelt - wenn auch die Animation recht derbe von Lenneth aus Valkyrie Profile abgeschaut wurde - war dennoch arbeit :O ... naja, ich denke soviel könnte man eh nicht mit den Grafiken anfangen, dafür sind es zu wenige ^^°... Hintergründe sind btw. von Drake, mit dem ich an diesem als Fanfic geplantem Projekt gearbeitet habe - genauer gesagt sind die aus VP gerippt)
Man kann im Maker auch die Startposition auf eine andere Map setzen (nicht alle funktionieren, aber die letzten sollten schon, irgendwie). Die sind grafisch zwar nicht so schön, dafür sieht man besser, wie gut die Kollision im Skript funktioniert.
C ya
Lachsen
Hey also dein Script Lachsen is ja echt voll geil! Aber: Es ruckelt ein wenig! Nur ein weinig is halt ein wenig zu viel! Ok ja das kann an meinem PC liegen!:rolleyes:
Aber ich fand auch das so wie dus erklärt hast wär doch eigentlich viel mehr möglich! Oder? Also ich hab in meiner simpelanfängernoobmöchtegerngravitation(geiles Wort!:D) die ganzen Pics simpel auf den Hero gesetzt und bissle rumprobiert und eigentlich find ichs gut! (Nein kein Script dafür gibt es noch zu wenig und ich will auch kein Script posten da ich ja der war der ganz am Anfang gefragt hatte!;)) Natürlich ist deine Technick besser von dem System gesehen aber für mein MMX könnt ichs nicht benutzen!(Nein nicht weils mir zu schwer ist!^^) Aber trotzdem geile Idee Lachsen!http://www.multimediaxis.de/images/s.../respekt_2.gif
Ein wirklich tolles Script Lachsen, muss ich zugeben.
An die kleine Verzögerung hat man sich recht schnell gewöhnt, nur gefällt es mir besser, wenn sich der Char in der Luft, beim Springen nicht von selbst nach vorne bewegt, sondern wenn ich dies selbst durch "Drücken nach Vorn" bewerkstelligen muss. (Bei deinem Script muss man ja nachjustieren, wenn man ausversehen zu weit springt, in dem man wieder in entegegengesetzte Richtung drückt). Aber das sind natürlich nur ein paar Klicks und das hat auch nichts mit der technischen Seite des Scripts zutun^^'
Was ich allerdings nicht so gut fand war, dass es mir eher wie ein "Halftile-Movement" vorkam oder? Als ich den Cursor nur ganz leicht antippte, bewegte ich mich, so weit wie ich das mitgekriegt hab, um 8 Pixel?
Ob es auch daran lag, dass ich den Absprungpunkt bei einigen Platformen desöfteren mal verpasst hab? Kann man sich aber sicher dran gewöhnen.
Außerdem wird's auf dem RPG Maker halt auch extremst schwierig das genauer hinzukriegen, wie du ja sagtest allein wegen der Performance.. sind ja auch noch keine Gegner drin.. außerdem glaube ich ja auch stark, dass viele kommerzielle Jump'n'Runs es fast ebenso praktizieren. Eine Genauigkeit von ein paar Millimetern reicht ja eigentlich.
Das Scrolling find ich btw richtig gelungen, zwar kommt es mir manchmal abgestuft vor, aber dafür, dass du nicht pixelgenau scrollst und somit noch Events verwenden kannst, ist es wirklich sehr gut.
Und dann erst die ganzen Bewegungsmöglichkeiten des Chars (Ducken, Schlagen, Rutschen,..) ^.^
Die ganzen beeindruckenden Animationen sind natürlich ein gehöriger Performancekiller, aber mit der eingeschränkten Max-Picanzahl wird es nunmahl schwierig mit "Move Picture" anstatt mit "Show Picture" Befehlen zu arbeiten.
Lief dennoch flüssig bei mir.. (hab allerdings auch einen 2800+).
Wirklich zu schade, dass kein Spiel draus geworden ist -.- aber wenigstens ein tolles Script.
@lachsen:
ziemlich gut das script^^ http://www.multimediaxis.de/images/s.../respekt_2.gif
hier noch kritik =/
1. in den meisten jump n' runs gibt es ja auch noch gegner und z.B. mehrere möglichkeiten einen weg zu gehen wie z.B. bei Asterix & Obelix^^
da kann man ja z.B. bei einem felsen untendrunter weiterlaufen oder auf ihn draufspringen und dort weiterlaufen... (hat sich erledigt wenn ich mir so die anderen maps anschau^^)
2.desweiteren gibt es auch items die sich bewegen wie z.B. in Super Mario World, die sich dann z.B. nach rechts bewegen...
3. und dann noch gegner... also z.B. das man gegner mit ein, zwei schlägen besiegt oder wenn man auf sie draufspringt^^
ich frag mich ob du erklären könntest wie so etwas gehen könnte (2. + 3.)?
aber im großen und ganzem is es ein gutes script ;) läuft sogar flüssig auf meinem pc^^
MfG
LotW89
3. ist ziemlich einfach, du setzt beim Springen einen Switch. Wenn dieser aktiviert ist kriegen die Gegner bei Berührung mit dem Helden Schaden, ist er nicht aktiviert geht der Schaden auf den Helden.
nya, ich poste mal mein Megaman Skript welches ich für den Techkontest im Quatier angefertig habe, das es imo für RPG Maker Studios interessant sein sollte, da er wie ich aus seinen Post's entnehme ein Megamanspiel erstellt. Nya, es verfügt über Pixelmovement, Pixelscrollen, Rennen, Schießen... Leider ist es nie ganz fertig geworden... Inwieweit du die Ressourcen klaust oder sonstiges damit anstellst ist mir eigentlich egal. Viel Spass
http://rapidshare.de/files/11635374/...P_RUN.rar.html
man bräuchte aber trozdem noch ein event das überprüft ob man den gegner berührt hat und z.B. für endgegner wie oft man noch ihn treffen muss... aber das sollte kein so großes problem seinZitat:
Zitat von UhuSchuhu
EDIT: ich habs ma mit normalen charas getestet^^ klappt ganz gut... das mit den items funzt wahrscheinlich auch so
@Ryo Saeba
Wegen der Sprungbewegung: Ich hab mich hier versucht an das Original zu halten: Valkyrie Profile. Dort handhabte es sich mit der Sprungseitwärtsgeschwindigkeit ähnlich (imho sogar etwas unhandlicher xD)
Wegen dem angeblichen "Halftile-Movement": Das hängt damit zusammen, dass beim Gehen aufder Stelle mit maximaler Geschwindigkeit gestartet wird. Das ist eine Sache, die ich an sich ändern könnte (auch ohne großen Aufwand), indem ich einfach eine ganz kurze Beschleunigung am Anfang einsetze, aber auch hier hab ich mich wieder versucht an das Original zu halten.
Wegen der Performance: So schlecht hatte ich die nichtmal in Erinnerung. Auf meinen alten Rechner (etwas über 1 Ghz ) lief das ganze noch recht flüssig.
@RPG Maker Studius
Ich kann dir wirklich nicht übelnehmen, dass du beim Event-Movement bleibst. Das Prinzip an sich wollte ich auch nicht wirklich so kritisieren. Zwar gibt es leichte Einbußen bei der Handlichkeit, dafür ist es halt eindeutig einfacher umzusetzen. So ein PixelMovement-Jump'n Run-Skript ist ein derber Aufwand fürs ganze Spiel und es ist einfach übertrieben damit ein ganzes Spiel auf die Beine zu stellen. (vorallem wenn man nicht den Hang zur Technik hat)
@LotW89 Das was du aufzählst könnte möglich sein, wäre aber im Endeffekt nicht in dem Projekt integriert worden (in den meisten Fällen), da die Vorlage einfache eine andere war ^^°
Das ganze ist halt nur ein unvollständiges Skript indem nur die Grundlagen grob integriert sind.
@UhuSchuhu Das geht so einfach leider nicht, weil die automatische Heldenberührung zumindest in meinem Skript nichtmehr wirklich funktioniert
Soviel von meiner Seite
C ya
lachsen
Oh sry Lachsen kamm falsch rüber ich habe auch nicht geglaubt das du das System schlecht machen wolltest!:) Ich wollt dir eigentlich nur sagen das dein Script klasse ist aber zu kompleziert für mich! XD
:D
Schreib doch dazu noch ein Tutorial Lachsen. Am besten mit Beispieldemo. Damit könntest du sicher das JnR Genre für den Maker ins Rollen bringen.
BTW: Vels. war großartig. Vorallem der Kampf zwischen K. und G. Großes Kino ^^ War irgenndwie sehr emotional. Hoffe der Rest wird genau so geil... Und Lachsen... ICH WILL WEITERSPIELEN!
PS an Lil_Lucy: Bist du in real genauso scharf wie dein Avatar? :p