Druckbare Version
Hallöle!
Hab mir gerade ne Idee für ein Jump and Run ausgetüftelt.
Und stoße jetzt schon auf ein Problem:
wie bekommt man Pixelmovement hin,ohne dass die Kamera sich zu schnell bewegt?
Wenn man nämlich die Richtungstasten gedrückt hält,kommt die Figur mit der Kamera nicht mit,d.h. dass die Figut ausserhalb des Bildschirmes landet.
Wie kann man dieses Problem beheben?
Also so,dass die Figur immer in der Mitte ist.
Ich habe kürzlich sowas selber hingestellt, es ist etwas arg komplex,
im Moment füllt das ganze bei mir 15 Events die fast alle immer parallel
ablaufen, und das noch ohne korrekt funktionierendes Springen und
all solche Sachen, daran zerbreche ich mir immernoch den Kopf.
Bei Pixelmovement ist eine Sache jedenfalls erstmal wichtig:
Deine Map muss zum Picture werden, sonst kannst du einen ordentlichen
Pan Screen absolut vergessen. Bewegt sich nun deine Figur aus der
Mitte raus, korrigierst du die Position vom Mapbild mit, bis es wieder
übereinstimmt. Gleichzeitig musst du berechnen, welchem Feld auf der
ursprünglichen Map deine Bildposition entspricht. Ob du an einer Stelle
dann laufen/vorwärts/rücktwärts/springen/fallen/kriechen kann, lässt
sich am besten mit Terrain-IDs machen, die auf einer unsichtbaren Map
im Hintergrund auf den Feldern angebracht sind und du über Save Terrain
ID dir von der berechneten Feldposition greifst.
~MitteVerlassen: Beachte, dass Maps auch Ränder haben, du musst
immer im Blick haben, wie weit dein Mapbild denn schon gescrollt ist und
das Korrekturverfahren an den Rändern abstellen, das ist ein bisschen
Mathe und Nachdenken.
Ah,verstehe:D
Und das Mit dem Rand - ich glaub das kann man "umgehen",indem man einfach die Map selber größer macht (bspw. mit Felsen) - sieht zwar nicht so schön aus,ist aber denke ich etwas sparsamer an Code.
Ich stoß da auch gerade auf ein Problem:
Wie ist denn das bei anderen Charas und Gegnern,die auch Picture-Basiert sind?
Genauer bitte... was soll mit denen sein? was ist das Problem?Zitat:
Zitat von Engel der Furcht
Wegen der Bewegung? der Kollisionsabfrage? etc.?
Wenn sich die Map,anstatt die Character bewegen,dann bleiben doch andere Pictures stecken.
Genaugenommen werden diese genauso dargestellt wie der Spieler selbst.
Da nun aber ein JnR-Level üblicherweise ziemlich gross ist, versuche dir
im Code imaginäre überlappende Rechteckbereiche auf die Map zu zeichnen,
in deren Bereichen du die Objekte spawnst, das erspart dir ne Menge Ärger
wenn du um die 100 Interaktionsobjekte in einer Stage brauchst und wenn
die alle gleichzeitig aktiv sind, das Spiel wahrscheinlich auch auf einer starken
HighEnd-Kiste laggen wird, vergleichbar mit einem Politiker der aus dem Ähm-
Sagen gar nicht mehr rauskommt und sein eigentliches Anliegen vergisst.
Jedenfalls würde ich wohl Events platzieren die Platzhalter für die ganzen
Sachen/Typen/Viecher sind und dann ihre Position immer relativ zum Mapbild
berechnen etc etc etc, es ist ein endloser Wirrwarr kranker Technik.
Die Bewegung dieser würde ich eher noch auf Felderweise beschränken, da es
sonst vielleicht zuviel Arbeit wird, ausser es ist ein CPU-Partner mit eigener KI
(ja sowas gibt es wirklich in einem Spiel)
Ich glaub ich hab nen Logikfehler drin -
Die Map ist ja in einem Picture gespeichert.
Die "richtige" Map vom Maker aus bewegt sich ja aber nicht mit.
Ich mein damit,dass sich die Rastermap still bleibt,während sich die PictureMap nur beim Drücken von Links/Rechts bewegt.
Du kannst die unsichtbare Map unter dem Picture ja versuchen, mitzubewegen
wenn du es brauchst, wenn du berechnen kannst wie sich die Positionen
unterscheiden, je nach Unterschied den Pan Screen mit 400% auslösen,
um die Map möglichst fix zurechtzuschieben, denk ich mal.
Das muss sie auch eigentlich nicht, da sich der ganze Mapkram inklusiveZitat:
Die "richtige" Map vom Maker aus bewegt sich ja aber nicht mit.
Eventgrafiken eh unter dem Picturezeug befinden würde.
Ah,ich glaub ich hab ne gute Idee:Zitat:
Zitat von MagicMaker
Wenn man nach links und rechts drückt,verschiebt sich die Map(natürlich umgekehrt,wenn man nach links drückt scrollt die Map nach rechts)
So. Gleichzeitig werden die Koordinaten des Spielers verändert. Aber ohne,dass sich das Bild des Spielers mitbewegt.
Hört sich fast an, als hättest du den System-Spieler, den man in einem normalen Projekt direkt steuert und den Graphik-Spieler, den man sieht, noch nicht getrennt - für pixelgenaues Movement brauchst du das.
Aber generell bin ich der Meinung, der 2k/2k3 taugt dafür nicht, was ist dein Grund, nicht auf den XP umzusteigen bei dem das mit Ruby wesentlich besser geht weil man eben nicht gegen unnötige Einschränkungen kämpfen muss?
http://npshare.de/files/a42c4ff9/Mein%20Film.wmv
Bisher ohne Kollision aber das schaff ich auch noch
Danke an Shadowsoul für die ganzen hilfreichen Tipps:A
Woah, das sieht cool aus. Da bekommt man Lust selbst ein JnR zu basteln :3
Ganz einwandfrei, hoffe dass du es wenigstens bis zur einer Demo schaffst.
Nettes Filmchen. Wenigstens funktioniert bei dir schonmal ordentliches Hochspringen
(mal abgesehen vom Fallen, das bei mir zwar geht aber irgendwie noch hapert), in meinem
Spielchen kann ich das bisher ziemlich vergessen.
Ich bin dabei auch gerade in einer Sackgasse,weil die Animation nicht zuende geführt wird (weil bei der Anim ein Event gecallt wird und somit die Anim nicht zuende geht...)
Werd ich glaub ich über PP machen...
das hier stimm ich nicht ganz zu, denn es funktioniert auch ziemlich gut einem tileset zu benutzen, halt braucht man dafür eine andere methode. Ich hab selber ein rm2k3 pixel basiertes platformer gemacht, und dabei hauptsächlich tileset benutzt für dem map. Am ende hat es etwa so ausgesehenZitat:
Zitat von MagicMaker
http://www.youtube.com/watch?v=En2IY9eDMmc
Mein methode ist aber ein bisschen anders. Da ich ja tilesets benutze, muss ich den screen so panorieren dass es immer die aktuelle ort am map zeigt. Wenn sich mein pixel basiertes figur bewegt und an dem rand kommt wo er anfängen zu scrollen soll, wird das picture des char einfach so so viel zurück geschoben bevor das bild selber "refreshed" wird solange man noch am scrollen ist, wo wie viel zurück geschoben wird abhängig von der schnelligkeit der bewegung ist.
wichtig ist auch dass der held zum panorieren benutzt wird, da "pan screen" nicht mit 2 unterschiedlichen schnelligkeiten panorieren kann, bzw. man muss eines für horizontales panorieren nehmen, und das andere fürs vertikale. Ich benutze terrain codes für den zweck davon herauszufinden ob der char im luft oder aufm boden steht, oder auf was sonstiges.
der nachteil von diesem methode liegt darin dass wann immer es in einer richtung panoriert wird, wirds immer einen ganzen "tile" panoriert, also könnte man sagen dass es etwas komisch aussieht wenn man auf die pixelbasierte bewegung denkt. Ein anderes problem, dass ich zumindest hatte, ist dass wenn man z.b. stirbt und an einem ort zuruck will musste ich zu dem ort zuruck scrollen, was auch mit höchster geschwindigkeit ein bisschen dauern kann in einem grossen map und man weit vom "respawn" punkt stirbt.
Ist aber bestimmt möglich umzugehen, hab halt selber nicht so viel energie darauf verwendet es herauszufinden.
vorteile dieser methode ist dass man nicht seinen ganzen maps zum pictures machen muss, und es ist wesentlich einfacher chars als feinde zu benutzen, falls picture basierte feinde nicht sein muss. bei diesem methode reicht 10 pp events für den mechanik selber, wobei ich sagen muss dass ich nicht weiss ob man doch weniger schaffen kann bei dem anderem methode die hier erwähnt wird.
ps. entschuldige schonmal für die bestimmt vielen artikel fehler und sonstiges die sicher in dem post drin ist.
Ich habe mich auch etwas falsch ausgedrückt, ich erreiche damit dass die Map ein Picture ist,Zitat:
der nachteil von diesem methode liegt darin dass wann immer es in einer richtung panoriert wird, wirds immer einen ganzen "tile" panoriert, also könnte man sagen dass es etwas komisch aussieht wenn man auf die pixelbasierte bewegung denkt.
dass ich nicht auf "Pan Screen" angewiesen bin, der nur felderweise funktioniert. Naja vorläufig,
ich habe noch Destiny Version 2 in Erwartung. Mit Bananen-Joe habe ich rausgefunden, dass
die Position des Screens pixelweise manipulierbar ist. Wenn das integriert ist und ordentlich
geht kann ich auf die Mapmethode zurücksteigen.
Ich habe es auf viele Events ausgeweitet bei mir, im Moment 15, da vieles zur selben Zeit ablaufenZitat:
wobei ich sagen muss dass ich nicht weiss ob man doch weniger schaffen kann bei dem anderem methode die hier erwähnt wird.
muss und nicht hintereinander. Möglicherweise mache ichs mir zu schwer aber es war schlimm
genug, diese Variante auszuplanen.
WENN DAS funktioniert revive ich mein Kirby-Spiel, dass es damals zur Demo brachte :'DZitat:
Ich habe mich auch etwas falsch ausgedrückt, ich erreiche damit dass die Map ein Picture ist,
dass ich nicht auf "Pan Screen" angewiesen bin, der nur felderweise funktioniert. Naja vorläufig,
ich habe noch Destiny Version 2 in Erwartung. Mit Bananen-Joe habe ich rausgefunden, dass
die Position des Screens pixelweise manipulierbar ist. Wenn das integriert ist und ordentlich
geht kann ich auf die Mapmethode zurücksteigen.
Zum Video:
Ich weiß nicht, aber in dem Video sah man nie wirklich, dass es Pixelmovement war. KA wieso,
aber es sah alles genauso aus, wie mit TileMovement :'D
Finde es aber trotzdem toll, dass eine so rießige Map scheinbar flüssig läuft. Damit ist die
Methode ressourcenschonender wie meine damals :'D
In diesem Fall irritiert die Tatsache den Zuschauer ein bisschen, dass sich die Map selbst nurZitat:
KA wieso, aber es sah alles genauso aus, wie mit TileMovement :'D
Feldweise bewegt, was zu meinem Erstaunen sogar flüssig von der Hand geht.
Zur Verdeutlichung,dass es Pixelmovement ist:
http://npshare.de/files/38d6175c/Mein%20Film.wmv
(Es stockt nicht,weil die Tastenabfrage nicht funktioniert - ich habs extra gemacht,damit man sieht,dass man sich pixel für pixel bewegen kann)
Ich hab die Methode gewählt,dass der Spieler in der Mitte verankert ist,es bewegt sich also die Map,nicht der Spieler.Koordinaten des Spielers werden aber dennoch genutzt,um Kollisionen verfügbar zu machen.
Ich meinte nicht dein Video, EdF. ^^
Da sah man es doch sehr deutlich.
Weisst du obs auch noch möglich ist der "pan screen" so zu manipulieren dass es möglich ist ihn zwei unabhängige geschwindigkeiten zu erteilen, bzw. für horizontale und vertikale richtung?Zitat:
Zitat von MagicMaker
Sonst wird man immernoch auf dem hero zu benutzen angewiesen sein fürs scrollen in die eine richtung.
Liegt wahrscheinlich daran, wie schon erwähnt wurde, dass der es nur feldweiser gescrollt wird, und der qualitet des video ist auch nicht ganz toll, was wahrscheinlich auch dazu beiträgt es schwieriger zu erkennen macht.Zitat:
Zitat von Rosa Canina
Der char muss naturlicherweise auch ein geschwindigkeit haben der zu dem scrollen passt, was es möglich auch als tilemovement aussehen lässt.
Wenn man aber genauer hinguckt kann man schon erkennen dass es pixelmovement ist, ins besondere an das springen.
Und auch wenn es etwas schwierig zu sehen sein soll ist es umso weniger schwierig es zu fühlen wenn man es selber spielt.
Aber ja, ist schon etwas weniger ästhetisch als dem picture scroll variant.
Oh, eine Pixelmovement-Diskussion. Wieso habe ich die übersehen? Hätte so gerne auch mitdiskutiert! :(
Naja, vielleicht ist es ja noch nicht zu spät.
Habe jedenfalls auch mal ein Pixelmovement-System im RPG Maker gemacht, zu sehen in diesem Video ca. ab 1:00:
http://www.youtube.com/watch?v=yJTUo5xXvTc
Das ganze hat noch ziemlich viele Bugs und ist bei weitem noch nicht perfekt. Irgendwann werde ich das mal komplett neu machen und all meine Erfahrung nutzen um ein wirklich atemberaubendes System zu kreieren. Wird nur wohl nicht all zu bald sein. :P
Wie ihr seht (oder wahrscheinlich auch eher nicht, weil es in diesem Video noch überhaupt gar nicht zutrifft), habe ich das Scrolling-Problem einfach gelöst, indem ich jede Map genau einen Bildschirm groß gemacht habe. Es gibt trotzdem noch Scrolling in mit diesem System, was im Video nicht zu sehen ist. Das ist aber nur ein Scroll von Raum zu Raum, was mich damals auch auf die Idee gebracht hatte, daraus ein Zelda-Spielchen zu machen.
Bei Jump 'n' Runs ist das ganze natürlich nochmal etwas komplizierter, weil man da noch Schwerkraft ist und auf Scrolling eigentlich auch nicht wirklich verzichten kann.
Ich bin jetzt gerade dabei,die Kollision für den Boden zu machen.
Das ist das Event für die Terrainüberprüfung.Zitat:
Zitat von EasyEventExporter
Variable 7,8 sind X/Y für Terrain,9 die ID.
Variable 10 ist die sogenannte "StateID",die gibt an,wie sich Lara verhält(Laufen,springen...)
StateID6 bedeutet Runterfallen
StateID0 bedeutet Stehen.
Das ganze ist aber glaube ich nicht ganz relevant.
Jedenfalls,
wenn die olle Kuh runterfällt, stoppt sie erst 5-10 Pixel unter der eigentlichen Grenze und fällt in den Boden hinein.
Wie mache ich nun,dass das Weib wirklich auf der Graskante steht?
Hier zur verdeutlichung.
http://npshare.de/files/b83c20e3/Mein%20Film.wmv
Hat vielleicht was mit dem Show-Picture-Befehl zu tun. Der benutzt ja immer den Bildmittelpunkt als Refferenz. Da könnte es bei Berechnungen schonmal passieren, dass ein Bild nicht ganz da landet, wo man es haben wollte.
Das Bild des Spielers ist immer in der Mitte (160;120,bei Animationen abweichend)
Die Koordinaten sind aber immer richtig und das bild sitzt auch richtig.
nur jedes frame zu checken ist nicht schnell genug um rechtzeitig zu stoppen, ausser der char mit nem geschwindigkeit entsprechend "3: half normal" runterfällt.
Es gibt wohl 2 lösungen auf das problem die mir einfällt. Entweder du guckst einige pixel vorraus beim jedem check, oder du lässt ein event dich wieder auf dem korrekten höhe korrigieren bevor das bild des spielers wieder refreshed wird.
Was noch ein Problem sein könnte (war auch bei meinem Pixelmovement damals so): Du benutzt ja um die Terrain ID zu bekommen Map-Koordinaten und nicht Screen-Koordinaten/Pixel-Koordinaten. Da aber ein Tile ja nunmal 16x16 Pixel groß ist, könnte es vorkommen, dass das Spiel, obwohl du eigentlich schon zu 1/3 bis 1/2 auf einem bestimmten Tile stehst, immer noch DIESES Tile statt des Tiles darunter abfragt. Verstehst du, wie ich meine? Also das Tile drunter wird quasi erst dann abgefragt, wenn du schon ganz oder fast ganz auf dem Tile darüber draufstehst. Ist bisschen schwer zu erklären. Bei mir war es aber anfangs ähnlich. Oben und links machte der Held immer haargenau vor der Wand halt, unten und rechts hingegen konnte er bis zu einem Tile in die Wand hineinlaufen. Ich weiß nicht mehr ganz genau, wie ich das gelöst hatte. Ich glaube ich hatte irgendwie Berechnungen benutzt, um in bestimmten Fällen das richtige Tile zu bekommen.
Ist eine Ewigkeit her, dass ich hier was gepostet habe. Aber da mich das Thema so sehr interessiert, erzähl ich mal von meinen Erfahrungen. Aber vorher fange ich mit etwas Eyecandy an. Ich hatte mal geplant Neo23 bei einem Megaman X Fangame auf dem Maker zu helfen und ihm ein auf Pixelmovement basierendes Jump and Run Skript zu erstellen. Fertig geworden ist das zwar nie und wird es wohl auch nicht mehr, aber ich habe hier noch ein Video von damals auf der Platte rumfliegen, das irgendeinen Zwischenstand dokumentiert hat.
>Video<
Dem Anschein nach konnte man bereits Laufen, Springen, Dashen, die Wand runter rutschen und von der Wand abspringen. Ich bin mir ziemlich sicher, dass ich auch schon den Air-Dash irgendwann mal umgesetzt hatte, aber das ist jetzt auch egal.
Als ich angefangen habe daran zu arbeiten, wollte ich, dass man genauso wie bei meinen Tile-Movement Systemen sich mittels Terrain IDs eine Map ganz normal zusammenklicken kann. Wenn man aber Picture-Koordinaten verwendet, kann man die Terrain ID nicht einfach so auslesen, da diese Koordinaten immer den aktuellen Bildausschnitt als Bezugssystem wählen. Das Problem habe ich gelöst, indem ich mir selbst einen Bezugspunkt definiert habe. Ich habe in die obere Linke Ecke der Map ein Event gesetzt, das Nullpunktevent. Wenn ich nun die genaue Position von Megaman abgefragt habe, habe ich einfach die Differenz zwischen den Picture-Koordinaten des Nullpunktevents und den Picture Koordinaten von Megaman gebildet. Diese Differenz geteilt durch 16 entspricht dann genau den Tile-Koordinaten auf denen Megaman gerade steht. Dadurch ließen sich im wesentlichen wieder Terrain IDs nutzen.
Ein zweites Problem bestand im Mitscrollen der Map. Wenn man die Map einfach mit Pan Screen bewegt, behält man die aktuelle Position im Bezug zum Bildausschnitt bei. Man bleibt also nicht in der Bildmitte, sondern wird durch Pan Screen einfach mitgeschoben. Das habe ich gelöst, indem ich bei jedem Schritt, den die Map mitgescrollt ist, die Position von Megaman um 16 Pixel in die entsprechende Richtung verschoben habe, so dass das Picture in der Bildschirmmitte bleibt. Dazu hab ich einen Pan Screen Schritt für den Movement Speed Normal in 8 0,0 Waits unterteilt und nach(oder vor? Weiß ich nicht mehr.) jedem Wait die Position um 2 Pixel korrigiert. Dadurch sieht das ganze flüssig aus und funktioniert wunderbar. Worauf man dabei achten muss, ist diese Positionskorrektur zu deaktivieren, sobald die Map nicht mehr scrollt, also am linken und rechten Bildschirmrand beispielsweise.
Kein Problem ist es meiner Meinung nach, dass Pan Screen nicht pixelgenau funktioniert. So lange man sich flüssig in eine Richtung bewegt, fällt es gar nicht auf. Und wenn man aus welchem Grund auch immer sich wirklich nur langsam Pixel für Pixel fortbewegt, stört es auch nicht wirklich, zumindest mich nicht. Eher problematisch ist, dass man sich dadurch auf bestimmte Bewegungsgeschwindigkeiten reduziert. 2 Pixel (Normal) oder 4 Pixel (2xFaster) pro 0,0 Wait geht, aber 3 Pixel pro 0,0 Wait ist nicht wirklich gut umzusetzen. Man kann natürlich einen Char auch mal um 3 Pixel pro 0,0 Wait bewegen, aber als kontinuierliche Bewegungsgeschwindigkeit ist das nicht geeignet.
Ansonsten konnte ich das meiste völlig analog von meinem Tile-Movement Jump and Run Skript übernehmen. Hier und da gab es noch ein paar Dinge zu beachten, zum Beispiel bei der Landung auf dem Boden: Man muss ja auf dem Bodentile immer wieder auf der gleichen Pixelreihe landen, aber da war die Modulusfunktion mein Freund. Außerdem verändert sich die Geschwindigkeit im Sprung und im Fall. In Y-Richtung bewegt man sich zunächst mit 4 Pixel pro 0,0 Wait, dann 3, dann 2, dann 1 und dann fällt man genauso wieder nach unten. Dadurch ergibt sich eine schöne, rundwirkende Flugbahn und nicht so ein hässliches Dreieck wie bei Tile-Movement. Das muss natürlich alles entsprechend im Sprungevent angepasst werden, aber vom Prinzip her ist es völlig analog zum Tile-Movement.
Nagut, wenn mir noch was einfällt, trag ich es nach. Ich find's cool, dass hier Leute immer noch an Pixelmovement auf den alten Makern rumwerkeln. Vielleicht packt es mich irgendwann auch noch mal.
Ja, ich glaube ähnlich habe ich es auch bei mir gemacht, um zu verhindern, dass der Held in die Wand läuft. Und ich hatte übrigens - genau wie du - auch Probleme mit ungeraden Laufgeschwindigkeiten. Den Fehler habe ich bisher noch nicht ausfindig gemacht. Was passiert ist jedenfalls, dass mit 2 und 4 ppf alles super funktioniert, mit 3 ppf hingegen kommt es des öfteren mal vor, dass der Held, wenn man beispielsweise diagonal läuft, einfach in eine Wand reinläuft. Solange man die Geschwindigkeit aber nur auf gerade Werte gesetzt hat, war das kein Problem.Zitat:
Zitat von Jonn
Das liegt daran, dass die Umgebung weiterhin ein 16px-Raster hat.
Du kannst den Helden also 1, 2, 4 und 8 Px gleichzeitig laufen lassen, aber KEINE andere
Zahl. Jedenfalls nicht im Normalfall, mit Tricks geht das sicher auch, ist aber halt weitaus
aufwendiger.
Da mich das Thema sehr interessierte, habe ich mich auch mal rangesetzt... und etwas
hinbekommen... yeah. Nur ohne Map-Scrolling bislang XD
Aber ich habe KA ob das EdF helfen könnte, da der Code wirklich... komplex ist.
Das seltsame ist aber, dass ich eben diesen Fall (ungerade Pixel) in meinem Script speziell behandelt hatte. An und für sich funktioniert die Kontaktabfrage mit Wänden ja (solange man nicht 16 oder mehr Pixel auf einmal geht). Nur wenn man diagonal läuft, taucht dieser Fehler oftmals auf.