Alles auf dem Maker ist möglich

[Kynero]

Genau das meinte ich. Er hatte nur das "NIEMALS" so betont. Machbar/ spielbar bleibt es mMn weiterhin.

...

Jap, weil ich nicht denke das jemand jemals auf dem normalen Maker ein Jump'n Run schaffen kann, was sich genauso flüßig spielt wie ein Mario Jump'n Run. Programmieren könnte man ein Jump'n Run darauf schon, aber das Resultat selber habe ich noch nirgends als wirklich "flüssig" empfunden. Wie Kelven schon sagte sind dafür viele Dinge auf dem Maker einfach zu ungenau. Das wirkt sich schon ziemlich störend auf's Gameplay aus, anders als bei einem Mario Jump'n Run.
Und ein ungenaues Spiel ist mMn nicht wirklich spielbar...

Nochmal etwas anders ausgedrückt: Der Maker ist für das Genre einfach zu ungenau und deswegen wird es auch NIEMALS Niveau da haben.

[makenshi]

Jap, weil ich nicht denke das jemand jemals auf dem normalen Maker ein Jump'n Run schaffen kann, was sich genauso flüßig spielt wie ein Mario Jump'n Run.

...

Einspruch.
Wie gesagt, am Montag kann ich mal in meinem Skriptordner herumwühlen.
Da hatte ich ein Pixelmovement von Lachsen herumliegen was sich sehr sehr akkurat steuern ließ. Darum kann ich auch hier nur sagen: Es geht schon. Es ist einfach nur ein Aufwand der auch die entsprechenden Fähigkeiten und Erfahrungen benötigt.

@ssj5000
Gebe ich dir fast völlig recht. Nur in dem Punkt "dass es sinnlos ist ein Spiel zu erstellen von dem man schon weiß das es nicht wirklich gut wird" nicht. Mit so einem Gedanken fängt man kein Spiel an. Schon vor der Erstellung sollte klar sein welche Beschränkungen in Kauf genommen werden müssen. Und bei diesen sollte abgewägt werden ob es sinnig ist das entsprechende Genre mit diesen umzusetzen.

Nur weil man gegen die Engine arbeitet, muss kein schlechtes Spiel dabei rauskommen.

[Davy Jones]

Nur weil man gegen die Engine arbeitet, muss kein schlechtes Spiel dabei rauskommen.

...

Dito, der Macher von U.S.G. - A New Beginning hats mit dem XP schon vorgemacht. Er hat die RPG-Sparte übersprungen und etwas völlig anderes gestaltet, nämlich einen Bullet Hell-Shooter (Danmaku):

http://www.youtube.com/watch?v=PgBblgK2WCU

Auf dem 2k/2k3 sieht sowas leider anders aus, die Dinger sind halt zu altbacken als dass man etwas gescheiteres als Adventures/RPGs drauf zaubern könnte. Evtl. noch Jump 'n Runs, aber da sind halt die makerinternen Einschränkungen mistig =P

Mal sehen wie sich der Action Game Maker schlägt, soll ja im Dezember in Japan erscheinen. Ob sich Enterbrain zu einer englischen Version durchringt, bleibt allerdings abzuwarten~

[Hisoka]

Dito, der Macher von U.S.G. - A New Beginning hats mit dem XP schon vorgemacht. Er hat die RPG-Sparte übersprungen und etwas völlig anderes gestaltet, nämlich einen Bullet Hell-Shooter (Danmaku):

http://www.youtube.com/watch?v=PgBblgK2WCU

Auf dem 2k/2k3 sieht sowas leider anders aus, die Dinger sind halt zu altbacken als dass man etwas gescheiteres als Adventures/RPGs drauf zaubern könnte. Evtl. noch Jump 'n Runs, aber da sind halt die makerinternen Einschränkungen mistig =P

Mal sehen wie sich der Action Game Maker schlägt, soll ja im Dezember in Japan erscheinen. Ob sich Enterbrain zu einer englischen Version durchringt, bleibt allerdings abzuwarten~

...

Natürlich galt meine Aussage nicht für alle. Aber eben für den großteil der "Ich treibe den Maker an die Grenzen" Leute. Da geht es eben um die technischen Sachen und der Rest bleibt auf der Strecke.
Es ist eben klassischerweise so das irgendwas auf der Strecke bleibt wenn man sich zu sehr auf einen Punkt konzentriert. Wenn das nicht passiert, dann investiert man meist soviel Zeit ins Projekt das es eine Ewigkeit dauert bis es fertig wird. Dann ist aber wieder die Gefahr, das man das Projekt abbricht.
Daher reicht es meist nur für Minispiele. z.B. einen Vertical Shooter

Gehe mal beim Shooter beinahe davon aus das in der Entwicklung so aufwendig war, das man mit dem Gamemaker oder Blitz gleich 2 oder 3 Spiele der Sorte hätte machen können. (hat da jemand Daten?)

[The_Burrito]

Ist mit dem RMXP gemacht worden. War daher sicherlich nicht so aufwendig wie es mit dem RM2k/3 gewesen wäre. Genaue Daten über die Entwicklungsdauer kann ich allerdings nicht nennen.

[R.D.]

Ist mit dem RMXP gemacht worden. War daher sicherlich nicht so aufwendig wie es mit dem RM2k/3 gewesen wäre. Genaue Daten über die Entwicklungsdauer kann ich allerdings nicht nennen.

...

Nicht so aufwendig wie, mit dem 2k/3? Sicher, aber immernoch ziemlich viel Arbeit.
Als Progger kann man sich das ungefähr vorstellen^^

[The_Burrito]

Jedes gute Spiel ist viel Arbeit.

[CapSeb]

Wie gesagt, am Montag kann ich mal in meinem Skriptordner herumwühlen.
Da hatte ich ein Pixelmovement von Lachsen herumliegen was sich sehr sehr akkurat steuern ließ.

...

Meintest du das Script, dass Lachsen in --> diesem Thread <-- beschrieben hat? Leider sind die Links dort veraltet.
Ich hab auch ein Lachsen-Script auf dem Rechner, aber weil bei dem verlinkten Thread von Plattformen geredet wird, dürfte das etwas anderes sein.

Um das mit diesem Thread hier zu verbinden - man kann an Lachsens Beschreibungen sehr gut sehen, was mit ordentlichem Aufwand machbar ist. Viele geben schon weit früher auf und sagen es ist unmöglich.


CapSeb

[makenshi]

Ja, exakt das Skript meine ich.
Leider habe ich es auch nicht mehr in meinem Skriptordner.
Ich könnte mich aufregen das ich das gelöscht habe.

Als alternative Referenz kann ich das hier bieten.
Ist ein Megaman J&R Pixelmovement Skript von Zeph. Auch sehr gut
meiner Meinung nach.

Gelenkt wird mit den Pfeiltasten, mit Numpad 0 kann man schießen und Numpad ,/Entf wird gesprungen.

[R.D.]

Man könnte ihn ja mal fragen, ob er es noch hat^^

@Script, gefällt mir schon mal sehr gut^^

[elsen]

Ja, Lachsens Script würde mich auch interessieren, nachdem ich mir den Thread da mal durchgelesen habe =D

@ Skript von Zeph: Stimmt, da haben wir ja nen Pixelmovement-beispiel...
Nur: Warum sollte man es sich mit Pixelmovement so komplieziert machen, wenn es mit Tilemovement genauso "flüssig" aussieht? Das Script beinhaltet eher nur einen komplizierteren Weg, der nicht mehr als dasselbe bringt... Wenn Geschwindigkeitsunterschiede ins Spiel kommen (beim Sprung, fallen, etc.), dann würde es damit schon wieder ganz anders aussehen... (aber das ist wirklich alles andere als mal eben schnell gemacht ^^').

greetz!
elsen =)

[R.D.]

lol

Bitte, mit eventmovment, bekommst NIE, NIE so ein gutes Pixelmovment hin.
Ich glaube da fehlt dir die Erfahrung oder, denn Pixelmovement ist mit Tiles schlecht möglich.

das wird ein, wie schon gesagt wurde -.- Up/down(Left/Right), was völlig daneben aussieht und meißt total kantig zu spielen ist, da es sich eben nur auf Tiles bewegt, und nich so flexibel wie ein Bild ist.

[elsen]

denn Pixelmovement ist mit Tiles schlecht möglich.

...

Hat ja niemand behauptet, vor allem, da es nicht geht xD

Ich habe mich auf das Script bezogen und dort spielt es sich nicht sehr anders als meins, mit Tilemovement.. Sicher gibt es Unterschiede, aber die heben sich dort nicht zu sehr raus.
Springen läuft vllt ein wenig flüssiger dort, aber eben nur ein wenig, weswegen ich nicht so einen großen Aufwand für Pixelmovement betreiben würde.
Zweck und Nutzen stehen da eindeutig im falschen Verhältnis zueinander!
[EDIT]Die wirklich flüssigen Seitwärtsbewegungen (sowohl beim Laufen, als auch beim Springen), die du mit Sicherheit meinst, sind natürlich nicht mit Tilemovement möglich, aber auch auf die war meine "Verhältnisaussage" bezogen... vllt ist nur nicht angekommen, dass ich mich auf die Gravitation bezogen habe![/EDIT]^^

greetz!
elsen =)

[makenshi]

Naja, ich denke das man schon einen deutlichen Unterschied bemerkt.
Auf Tilemovement wird es dir unmöglich sein eine Bewegung zu setzen die unter 16 Pixel ist. Genau so schaut es bei den kontrollierbaren Sprüngen aus. Du kannst hier immerhin kurz oder lang springen. Bei einem Tilemovement wärst du wieder an die Kästchen gebunden.

Wenn du also ein Tilemovement im Vergleich heranziehst ist es schon ein ziemlicher Unterschied. Zudem Zeph ja auch nur die Basis hergestellt hat. Und diese Basis ist schon einem Tilemovement klar überlegen. Restliche Erweiterungen sind dann auch nur eine Frage der Zeit.

[Phno]

denn Pixelmovement ist mit Tiles schlecht möglich.

...

Kommt auf die Dimensionen des CharSets an. 16x16 funktioniert rein theoretisch auch flüßig.

[elsen]

Auf Tilemovement wird es dir unmöglich sein eine Bewegung zu setzen die unter 16 Pixel ist. Genau so schaut es bei den kontrollierbaren Sprüngen aus. Du kannst hier immerhin kurz oder lang springen. Bei einem Tilemovement wärst du wieder an die Kästchen gebunden.

...

mh.. Technisch wird man wohl weiterhin an die Terrain IDs gebunden sein, welche ja den Kästchenabstand haben (ja, faszinierend nicht?^^) aber es stimmt schon, damit hat man halt eine Grafisch angenehmere Lösung....

[makenshi]

mh.. Technisch wird man wohl weiterhin an die Terrain IDs gebunden sein, welche ja den Kästchenabstand haben (ja, faszinierend nicht?^^) aber es stimmt schon, damit hat man halt eine Grafisch angenehmere Lösung....

...

Japp, nur ist das ja relativ wurscht. Das bezieht sich dann ja lediglich auf ein Kästchen Terrain. Die Bewegungsfreiheit des Charakters ist dann trotzdem von diesen losgelöst. Oder wolltest du auf etwas anderes hinaus?

@Phno
Japp. Bei der Demo vom Tastenpatch ist ein imo recht gutes "tilebasiertes" Movement. Afaik war es jedenfalls "tilebasiert". Man merkt jedoch auch bei einem entsprechenden Charset das man sich nicht pixelweise bewegt.

[CapSeb]

Wie sieht das eigentlich mit der Kollisionsabfrage aus? Terrain-ID wurde hier genannt, aber das würde ja heißen, dass sie immer noch tile-basiert wäre. Lässt sich damit ein vernünftiges Jump'n Run machen? Ein Standardelement von denen sind ja z.B. sich vertikal bewegende Plattformen, für die man eine möglichst genaue Kollisionsabfrage benötigt. Schräger Untergrund würde mit einer tile-basierten Kollisionsabfrage auch nicht funktionieren.

...

Gleich mal eine Gegenfrage. Warum sollte es nicht gehen? Weil es den Anschein hat? Würde mich ehrlich interessieren, weil bei solchen Fragen bin ich von vornherein überzeugt, dass es da eine Lösung für gibt. Vielleicht kommt man damit auch der Antwort näher, was alles machbar ist. ^^

Also Schrägen sind schonmal in dem Sinne machbar, dass man Diagonalen als halbvolle Tiles definiert. Es gäbe also eine eigene Terrain-ID für 45°-Böden und für 135°-Böden. Definitionssache ist außerdem die Größe des Chars. Jetzt so theoretisch aus der Luft gegriffen vertut man sich da zu leicht, als dass man das genau erklären könnte. Ist sehr viel Erfahrung bzw. Arbeit nötig.

(Bei meinem momentanen BattleVersus-Script gibt es Kollisionsabfragen für Schrägen mit dem 1Pixel-Char. Aber pscht! Geheim....)

Sich vertikal bewegende Plattformen ... die Plattformen selbst kann man als Events darstellen. Diese müssten dann aber die Geschwindigkeit abspeichern oder auslesbar machen. Dann kann man das auf Darstellung und Kollisionsberechnung aufteilen und diese vollständig voneinander unabhängig machen. Im Hintergrund wird die Position berechnet, und gezeigt wird die Plattform samt bewegtes Picture für den Helden.
Aber ich würde nicht gleich die erste Idee verwenden, sondern viel testen.

Pixelgenaue Kollision ist ohne Hacks/Patches/whatever leider nicht möglich.

...

Auch hier würde ich gern wissen: Warum so felsenfest davon überzeugt?


CapSeb

[Kyuu]

Auch hier würde ich gern wissen: Warum so felsenfest davon überzeugt?

...

Bitte: Pixelgenaue Kollision, wie sie in Jump'n'Runs/Shooters verwendet wird, die man auf dem Maker zu adaptieren versucht, bedeutet Bitmaskenüberlagerung. Es gibt keine Möglichkeit auf den alten Makern Bitmasken von Bildern zu erstellen, von bitweisen Operationen wollen wir gar nicht sprechen. Weiß nicht ob das auf dem RMXP anders ist, aber von dem reden wir ja nicht.

Wenn dir pixelgenaue Kollision ein Begriff ist, solltest du das eigentlich wissen. :)

[Phno]

Wenn wir jeden Pixel mit einer Variable unterlegen: Ja, pixelgenaue Kollision ist möglich.

Nur weil etwas Aufwand bedeutet, heißt es nicht dass es unmöglich ist~