Alles auf dem Maker ist möglich

[Kelven]

Wie du sicherlich gelesen haben wirst, geht es mir nicht um die bloße Umsetzbarkeit, sondern um vernünftige Spielbarkeit.

[Pazu]

Und dabei wollte ich den ersten Ego-Shooter auf dem Maker mit realistischer Physik-Engine machen!

[CapSeb]

Mir geht es in erster Linie darum, ob sich solche Spiele auf dem Maker vernünftig spielen lassen und das tun sie wie gesagt nicht. Sie sind zwar schon spielbar, aber eben bei weitem unter dem Niveau, das man von kommerziellen Spielen gewohnt ist. Es sei denn man schraubt die eigenen Ansprüche sehr weit zurück.

...

Ich denke da sind wir uns einig. Nur das bisher Erschienene stellt ja nicht das Maß aller (Maker-) Dinge dar.
Wenn man alles bisher hier Fabrizierte (von Standard Rollenspielen abgesehen) irgendwo präsentieren würde wo der Maker unbekannt ist, würden alle mit dem Kopf schütteln. Mich eingeschlossen.

aber bei Strategiespielen kommt man um richtiges Pathfinding nicht herum und um die ging es.

...

Eh, ja. Wie gesagt ist bei einem anspruchsvollerem System eine anspruchsvollere KI notwendig.
Strategiespiele sind nicht möglich auf dem Maker, bzw sinnfrei zu versuchen. Stimmt.

Falls du mit Beweis meinst, dass Kynero gesagt hätte, man könne auf dem Maker niemals ein Jump'n Run auf dem Niveau von Mario entwickeln, dann muss ich sagen, dass man diese Aussage nicht beweisen muss. Sie gilt solange bis jemand den Gegenbeweis antritt. Ich hab bis jetzt noch kein Maker-Jump'n Run gesehen, dessen Engine auch nur mit den simpelsten Jump'n Runs anderer Systeme mithalten kann. Dazu bräuchte man wie gesagt tile movement, flüssiges Scrolling, eine pixelgenaue Kollisionsabfrage usw.

...

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

---
Ich will mal ein paar handfeste Argumente kontern.


CapSeb

[makenshi]

Eh, ja. Wie gesagt ist bei einem anspruchsvollerem System eine anspruchsvollere KI notwendig.
Strategiespiele sind nicht möglich auf dem Maker, bzw sinnfrei zu versuchen. Stimmt.

...

Nicht möglich != sinnfrei zu versuchen.
Möglich ist es, wenn man die Dimensionen beschränkt.
Sinnfrei ist es auch nicht es würde immerhin im Endeffekt was bei rauskommen.

Der Knackpunkt ist simpel das es irgendwo nicht sinnvoll ist ein RTS auf einer Engine zu entwickeln die in dieser Hinsicht völlig gegen dich arbeitet. Es mag sein das die begrenzte Umgebung einen Reiz ausübt, ich denke da sehr oft ja auch so, jedoch ist das nur bis zu einem gewissen Maß sinnvoll.

[Hisoka]

...
Der Knackpunkt ist simpel das es irgendwo nicht sinnvoll ist ein RTS auf einer Engine zu entwickeln die in dieser Hinsicht völlig gegen dich arbeitet. Es mag sein das die begrenzte Umgebung einen Reiz ausübt, ich denke da sehr oft ja auch so, jedoch ist das nur bis zu einem gewissen Maß sinnvoll.

...

Ich würde da noch weiter gehen und sagen, dass es sinnlos ist ein Spiel zu erstellen von dem man schon weiß das es nicht wirklich gut wird. Denn man investiert soviel Zeit in die Umsetzung einer rudimentären Technik, das man kaum noch Zeit* hat den Rest des Spiels zu machen. Wenn man schon beinahe an einer A-Stern Implementation scheitert, dann sollte man wissen, dieses System sollte man für die Idee nicht weiter nutzen.

*Zeit bis die Motivation am Ende ist.

Auch bei einem Jump'n'Run kann man schon an die Grenzen des Makers stoßen. Man Bedenke etwas wie schräge Wege. Gerade hier bekommt man im Maker Probleme. Gerade weil hier die TileID nicht mehr weiterhilft.

Man merkt den alten Makern schon sehr schnell an wann sich erste Grenzen auf tun. Gerade so Sachen wie Kampfsysteme und alternative Menüs sind sehr umständlich umzusetzen.

Wenn jemand viel Flexibilität und große Freiheit will kann er sich ja mal RubyGame ansehen. Das wäre gerade hier die passende Alternative für die, die Ruby können und mögen.


Möglich ist eben vieles. z.B. die "Quake 3 Level" Demo die gezeigt wurde. Nur ist es eben weit umständlicher dies mit dem Maker zu machen. In C++ war es ein rund 20 Zeilen Tutorial und hier muss man erstmal den Maker dazu bringen das er die neue "Engine" versteht.

Daher sollte man sich beim Maker wirklich rein auf RPGs konzentrieren. Denn die sind schon aufwendig genug. Wenn man dann noch gegen das Programm arbeitet ist schon klar das nichts draus wird. Oder eben nur ne poplige Techdemo.

[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.

[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