Eigenes Menü: Unterschied zwischen den Versionen

Aus Makerpendium.de
K
 
(13 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
__NOTOC__
+
[[Datei:Tarasadventure4.gif|thumb|320px|<small>Das eigene Menü von [[Tara's Adventure]]</small>]]__NOTOC__
[[Datei:Tarasadventure4.gif|thumb|Das eigene Menü von [[Tara's Adventure]]]]
+
'''Eigene Menüs''' (gemeint sind vor allem Pausenmenüs) in [[Spieledatenbank von A bis Z|RPG-Maker-Spielen]] sind schon etwa genau so lang ein Thema für [[:Kategorie:Entwickler/-in|Entwickler]] wie der [[RPG Maker 2000]] existiert.  
'''Eigene Menüs''' (gemeint sind vor allem Pausenmenüs) in [[Spieledatenbank von A bis Z|RPG-Maker-Spielen]] sind schon etwa genau so lang ein Thema für [[Personenverzeichnis|Entwickler]] wie der [[RPG Maker 2000]] existiert.  
 
  
Eigene Menüs entstanden als Antwort auf das sperrige Standardmenü des RPG Maker 2000/2003, das kaum Raum für eigene Anpassungen lässt. Je nach Spiel und Genre erscheint ein eigenes Menü daher durchaus sinnvoll, etwa um essentielle Funktionen schnell erreichbar zu machen. In vielen Fällen erwiesen sich eigene Menüs letztlich aber als gescheiterte Experimente oder stellen sich, je nach Spiel, gar als komplett unnötig heraus. Ähnlich wie bei den meisten eigenen (oder nachgebauten) Kampfsystemen sind sie oft zu weniger imstande als das, was sie ersetzen sollen.
+
Eigene Menüs entstanden als Antwort auf das sperrige Standardmenü des [[RPG Maker 2000]]/[[RPG Maker 2003|2003]], das kaum Raum für eigene Anpassungen lässt. Je nach Spiel und Genre erscheint ein eigenes Menü daher durchaus sinnvoll, etwa um essentielle Funktionen schnell erreichbar zu machen. Auch der Einbau neuer Spielmechaniken oder Charakterattribute in das Spiel kann ein eigenes Menü erforderlich machen.
  
Speziell bei überambitionierten, im Alleingang entwickelten Projekten macht sich auch bemerkbar, dass ein gehöriger Teil der Entwicklungszeit in die Entwicklung eigener Menüs oder Kampfsysteme geflossen ist, wodurch andere Aspekte wiederum vernachlässigt wurden. In vielen Demos sind eigene Menüs auch unfertig und nur in Teilen benutzbar.  Gute ''Gegenbeispiele'', die ein an die ''Spielbedürfnisse'' vorbildlich angepasster Ersatz sind, stellen hierbei die Menüs aus [[Velsarbor]], [[Der schwarze Magier]] und [[Nebulus]] dar.
+
In vielen Fällen erwiesen sich eigene Menüs letztlich aber als gescheiterte Experimente oder stellen sich, je nach Spiel, gar als komplett unnötig heraus. Ähnlich wie bei den meisten [[Eigenes Kampfsystem|eigenen (oder nachgebauten) Kampfsystemen]] sind sie oft zu weniger imstande als das, was sie ersetzen sollen. Vielmehr waren bzw. sind sie oftmals Selbstzweck um den hohen Maßstäben der Community zu genügen und bieten keine praktischen Vorteile gegenüber dem Maker-Standard.
  
 +
Speziell bei überambitionierten, im Alleingang entwickelten Projekten macht sich auch bemerkbar, dass ein gehöriger Teil der Entwicklungszeit in die Entwicklung eigener Menüs oder Kampfsysteme geflossen ist, wodurch andere Aspekte wiederum vernachlässigt wurden. In vielen Demos sind eigene Menüs auch unfertig und nur in Teilen benutzbar.  Gute ''Gegenbeispiele'', die ein an die ''Spielbedürfnisse'' vorbildlich angepasster Ersatz sind, stellen hierbei die Menüs aus [[Velsarbor]], [[Der schwarze Magier]] oder [[Nebulus]] dar.
 +
[[Datei:Fos screen 3.png|thumb|320px|<small>Das eigene Menü in [[Fortress of Souls]], eine typische Umsetzung</small>]]
 +
[[Datei:Vampires Döhn Zwei 3.png|thumb|320px|<small>Das absichtlich völlig unnütze Menü von [[Vampires Döhn Zwei]]</small>]]
 +
[[Bild:Aldaran_Fehlendes_Menü.png|thumb|320px|<small>Ein aufwendiges Projekt wie [[Aldaran]] musste sich [[:Kategorie:2004|2004]] regelrecht entschuldigen, dass es kein eigenes Menü hatte</small>]]
 
==Generelle Methoden==
 
==Generelle Methoden==
 
Eigens erstellte Menüs sind entweder ein Ersatz für das [[Standardmenü]] oder eine Ergänzung für Selbiges, wobei letzteres eher in den seltensten Fällen sinnvoll ist und gut durchgeführt nicht zu weit vom Stil des Standards abweichen sollte (Arbeitshilfe hierfür: [[MyWindow]] (RPG2000/2003)), es jedoch häufig tut. Ergänzungsmenüs werden dann entweder dem Standard vorgeschaltet oder werden durch einen Gegenstand aus dem Inventar aufgerufen.
 
Eigens erstellte Menüs sind entweder ein Ersatz für das [[Standardmenü]] oder eine Ergänzung für Selbiges, wobei letzteres eher in den seltensten Fällen sinnvoll ist und gut durchgeführt nicht zu weit vom Stil des Standards abweichen sollte (Arbeitshilfe hierfür: [[MyWindow]] (RPG2000/2003)), es jedoch häufig tut. Ergänzungsmenüs werden dann entweder dem Standard vorgeschaltet oder werden durch einen Gegenstand aus dem Inventar aufgerufen.
  
 
Mit dem RPG2000-/2003-[[IPS-Patch]] [[SwitchOnMenuCall]] kann der Aufruf des Standardmenüs durch den Abbruchbutton durch das Einschalten von einem [[Switch]] ausgetauscht werden, was die Einbindung eines eigenen Menüs stabiler und einfacher gestaltet.
 
Mit dem RPG2000-/2003-[[IPS-Patch]] [[SwitchOnMenuCall]] kann der Aufruf des Standardmenüs durch den Abbruchbutton durch das Einschalten von einem [[Switch]] ausgetauscht werden, was die Einbindung eines eigenen Menüs stabiler und einfacher gestaltet.
 +
 
==Mapmenü==
 
==Mapmenü==
Das ''Mapmenü'' ist die ungefähr mit älteste Form von in [[RPG Maker|RPG Makern]] auf dem PC gebauten Menüs und gleichzeitig die üblicherweise umständlichste. Aufgerufen wird es über ein ständig laufendes [[Event]] auf der [[Mapping|Map]] oder ein [[CommonEvent]], das die Position des Spielers speichert und einen Teleport auf eine neue Map durchführt, sobald die Taste zum Aufruf (in der Regel ''ESC'') gedrückt wurde. Durch diese Vorgehensweise entsteht eine Vielzahl an Problemen, denen nur schwer entgegenzuwirken ist.
+
Das ''Mapmenü'' ist die ungefähr mit älteste Form von in [[RPG Maker]]n auf dem PC gebauten Menüs und gleichzeitig die üblicherweise umständlichste. Aufgerufen wird es über ein ständig laufendes [[Event]] auf der [[Mapping|Map]] oder ein [[CommonEvent]], das die Position des Spielers speichert und einen [[Teleport]] auf eine neue Map durchführt, sobald die Taste zum Aufruf (in der Regel ''ESC'') gedrückt wurde. Durch diese Vorgehensweise entsteht eine Vielzahl an Problemen, denen nur schwer entgegenzuwirken ist.
  
 
Die Positionen von Events, die sich auf der alten Map bewegt haben, sind nicht wiederherstellbar, falls diese sich nach definierten Routen bewegen (da sie sonst durcheinander geraten) und das manuelle Umplatzieren beim Verlassen des Menü's ist ein für jede einzelne Map viel zu spezieller Prozess, weswegen unter anderem deswegen darauf auch immer verzichtet wird.
 
Die Positionen von Events, die sich auf der alten Map bewegt haben, sind nicht wiederherstellbar, falls diese sich nach definierten Routen bewegen (da sie sonst durcheinander geraten) und das manuelle Umplatzieren beim Verlassen des Menü's ist ein für jede einzelne Map viel zu spezieller Prozess, weswegen unter anderem deswegen darauf auch immer verzichtet wird.
Zeile 21: Zeile 25:
  
 
'''Weitere Spiele mit Mapmenü:'''
 
'''Weitere Spiele mit Mapmenü:'''
*[[Eternal Legends]] ''(vorgeschaltet)''
+
*[[Eternal Legends - The Demon Saga]] ''(vorgeschaltet)''
 
*[[Hell Gates 2 - Valadurs Erbe]]
 
*[[Hell Gates 2 - Valadurs Erbe]]
 
*[[The Legend of Zelda - Link's Journey]]
 
*[[The Legend of Zelda - Link's Journey]]
Zeile 36: Zeile 40:
  
 
==Menü auf Picture-Basis==
 
==Menü auf Picture-Basis==
Die Darstellung eines Menü's durch Pictures ohne Teleport ist die beste Methode in einem RPG Maker ohne den Einsatz von einer Script-/Programmiersprache ([[Lua]], [[Ruby]], [[JavaScript]],...), erfordert jedoch immer noch einiges an Können. Jede Information und Navigation kann in frei gestaltbarer Form an beliebiger Position angezeigt, verschoben und bedient werden und je nach Bedürfnis ist auch ein Blick auf die Map durch die Oberfläche des Menü's hindurch im Bereich des Möglichen.
+
Die Darstellung eines Menüs durch Pictures ohne Teleport ist die beste Methode in einem RPG Maker ohne den Einsatz von einer Script-/Programmiersprache ([[Lua]], [[Ruby]], [[JavaScript]],...), erfordert jedoch noch immer einiges an Können. Jede Information und Navigation kann in frei gestaltbarer Form an beliebiger Position angezeigt, verschoben und bedient werden und je nach Bedürfnis ist auch ein Blick auf die Map durch die Oberfläche des Menü's hindurch im Bereich des Möglichen.
  
 
Viele Picture-Menüs oder Textbox-Picture-Kombinationen neigen jedoch dazu, sehr langsam zu sein (bspw. eine 1s-Dauer bei jeder einzelnen Bewegung, manchmal auch nichtmal gleichzeitig) und die Spieler mit ''"fancy"'' gestalteten, aber spätestens nach dem dritten Mal ansehen öden Effekten zu langweilen (weniger ist manchmal mehr), die das Spiel abseits aller Erträglichkeit ausbremsen. Zu empfehlen sind Bewegungsabläufe, die 1 bis 2 Zehntel lang sind und möglichst parallel ablaufen.
 
Viele Picture-Menüs oder Textbox-Picture-Kombinationen neigen jedoch dazu, sehr langsam zu sein (bspw. eine 1s-Dauer bei jeder einzelnen Bewegung, manchmal auch nichtmal gleichzeitig) und die Spieler mit ''"fancy"'' gestalteten, aber spätestens nach dem dritten Mal ansehen öden Effekten zu langweilen (weniger ist manchmal mehr), die das Spiel abseits aller Erträglichkeit ausbremsen. Zu empfehlen sind Bewegungsabläufe, die 1 bis 2 Zehntel lang sind und möglichst parallel ablaufen.
  
Besonders Erweiterungen wie ''Destiny2'', [[DynRPG]] oder [[RPGSS]] haben beim RPG Maker 2000 und [[RPG Maker 2003|2003]] die Möglichkeiten verviel- und vereinfacht, ein Menü zu erstellen, das eine gewisse Komplexität erreicht, sind jedoch keine Voraussetzung dafür.
+
Besonders Erweiterungen wie [[Destiny Patch|Destiny2]], [[DynRPG]] oder [[RPGSS]] haben beim RPG Maker 2000 und 2003 die Möglichkeiten verviel- und vereinfacht, ein Menü zu erstellen, das eine gewisse Komplexität erreicht, sind jedoch keine Voraussetzung dafür.
  
 
Berührungs-Events, die mit Mapmenüs leicht ausgetrickst werden können, sind bei einem über ''Autostart'' laufenden (von einem parallelen Event ausgelösten) Picture-Menü ohne zusätzlichen Aufwand auf der sicheren Seite und werden immer unumgehbar ausgeführt, sobald der Menüprozess beendet wurde.
 
Berührungs-Events, die mit Mapmenüs leicht ausgetrickst werden können, sind bei einem über ''Autostart'' laufenden (von einem parallelen Event ausgelösten) Picture-Menü ohne zusätzlichen Aufwand auf der sicheren Seite und werden immer unumgehbar ausgeführt, sobald der Menüprozess beendet wurde.
Zeile 49: Zeile 53:
 
*[[The Flashbulb Madness RPG]]
 
*[[The Flashbulb Madness RPG]]
 
*[[Yoshi's Island - Bowser's Revenge]]
 
*[[Yoshi's Island - Bowser's Revenge]]
 +
 +
{{GameDesignBox}}
  
 
[[Kategorie:Technik]]
 
[[Kategorie:Technik]]

Aktuelle Version vom 9. Februar 2023, 13:28 Uhr

Das eigene Menü von Tara's Adventure

Eigene Menüs (gemeint sind vor allem Pausenmenüs) in RPG-Maker-Spielen sind schon etwa genau so lang ein Thema für Entwickler wie der RPG Maker 2000 existiert.

Eigene Menüs entstanden als Antwort auf das sperrige Standardmenü des RPG Maker 2000/2003, das kaum Raum für eigene Anpassungen lässt. Je nach Spiel und Genre erscheint ein eigenes Menü daher durchaus sinnvoll, etwa um essentielle Funktionen schnell erreichbar zu machen. Auch der Einbau neuer Spielmechaniken oder Charakterattribute in das Spiel kann ein eigenes Menü erforderlich machen.

In vielen Fällen erwiesen sich eigene Menüs letztlich aber als gescheiterte Experimente oder stellen sich, je nach Spiel, gar als komplett unnötig heraus. Ähnlich wie bei den meisten eigenen (oder nachgebauten) Kampfsystemen sind sie oft zu weniger imstande als das, was sie ersetzen sollen. Vielmehr waren bzw. sind sie oftmals Selbstzweck um den hohen Maßstäben der Community zu genügen und bieten keine praktischen Vorteile gegenüber dem Maker-Standard.

Speziell bei überambitionierten, im Alleingang entwickelten Projekten macht sich auch bemerkbar, dass ein gehöriger Teil der Entwicklungszeit in die Entwicklung eigener Menüs oder Kampfsysteme geflossen ist, wodurch andere Aspekte wiederum vernachlässigt wurden. In vielen Demos sind eigene Menüs auch unfertig und nur in Teilen benutzbar. Gute Gegenbeispiele, die ein an die Spielbedürfnisse vorbildlich angepasster Ersatz sind, stellen hierbei die Menüs aus Velsarbor, Der schwarze Magier oder Nebulus dar.

Das eigene Menü in Fortress of Souls, eine typische Umsetzung
Das absichtlich völlig unnütze Menü von Vampires Döhn Zwei
Ein aufwendiges Projekt wie Aldaran musste sich 2004 regelrecht entschuldigen, dass es kein eigenes Menü hatte

Generelle Methoden

Eigens erstellte Menüs sind entweder ein Ersatz für das Standardmenü oder eine Ergänzung für Selbiges, wobei letzteres eher in den seltensten Fällen sinnvoll ist und gut durchgeführt nicht zu weit vom Stil des Standards abweichen sollte (Arbeitshilfe hierfür: MyWindow (RPG2000/2003)), es jedoch häufig tut. Ergänzungsmenüs werden dann entweder dem Standard vorgeschaltet oder werden durch einen Gegenstand aus dem Inventar aufgerufen.

Mit dem RPG2000-/2003-IPS-Patch SwitchOnMenuCall kann der Aufruf des Standardmenüs durch den Abbruchbutton durch das Einschalten von einem Switch ausgetauscht werden, was die Einbindung eines eigenen Menüs stabiler und einfacher gestaltet.

Mapmenü

Das Mapmenü ist die ungefähr mit älteste Form von in RPG Makern auf dem PC gebauten Menüs und gleichzeitig die üblicherweise umständlichste. Aufgerufen wird es über ein ständig laufendes Event auf der Map oder ein CommonEvent, das die Position des Spielers speichert und einen Teleport auf eine neue Map durchführt, sobald die Taste zum Aufruf (in der Regel ESC) gedrückt wurde. Durch diese Vorgehensweise entsteht eine Vielzahl an Problemen, denen nur schwer entgegenzuwirken ist.

Die Positionen von Events, die sich auf der alten Map bewegt haben, sind nicht wiederherstellbar, falls diese sich nach definierten Routen bewegen (da sie sonst durcheinander geraten) und das manuelle Umplatzieren beim Verlassen des Menü's ist ein für jede einzelne Map viel zu spezieller Prozess, weswegen unter anderem deswegen darauf auch immer verzichtet wird.

Events, die durch Berührung aktiviert werden, können mit einem Mapmenü, falls es nicht mühsam dafür angepasst wurde (siehe Alternate: Virus of Ragnarök), ganz simpel vom Spieler umgangen werden, da der Teleportprozess einen Vorrang gegenüber dem Berührungs-Event besitzt, wenn das Menü mitten in einem Laufschritt aktiviert wird. Dadurch ist es in vielen Spielen leicht möglich, Sperren, Fallen und (manchmal offensichtliche) Zwischensequenzen zu überspringen und/oder den Spielverlauf zu zerstören, was nichteinmal wissentlich durch den Spieler passieren muss (Glitch-Abusing), sondern auch Zufall sein kann und einen Designfehler seitens des Entwicklers (und nicht der Engine) darstellt.

Auch die Gestaltung eines Mapmenü's selbst erweist sich als unpraktisch, da die angewendete Darstellungstechnik durch Events keinerlei Vorteile gegenüber Pictures aufweist, klobiger ausfällt und die genaue Einteilung benötigter Grafiken in ChipSet und CharSets ein sehr unangenehmer Umweg beim Erstellen ist.

Weitere Spiele mit Mapmenü:

Die Textbox

Einfache Standard-Textboxen mit Auswahl können für sehr simple und informationsschlanke Menüs verwendet werden, die nicht viel darstellen müssen. Generell sollten diese jedoch nicht zu tief verschachtelt werden, da es den Spielern schnell die Übersicht rauben kann. Richtig angewendet entstehen keine Nachteile.

Weitere Spiele mit Textboxmenü oder Textbox-Picture-Kombination:

Menü auf Picture-Basis

Die Darstellung eines Menüs durch Pictures ohne Teleport ist die beste Methode in einem RPG Maker ohne den Einsatz von einer Script-/Programmiersprache (Lua, Ruby, JavaScript,...), erfordert jedoch noch immer einiges an Können. Jede Information und Navigation kann in frei gestaltbarer Form an beliebiger Position angezeigt, verschoben und bedient werden und je nach Bedürfnis ist auch ein Blick auf die Map durch die Oberfläche des Menü's hindurch im Bereich des Möglichen.

Viele Picture-Menüs oder Textbox-Picture-Kombinationen neigen jedoch dazu, sehr langsam zu sein (bspw. eine 1s-Dauer bei jeder einzelnen Bewegung, manchmal auch nichtmal gleichzeitig) und die Spieler mit "fancy" gestalteten, aber spätestens nach dem dritten Mal ansehen öden Effekten zu langweilen (weniger ist manchmal mehr), die das Spiel abseits aller Erträglichkeit ausbremsen. Zu empfehlen sind Bewegungsabläufe, die 1 bis 2 Zehntel lang sind und möglichst parallel ablaufen.

Besonders Erweiterungen wie Destiny2, DynRPG oder RPGSS haben beim RPG Maker 2000 und 2003 die Möglichkeiten verviel- und vereinfacht, ein Menü zu erstellen, das eine gewisse Komplexität erreicht, sind jedoch keine Voraussetzung dafür.

Berührungs-Events, die mit Mapmenüs leicht ausgetrickst werden können, sind bei einem über Autostart laufenden (von einem parallelen Event ausgelösten) Picture-Menü ohne zusätzlichen Aufwand auf der sicheren Seite und werden immer unumgehbar ausgeführt, sobald der Menüprozess beendet wurde.

Weitere Spiele mit Picture-Menü:

Öffnen
● GameDesign, Story und Technik (inklusive Antibeispiele)