Über die Qualität von Makerspielen

Zitat:

---

Zitat von real Troll

Der zweite Punkt (freie Punktverteilung) kommt in Makerprojekten eher selten vor; [...]Woran liegt es? Wird diese Möglichkeit unter den Entwicklern einfach nicht gesehen? Dann sollten wir darüber diskutieren. Allerdings halte ich es für sehr unwahrscheinlich, dass aus bloßer Kenntnislosigkeit die freie Punkteverteilung so selten eingesetzt wird, dafür kommt sie in zu vielen Spielen jenseits des Makerkosmos vor. Kann man als Spielinteressierter kaum verpassen.
Ich vermute, die Möglichkeit wird bewusst nicht ergriffen. Aber das ist nur eine Vermutung, ich weiß nicht, wie es in anderen Köpfen spukt.

---

Ich denke es würde wesentlich öfter verwendet werden, wenn das als StandardFunktion mit drin wäre. Sowohl Statuspunktevergabe als auch Talentbäume. Bei letzteren gibt es irre viele kommerzielle Vorbilder, aber die haben fast alle gemein, dass sich die Effekte schwer 1:1 auf den Maker übertragen lassen. Ich kenne mich mit den vorhandenen Rubyscripten für die neuen Maker nicht so aus. Beim 2k3 kann ich mittlerweile alles nachscripten, was kommerzielle Spiele so bieten, aber die Situation ist nicht vom Maker so gegeben, sondern das Ergebnis von DynRPG und dem Evenscriptframework. Die Xp/Ace-Scripte sehen mir aus, als würde da vor allem von Japanern das nachgebaut, was aus jRPGs bekannt ist, seltener Sachen aus West-RPGs.

Zitat:

---

Zitat von Yenzear

Ich würde ja sagen, dass die Option den Entwicklern durchaus bekannt ist. Ein Grund, dies nicht umzusetzen ist das bereits von dir erwähnte "Verskillen" oder aber der Aufwand, es balancingtechnisch so hin zu bekommen, dass nicht eine Skillung übermächtig ist, also durchaus ein

---

Halte ich für sehr unwahrscheinlich. In der Makerszene die ich kenne wird jeder Scheiss eingebaut weil der Ersteller grade der Meinung ist, dass es cool klingt und er letzte Woche ein Spiel gespielt hat, dass das auch hatte.
Ich halte die technische Hemmschwelle fin der Umsetzung für wesentlich entscheidender.

Zitat:

---

Zitat von real Troll

Der zweite Punkt (freie Punktverteilung) kommt in Makerprojekten eher selten vor; mir fällt da gerade lediglich die "Sternenkind-Saga" als großes Beispiel eines fertigen Spiels ein. Woran liegt es?

---

In einige Spiele wollte ich sie einbauen, aber aus denen ist nichts geworden und dann hab ich die Attribute ganz rausgeworfen. Wobei das eigentlich gar nicht stimmt, ich bin zu Talenten übergegangen, also anstatt eines stetigen Zuwachses an Körperkraft kann man "Schaden + x %"-Talente lernen usw.

Corti hat jedenfalls den Nagel auf den Kopf getroffen. Eine freie Punkteverteilung erfordert Kenntnisse, die über das Zusammenklicken hinausgehen, falls es nicht gerade ein fertiges Script dafür gibt.

Zitat:

---

Zitat von Kelven

Corti hat jedenfalls den Nagel auf den Kopf getroffen. Eine freie Punkteverteilung erfordert Kenntnisse, die über das Zusammenklicken hinausgehen, falls es nicht gerade ein fertiges Script dafür gibt.

---

Sofern ich das nicht falsch gedeutet habe, meinte Corti aber, dass gerade der technische Part, also das "Zusammenklicken" der Hauptgrund ist, dass es nicht oft verarbeitet wird. Eben so entnehme ich seinen Post, dass Mangel an Kenntnis zur richtigen Umsetzung die wenigsten davon abhält, es umzusetzen ^^"
Ein fertiges Script gibt es eigentlich für so ziemlich alles mögliche, glaube ich. Selbst ein FireemblemlikeKS habe ich schon irgendwo in Form eines solchen Scripts gesehen.

Ich kann natürlich nicht für Corti sprechen, aber das was ich meinte ist, dass die meisten Maker-Entwickler zwar mit dem Event-Code Cutscenes oder interaktive Objekte scripten können, aber eben keine Custom-Menüs mit freier Punkteverteilung.

Wenn ich das mal Übersetzen darf:

Corti: Keine Punkteverteilung, weil keine Standard-Funktion [also zusammenklickbar].
Kelven: Keine Punkteverteilung, weil nicht simpel zusammenklickbar [also Standard-Funktion].

Also sagten beide im Grunde das gleiche.

Hm, dann eine Fehlinterprätation meinerseits ^^"
Ich dachte ja, dass Kelvens Satz (wichtiges habe ich mal schwarz hervorgehoben)

Zitat:

---

Eine freie Punkteverteilung erfordert Kenntnisse, die über das Zusammenklicken hinausgehen, falls es nicht gerade ein fertiges Script dafür gibt.

---

implizieren würde, dass es Kenntnisse, die über das Zusammenklicken einer solchen Funktion hinaus gehen erfordern würde, also eben auch Kenntnis darüber, wie man sowas gameplaytechnisch ordentlich einbaut.
Im Grunde klickt man Eventcode wie den eines Picturemenüs auch nur zusammen.

Die Ablaufsteuerung von einem Gespräch oder einem Schatz ist schon deutlich simpler als die von einem Menü. Ich kann mir vorstellen, dass das jemandem, der keine Programmiererfahrung hat, schnell über den Kopf wächst. Das Menü wird irgendwann so unübersichtlich und umständlich, dass der Entwickler genervt die Flinte ins Korn schmeißt.

Zitat:

---

Zitat von Kelven

Die Ablaufsteuerung von einem Gespräch oder einem Schatz ist schon deutlich simpler als die von einem Menü. Ich kann mir vorstellen, dass das jemandem, der keine Programmiererfahrung hat, schnell über den Kopf wächst. Das Menü wird irgendwann so unübersichtlich und umständlich, dass der Entwickler genervt die Flinte ins Korn schmeißt.

---

Mit Programmiererfahrung hat das Erstellen eines Picturemenüs jetzt nicht viel zu tun. Ich selbst habe auch schon welche zustande bekommen, ohne Programmiererfahrung zu haben. Ich kenne Leute, die Programmieren können und die amüsieren sich jedes Mal prächtig, wenn man beim Maker mit Bezug auf das Eventing vom Programmieren spricht ^^" Ist in etwa so, als würde man die Zubereitung einer Fünfmintuenterine als Kochen bezeichnen.
Alles, was es bei der Erstellung eines Picturemenüs im Maker braucht, sind Erfahrung (mit dem Maker) und halt eben Geduld. Die Steamversion des Makers wartet sogar mit farbigen Befehlen etc auf, das macht das Ganze dann noch etwas leichter. Die Möglichkeit, im "Code" des Events Notizen zur besseren Übersicht zu hinterlassen wird gemeinhin auch unterschätzt, wie ich glaube.

Zitat:

---

Ich kenne Leute, die Programmieren können und die amüsieren sich jedes Mal prächtig, wenn man beim Maker mit Bezug auf das Eventing vom Programmieren spricht

---

Bestimmt Mitglieder des Heise-Forums. http://abload.de/img/fingerzeiga3q40.gif

Ob man das Setzen des Event-Codes Programmieren nennen darf ist eine andere Frage (der Maker-Code ist aber immerhin turing-vollständig). Was ich sagte: Jemand, der programmieren kann, hat es einfacher bzw. sogar einfach. Oder anders ausgedrückt: Man muss davon ausgehen, dass die Mehrheit der Maker-Entwickler mit aufwändigeren Scripten Schwierigkeiten hätte.

Zu der Sache mit den Programmierkenntnissen:

Ich denke einfach dass das Programmieren mit dem Maker im Prinzip nichts anderes ist als das gängige Programmieren, und es sich lediglich in der Komplexität und der Zugänglichkeit des Werkzeuges unterscheidet. (Darauf gehe ich jetzt nur ein wenn mich jemand fragt wie ich das meine) Jemand der schon allgemeine Programmiererfahrung hat, hat den gleichen Vorteil im Maker wie ein erfahrener Maker-Entwickler (Kennt das Prinzip eines Skriptes, hat die abstrakten Denkstrukturen ect. pp.) nur dass der eine das Programm noch nicht gut kennt. Der Rest ist abhängig von den Fähigkeiten des jeweiligen Entwicklers. Und es ist nur natürlich, dass ein Programmieranfänger mit komplexeren Skripten überfordert ist (sei es jetzt im Maker oder in anderen Programmiersprachen). Das ist nunmal so wenn man in irgendetwas nur ein Anfänger ist. Selbstverständlich hat dann jede Person ihre eigenen Grenzen, aber mit der investierten Zeit kann glaube ich fast jeder die nötigen Kenntnisse erlangen. Wenn man von dem implementieren komplexerer Skripte spricht gehe ich davon aus, dass man von fortgeschritteneren Entwicklern spricht. Das Neulinge sich erstmal im Rahmen des Standards bewegen, ist ja verständlich. (Wobei es da bestimmt auch Ausnahmen gibt).

Ich denke der Punkt ist, dass viele Menschen die mit dem Maker arbeiten zu unterschiedliche Motivationen/Ansprüche haben. Natürlich hat jedes Feature seine eigenen Pros/Cons, so wie jetzt das Beispiel mit der Punkteverteilung. Damit habe ich mich persönlich noch nicht auseinander gesetzt, aber ich denke dass viele Entwickler so ihre (unterbewussten) Gründe haben, ihre Finger von Features außerhalb der Konventionen zu lassen:

• Zu viel Zeit / Aufwand - Besonders wenn der Maker nicht gerade das primäre Hobby ist
• Unsicherheit - Sei es jetzt ob man nicht weiß ob das Feature ins Konzept passt oder man an den eigenen Programmierfähigkeiten zweifelt / sie nicht hoch einschätzt
• Fehlende Bereitschaft so aufwendig zu Programmieren - Nach dem Motto 'Am Ende ist der Aufwand für die Katz'
• Einfaches nicht wahrnehmen der Möglichkeiten / Zu wenig Kreativität / Starres Denken in Konventionen - Ist ja auch möglich
• Niedriger Anspruch ans eigene Spiel (nicht negativ gemeint, gibt ja durchaus Gründe dafür z.B. wenn makern simpler Zeitvertreib ist)
• Bequemlichkeit - "Wenn andere ihre Spiele simpel halten und es funktioniert, wieso sollte ich es anders machen"

So oder ähnliche Argumente fallen mir jetzt ein. Im Falle der Punkteverteilung muss ich sagen, dass mir persönlich dieses Feature für mein Spiel tatsächlich noch nicht in den Sinn gekommen ist.
Vielleicht hat man es wirklich einfach nicht auf dem Schirm.

Also ich finde die Kochmetapher sehr treffend und werde sie mir definitiv merken. :)

Zitat:

---

Zitat von Kelven

Bestimmt Mitglieder des Heise-Forums. http://abload.de/img/fingerzeiga3q40.gif

Ob man das Setzen des Event-Codes Programmieren nennen darf ist eine andere Frage (der Maker-Code ist aber immerhin turing-vollständig). Was ich sagte: Jemand, der programmieren kann, hat es einfacher bzw. sogar einfach. Oder anders ausgedrückt: Man muss davon ausgehen, dass die Mehrheit der Maker-Entwickler mit aufwändigeren Scripten Schwierigkeiten hätte.

---

kA, was du mit Heise- Forum meinst ^^
Ich denke auch nicht, dass Programmierkenntnisse die Sache erleichtern, da beim reelen Programmieren alles von Hand eingegeben wird. Dass die richtige Zeile Code am richtigen Platz sein muss, ist ja kein Geheimnis. Viel mehr würde ich sagen, dass Makerkenntnisse beim Programmieren eventuell nützlich sein könnten, will mich da aber nicht drauf festnageln, weil keine Programmierskills. Dass die Mehrheit Probleme mit aufwändigeren Scripten hat, ist mehr auf einen Mangel an Praxis zurück zu führen. Das heißt nicht, dass man schon lange mit dem Maker arbeiten muss, sondern lediglich, dass man sich auch mal ins kalte Wasser stürzt und etwas neues ausprobiert, wie eben Picturemenüs. Wer das nicht tut, wird auch nach 20 Jahren noch Probleme mit sowas haben, einfach weil er nicht geübt ist.

@Katkat:
Ich denke schon, dass Programmieren etwas anderes ist, da es hier nicht nur darauf ankommt, die Befehle in korrekter Reihenfolge einzugeben, sondern auch, sich dabei nicht zu verschreiben. Obendrein nimmt einem beispielsweise der Steammaker wirklich viel in Sachen übersichtlichkeit und Parametereinstellungen ab, einfach wegen der grafischen Oberfläche des Programms. Beim Programmieren hat man afaik nur eine Textdatei gefüllt mit dem eigenst geschriebenen Code.
Das Ruby des XP und des VX/Ace geht schon etwas weiter in dir Richtung, als es das Eventing des 2k/3 tut.

Zitat:

---

Zitat von Yenzear

kA, was du mit Heise- Forum meinst ^^
Ich denke auch nicht, dass Programmierkenntnisse die Sache erleichtern, da beim reelen Programmieren alles von Hand eingegeben wird. Dass die richtige Zeile Code am richtigen Platz sein muss, ist ja kein Geheimnis. Viel mehr würde ich sagen, dass Makerkenntnisse beim Programmieren eventuell nützlich sein könnten, will mich da aber nicht drauf festnageln, weil keine Programmierskills. Dass die Mehrheit Probleme mit aufwändigeren Scripten hat, ist mehr auf einen Mangel an Praxis zurück zu führen. Das heißt nicht, dass man schon lange mit dem Maker arbeiten muss, sondern lediglich, dass man sich auch mal ins kalte Wasser stürzt und etwas neues ausprobiert, wie eben Picturemenüs. Wer das nicht tut, wird auch nach 20 Jahren noch Probleme mit sowas haben, einfach weil er nicht geübt ist.

@Katkat:
Ich denke schon, dass Programmieren etwas anderes ist, da es hier nicht nur darauf ankommt, die Befehle in korrekter Reihenfolge einzugeben, sondern auch, sich dabei nicht zu verschreiben. Obendrein nimmt einem beispielsweise der Steammaker wirklich viel in Sachen übersichtlichkeit und Parametereinstellungen ab, einfach wegen der grafischen Oberfläche des Programms. Beim Programmieren hat man afaik nur eine Textdatei gefüllt mit dem eigenst geschriebenen Code.
Das Ruby des XP und des VX/Ace geht schon etwas weiter in dir Richtung, als es das Eventing des 2k/3 tut.

---

Grafische Oberflächen kann man auch bei allen anderen Programmiersprachen haben. Das liegt am Programm mit dem man programmiert, nicht an der Sprache an sich. Visual Studio ist da zum Beispiel recht gut und übersichtlich.
Rein vom Prinzip her ist dass, was man mit den Events im Maker macht nichts anderes als das, was man auch bei allen anderen Programmiersprachen macht. Beim Maker muss man nur nicht alles selber eintippen, sondern hat schon vorgefertigte Befehle, quasi eine oder mehrere Zeilen im Code die man einfach per einzelnes Event einfügt. Dadurch sinkt die Fehlermöglichkeit, da man sich nicht vertippen kann, man schränkt sich aber auch ein, da man nur diese eine Art von Codezeile nutzen kann und Personalisierungen nicht möglich sind (sofern man beim reinen Eventezusammenklicken bleibt).

Was man aber auf jeden Fall lernt: Auf die Art zu denken wie ein Programmierer es tut. Codes können auf komplexe Art zusammengeschustert werden und mit nur einer Hand voll verschiedener Befehle kann man fast alles erreichen (ist dann nicht unbedingt die idealste oder Ressourcenschonendste Methode sein Ziel zu erreichen, aber man erreich es). Und wie einige Spiele beweisen ist das auch mit dem Maker erreichbar. Als richtiger Programmierer mit einer vollwertigen Programmiersprache könnte man vieles optimaler, eleganter und schneller erledigen, aber der erreichbare Umfang des Makers kann (innerhalb seiner Grenzen) durchaus ähnlich ausfallen wie von anderen vollwertigen Programmiersprachen.
Meine Meinung nach 2 Semestern C++ vor 3 Jahren ^^

@Eddy
Ja eben. Genau wie du es erläuterst denke ich auch, deswegen sagte ich dass sich "Komplexität und Zugänglichkeit des Werkzeugs" sich unterscheidet :)

@Yenzear
"Ich denke schon, dass Programmieren etwas anderes ist, da es hier nicht nur darauf ankommt, die Befehle in korrekter Reihenfolge einzugeben, sondern auch, sich dabei nicht zu verschreiben."

Nunja, das erhöht wie Eddy sagte eigentlich nur die Fehlermöglichkeit bzw. den Nervenfaktor. Und es kommt im Maker ja nicht nur darauf an alles in richtiger Reihenfolge einzugeben, zumindest bei komplexeren Skripten.
Das Prinzip ist das gleiche, ich überlege momentan mir mal eine gängige Skriptsprache anzugucken um zu sehen wie sehr die Maker-Grundlage mir hilft.

Aufjedenfall kann man nichts auf 'Technische-Limitierung' schieben meiner Meinung nach. Ist alles nur eine Sache der Anwendung.
Wobei ich verstehen kann warum manche Menschen sich nicht so ausführlich mit der Engine beschäftigen können/wollen, so dass sie ihr komplettes Potential ausschöpfen können.

@Yenzear Viele Programmierer nutzen vorgefertigte Librarys und Funktionen oder ganze Skripte von anderen, vor allem wenn es um kostenlose Indiespiele geht. Die sehen zwar ein bisschen anders aus, wie das Optionskästchen im Maker, brauchen aber auch nur minimalen eigenen Input. Verwenden können muss man den Kram trotzdem, sonst hilft das alles nichts...wie im Maker!

...Was war eigentlich nochmal das eigentliche Thema?

Zitat:

---

Zitat von Yenzear

Ich denke schon, dass Programmieren etwas anderes ist, da es hier nicht nur darauf ankommt, die Befehle in korrekter Reihenfolge einzugeben, sondern auch, sich dabei nicht zu verschreiben. Obendrein nimmt einem beispielsweise der Steammaker wirklich viel in Sachen übersichtlichkeit und Parametereinstellungen ab, einfach wegen der grafischen Oberfläche des Programms. Beim Programmieren hat man afaik nur eine Textdatei gefüllt mit dem eigenst geschriebenen Code.
Das Ruby des XP und des VX/Ace geht schon etwas weiter in dir Richtung, als es das Eventing des 2k/3 tut.

---

Das stimmt überhaupt nicht. Zum programmieren benutzen heute die allermeisten eine sogenannte IDE, das steht für Integrated Developement Enviroment. Diese Programme sind dafür da die Programmierarbeit erheblich zu erleichtern. Damit wird das Programmieren mit einer hochsprache sehr sehr sehr viel einfacher als die Arbeit mit dem RPG-Maker. Eine IDE ist ein unglaublich kompliziertes und mächtiges Werkzeug mit Funktionen, von denen die Makerer wohl nur träumen können. Automatische Code-Generierung, Auto-Vervollständigung, Refactorings, Templating, Statische und Dynamische Code-Analyse, Debugger die schrittweise durch ein Programm gehen können, vorwärts und rückwärts, und vollen Zugriff auf alle Variablen geben, und das ist nur der Anfang.

Übrigens, der Event-Code im RPG-Maker ist Programmierung genau wie alles andere. Ob man mit der Maus klickt oder auf der Tastatur tippt, am Ende kommt es nur darauf an, dass man mit einer Turing vollständigen Sprache eine Symbolreihenfolge produziert, welche von einem Computer verarbeitet werden kann.

Ok, dass es grafische Oberflächen für Programmierer und der Gleichen gibt, wusste ich nicht xD Ich bleibe dennoch bei meinem Standpunkt und sage im Makerkontext einfach "makern" statt programmieren, wenn ihr das unbedingt anders handhaben wollt, macht halt ^^"

Zitat:

---

Zitat von Sabaku

...Was war eigentlich nochmal das eigentliche Thema?

---

Kann schon sein, dass wir leicht ins Offtoppic abgedriftet sind ^^

Ganz so weit haben wir uns gar nicht vom Thema entfernt, denn das Spielsystem hat ja auch mit Qualität zu tun, zumindest für diejenigen, die meinen, das Standardsystem wäre nicht gut genug. Ich bin aber anderer Meinung: Der RPG Maker ist ein Werkzeug, mit dem jedermann ohne große Vorkenntnisse ein Spiel machen kann, also sollte man nicht erwarten, dass sich der Jedermann weit vom Standard entfernt.

Apropos Erwartungen, Owly hat etwas sehr Interessantes angesprochen, die falschen Erwartungen, was mich wieder zu einer älteren Frage zurückführt: Was sollte man von einem Makerspiel erwarten? "Es soll Spaß machen" wird gerne gesagt, aber das ist eine ausweichende Antwort, denn sie drückt sich um die Konkretisierung der Erwartungen. Erst wenn gesagt wird, was genau vom Gameplay und der Handlung erwartet wird, lässt sich darüber diskutieren, inwieweit die Erwartungen realistisch sind. Ich hab ja vorher schon mal angesprochen, dass Maker-Engine, Maker-Zuschnitte und Entwickler Einschränkungen unterliegen. Manchmal hab ich das Gefühl, dass beim Mäkeln an den Spielen schnell vergessen wird, wer hier wie mit was ein Spiel entwickelt hat.

Vor allem, wenn man selbst mit dem Maker arbeitet und schon länger in der Szene ist, sollte man wissen, wie die Spiele so sind und da steht nicht: wie die wenigen herausragenden Spiele so sind. Es ist nun mal so, dass es immer einige geben wird, die viel besser als die anderen sind - aber sollte man dem Rest daraus einen Strick drehen?

Nochmal zum "Was geht?" Ich spiele nun schon seit 14 Jahren Makerspiele und obwohl sich das Gameplay der Rollenspiele im Detail unterscheidet, ist ihr Aufbau meistens ziemlich ähnlich. Wir diskutieren seit Ewigkeiten über die Spielmechanik, über den Aufbau der Dungeons, Kampftaktik (TM), Speichersysteme, Schätze in der Hauseinrichtung und vieles mehr. Haben sich die Diskussionen auf die Spiele ausgewirkt? Vielleicht im Kleinen, aber viel geändert hat sich nicht. Vermutlich weil es (auf dem Maker) gar nicht großartig anders geht (und es auch kaum einer anders will), zumindest nicht ohne den RPGs ihre Identität zu nehmen. Falls jemand also spielerisch mehr von den Spielen erwartet, würde ich gerne wissen, was anders gemacht werden muss.

Zum Schluss möchte ich auf den Stein des Anstoßes zurückkommen, Desert Nightmare R. Natürlich muss ich gleich vorweg sagen, dass ein Stein keine Lawine ausmacht, es handelt sich mMn um eine allgemeines Problem der Community, nicht nur um eines, das meine Spiele betrifft. Zu denen kann ich aber im Gegensatz zu anderen Spielen etwas sagen, sprich ich weiß, was ich mit ihnen erreichen wollte.

Adventure-Gameplay: Habt ihr schon mal außerhalb der Makercommunity ein Adventure mit einer Retro-RPG-Engine gespielt? Vermutlich gibt es nicht sehr viele. Schon die C64-Adventures, die ich gespielt hab, hatten bessere Engines. Ein Adventure mit Makerengine zu machen ist eine ziemlich halbgare Lösung und ich geh mal davon aus, dass das den meisten Entwicklern hier auch bewusst ist oder irre ich mich? Wir machen es trotzdem, weil ... damit könnte man einen eigenen Thread füllen. Auf jeden Fall wird es getan und dann bekommen die Adventures oft auch noch eine rollenspielartige Handlung spendiert. Etwas, das ich von anderen Adventures auch eher nicht so kenne. Etwas überspitzt formuliert sind Adventures auf dem Maker oft "Ich hab ein RPG ohne Kämpfe und brauch nun anderes Gameplay". Und das sollte jedem bewusst sein, der schon etwas länger in der Szene ist. Natürlich trifft man als Entwickler auch mal schlechte Entscheidungen, unter denen der Spielspaß noch mehr leidet, aber der eigentliche "Fehler" (wie sehen das eigentlich andere?) wurde schon vorher gemacht und er wird von den meisten gemacht, die mit dem Maker Adventures machen. Der Hauptgrund, warum ich mich damals über einige Meinungen über das Spiel so geärgert hab, war übrigens, dass der "Fehler" bei meinem Spiel als (übertrieben) Todsünde dargestellt wurde, während er sonst anscheinend kein Problem ist.

Action: Der RPG Maker nutzt eine tile-basierte Rollenspiel-Engine und ist damit für Action vollkommen ungeeignet. Man muss schon zwei oder besser drei Augen zudrücken, wenn man auf dem Maker auf Action-Gameplay trifft. Auch das weiß jeder. Es wird trotzdem eingebaut, weil der Maker-Entwickler sich sagt: "Ich brauch die Action, denn man kann ja nicht mit dem Standard-KS gegen die Monster kämpfen und flüchten kann man mit ihm erst recht nicht und die kommerziellen Spiele haben auch Action." Mir kann niemand weismachen, dass er erwartet, dass Action auf dem Maker richtig Spaß macht. Sicherlich war das Flüchten damals in der ersten Version von Desert Nightmare R selbst für Makerverhältnisse zu monoton, das eigentliche Problem ist aber die Engine inlusive Vogelperspektive.

Handlung: Der eine oder andere fand die Handlung vom Spiel vielleicht langweilig oder aus anderen Gründen nicht unterhaltsam, das ist in Ordnung, das kann immer passieren, und es hängt von so vielen Faktoren ab, dass man es nie ganz verhindern kann. Erst wenn jeder gelangweilt ist, hat der Entwickler etwas falsch gemacht. Aber das nur am Rande, um Langeweile ging es bei der Diskussion ja nicht. Was kann man von der Handlung des Spiels erwarten? Nun, eines ist klar, ich hab nie gesagt, das Spiel hätte Anspruch oder wäre ein Charakterdrama. Wäre das mein Ziel gewesen, hätte ich wohl kein Spiel gemacht, auch kein Horror, sondern etwas Bodenständigeres. Im Spiel geht es darum, dass ein paar Leute vor Wüstenpsychopathen flüchten. Was soll man davon erwarten? Wie wäre es mit seichter Unterhaltung? Gegen die übrigens absolut nichts spricht, es sei denn, man wollte in Wirklichkeit etwas Anspruchsvolles machen. So naiv bin ich aber nicht, dass ich versuche, in einem 2-Stunden-Spiel mit ca. 20-30 Minuten Handlung, eine tiefsinnige Story zu erzählen. Die kurze Zeit bringt auch noch etwas anderes mit sich, nämlich dass die Figuren alle oberflächlich bleiben. Ist das ein Problem? Bei dieser Geschichte nicht. Ich kann mir vorstellen, dass die Figuren vielen Spielern nicht wirklich ans Herz gewachsen sind, aber das ginge sowieso nur bei der Hauptfigur, weil die Nebenfiguren keine besonders sympathischen Persönlichkeiten haben. Und Sandra wollte ich nicht zu stark überzeichnen (gegenüber stark überzeichneten Figuren empfindet man mMn schneller Sympathie/Antipathie), weil das zum Spiel nicht gepasst hätte und dann ist da eben die Spielzeit. Das Spiel müsste deutlich länger sein, um eine starke Bindung zu ihr aufbauen zu können. Dass das nicht geht, finde ich nicht so schlimm, weil die Story bei diesem Spiel nicht im Mittelpunkt steht. In einem längeren RPG müssen die Figuren schon sympathisch sein, in so einem kurzen Spiel ist es nicht so entscheidend (und es klappt auch höchstens nur dann, wenn die Figuren japanisch-überzeichnet sind). Lange Rede, kurzer Sinn: Was mich damals irritiert hat, war, dass einige von der Handlung viel mehr erwartet haben, als sie erfüllen kann (auch unter Berücksichtung meiner sicherlich nicht außergewöhnlichen schriftstellerischen Fähigkeiten). Woher kommen solche Erwartungen?

Also ich finde die Qualität eines Makerspieles zeigt sich durch:
1. Fesselnde Handlung.
2. Passende Musik und Soundefekte zur Schaffung einer tollen Atmosphäre.
3. Schöne Sprites und Grafiken.
4. Gute Dialoge, eine Spielwelt in der man viel Entdecken kann.
5. Interessante Gegner und Bosskämpfe.
6. Interessante Items.
7. Schöne Zwischensequenzen.

Ist meine persönliche Meinung. Wenn ich z.B. ein Spiel wie Unterwegs in Düsterburg ansehe, trifft alles was ich oben aufgelistet hab darauf meiner Meinung nach zu.

Zitat:

---

Zitat von real Troll

Ich vermute, die Möglichkeit wird bewusst nicht ergriffen.

---

Die Möglichkeit wird bewusst nicht ergriffen, weil Kenntnislosigkeit herrscht :p