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.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Ah,verstehe
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 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)
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
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 inklusive
Eventgrafiken eh unter dem Picturezeug befinden würde.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
Ah,ich glaub ich hab ne gute Idee:
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
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 ausgesehen
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,
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 ablaufen
muss und nicht hintereinander. Möglicherweise mache ichs mir zu schwer aber es war schlimm
genug, diese Variante auszuplanen.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
WENN DAS funktioniert revive ich mein Kirby-Spiel, dass es damals zur Demo brachte :'D
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
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
In diesem Fall irritiert die Tatsache den Zuschauer ein bisschen, dass sich die Map selbst nur
Feldweise bewegt, was zu meinem Erstaunen sogar flüssig von der Hand geht.
--
Solange es hier falschzitierende Ärsche gibt, dulde ich keinerlei Zitatboxen, die von mir sein sollen.
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.
--
Immer auf dem neuesten Stand sein: Der Blog von RosaArts
Lust auf eine Runde Smalltalk in gemütlicher Runde: RosaArts - Das Unterforum des RPG-Atelier
Hallelujah! Endlich gibt es meine Bücher auch auf AMAZON!
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?
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.
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.
Berechtigungen
Zitieren
