Ich habe früher zwar viel mit dem RPG Maker 2000 / 2003 gewerkelt, war aber nie technisch sonderlich begabt oder eher zu faul dafür.
Nun habe ich mir aber vorgenommen, ein eigenes Menü zu erstellen und habe auch schon alle nötigen Grafiken dafür erstellt. Stilistisch ist es so aufgebaut wie in den Final Fantasy-Teilen: Rechts sind Menüpunkte wie "Gegenstände", "Ausrüstung", "Spiel beenden" usw. und links sind die Charakterportraits bzw. deren momentane Werte.
Nun aber zu meinem Problem selbst. Im Moment funktioniert es soweit, dass ein Zeiger auf Gegenstände zeigt, da er der erste Punkt im Menü ist. Drückt man nach oben, kommt man auf den letzten Punkt (Spiel beenden) und drückt man von "Gegenstände" nach unten, kommt man auf den nächsten. Aber dann tut sich gar nichts mehr, nur der Druck auf den Escape-Knopf schließt das Menü, so wie ich es im Common Event angegeben habe.
Daraus ergibt sich für mich nun folgende Frage: Braucht man in so einem FF-Menü für jeden einzelnen Menüpunkt einen einzelnen Common Event? Oder geht das doch in einem einzigen und ich verstehe nur nicht wie?
Im Moment benutze ich eben nur 3 Common Events, eines für den Druck auf die Escape-Taste (Parallel Process -> dort wird ein weiteres Event aufgerufen), ein weiteres (Call, durch das 1. hervorgerufen), das die Grafiken des Menüs aufruft und ein drittes (Auto Start), das dann die Menüsteuerung selbst sein soll. Aber diese funktioniert eben bisher nur für "Gegenstände".
Wie gesagt, wenn man ohnehin für jeden einzelnen Menüpunkt einen Extra Common Event braucht, dann hat sich das Problem wohl schon erledigt... Aber geht das nicht einfacher? Sonst hab ich ja bald extrem viele Common Events.
Lies es dir durch. Das ist eigentlich recht gut. So wie dus machst, ists ganz schön kompliziert und ohne Scriptzitate natürlich auch schwer nachzuvollziehn. Das Tutorial dort oben sollte dir helfen, Grundlagen zu verstehen.
Grundsätzlich kann ich dir aber sagen, dass du keine CEs verwenden solltest... Ich persönlich präferiere Menüs auf separaten Maps wo dann alles über Map-Events läuft. Am Besten dann für jede Funktion des Menüs eine Map.
Um jede Menge Common Events wirst du wohl kaum herumkommen, denn das ganze sollte ja schon übersichtlich sein, so dass du recht schnell auch wieder weißt, wo jetzt was gemacht werden soll. Wenn du den Zeiger bewegen willst, wäre es vielleicht nicht schlecht, schon im Vorfeld festzulegen, wo der hingehen kann und wohin nicht. Bei dem, was ich gemacht habe, wurde praktisch alles in einem Call Event abgearbeitet, in dem auch ein Zyklus enthalten ist, so kann man die Initialisierung der Variablen ablaufen lassen, dann das Menü selbst steuern und schlussendlich das ganze beenden. ParallelProzess hat manchmal die Anwandlung, verspätet zu reagieren, bzw. kommt des öfteren dem Rest in die Quere. Ich muss allerdings sagen, dass ein FF-Hauptmenü für den Anfang doch ziemlich viel zu sein... Naja, schau dir auf jeden Fall mal das oben genannte Tutorial an und viel Glück!
Zuerst braucht man immer einen Index, der enthält wo man gerade im Menü ist.
(Erster Eintrag, bei dir "Gegenstände", sollte entweder Indexnr. 1 [oder 0] sein )
Das sollte auf deinem Schmierzettel so aussehen:
Willst du einen veränderbare Anzahl an Menüpunkte haben, brauchst du noch eine Variable maxIndex, den du entweder über einen Algorithmus dynamisch setzen lässt oder vorher festsetzt.
Zweitens brauchst du eine Variable zur Tastaturabfrage.
PS: Das Menü im Tutorial hat viel zu viel Code und ist unübersichtlich.
UPDATE: Pseudocode entfernt, im nächsten Post ist der verständlichere Makercode.
PS: Das Menü im Tutorial hat viel zu viel Code und ist unübersichtlich.
...
Dummschwätzer... Es ist genau das, was der gute Mann oben braucht und es ist nicht mehr, als das was du hier hast... und vor allem... es ist eine Schritt für Schritt anleitung di emit Maker-Screens untermauert wird. Alles in Allem ein guter Einstieg und leichter verständlich als von dir rausgehauter Pseudocode.
Dummschwätzer... Es ist genau das, was der gute Mann oben braucht und es ist nicht mehr, als das was du hier hast... und vor allem... es ist eine Schritt für Schritt anleitung di emit Maker-Screens untermauert wird. Alles in Allem ein guter Einstieg und leichter verständlich als von dir rausgehauter Pseudocode.
...
Der Maker-Code des Tutorials (und nicht das Tutorial selber) ist schlecht zusammen gescriptet (für einen Informatiker unästhetisch) und etwas langsamer (obwohl nicht sehr viel, jedoch für das mal x-mal die Millisekunde aus).
Das zeigt, dass der Autor vergessen hat den Code mal optimieren oder im Entstehungsprozess geschlampt hat.
Mein Code-Schnipsel dazu (was besser läuft):
PS: Ich kann nicht ersetzen, dass man sich mit dem Eventeditor und seinen Befehlen mal auseinandergesetzt hat.
Man muss auch lernen, sich allein mit Code-Schnipseln zurecht zu finden. Eine gute Aufgabe wäre es mal einen unkommentierte Code-Schnipseln zu kommentieren, um das zu lernen was da gemacht wird.
UPDATE: Ich hab den Code per Hand geschrieben, und nicht den EEE (den hab ich mir erst gestern herunter geladen) genutzt. Für einen neuen Post wäre es zu wenig gewesen.
Oh gott... er hat mehr als eine Fork verwendet um den Teste =5-Fall abzufragen... Steinigen wir ihn.. ganz ganz schnell... Sowas kann man sich später geben... Aber der Themenstarter hier schien überhaupt keinen Plan oder den falschen Plan zu haben und von daher is das Menü schon brauchbar... Dass man gleich lautende Forks auch zusammenfassen kann und sollte ist ein brauchbarer Hinweis nur kommt der nicht auf Anhieb raus, wenn du hier einfach einen Code heraushaust.
Du bezeichnest jemanden als Dummschwätzer, der eine qualitativ bessere Lösung bringt
In der Schule bringt man den Kinder ja auch nicht Halbwissen bei, wie im Tutorial der Fall ist, es ist durchaus mit einer entsprechenden Erklärung richtig einem Neuling eine möglichst leichte kurze verständliche Lösung zu geben
Natürlich sollte der Code von Nir-Kun kommentiert sein, so kann man es am leichtesten verstehen (Bei Nir-Kun ist auch der Vorteil von echtem Code [btw kein Pseudo-Code, sondern Code wir er vom EEE entsteht]).
Das ist wie mit dem ATB-KS aus dem E-Book, das ist auch komplizierter als es sein müsste.
Super, vielen Dank für das Tutorial, das hat mir schon geholfen!
Also hab ich doch keine Common Events für jeden Punkt gebraucht, wie ich erst gedacht habe. Jetzt klappt alles genau wie ich es mir gewünscht habe, das Menü lässt sich schließen und jeder Punkt lässt sich aufrufen, wie ich es wollte.
Von der Logik her verstehe ich nun auch alles, war mir am Anfang nur nicht sicher, in wie fern sich das im Maker umsetzen lässt.
EDIT:
Achja, ich hab's übrigens ohne Loop gemacht und es funktioniert trotzdem alles ruckel- und fehlerfrei. Ich weiß zwar, was ein Loop ist, aber wie wirkt sich das denn auf ein Menü aus?
Natürlich sollte der Code von Nir-Kun kommentiert sein
...
Ende ^^;
(und seiner erster Post beinhaltete Pseudocode der für Neulinge schwerer zu verstehen ist als son Maker-Screenshot...)
@Vorredner:
Es ist normalerweise so, dass du solche Menüs auch gerne mal in einem anderen Eventtyp als einem ParallelProcess verwendest. Es ist sogar der normale Weg es über ein Gecalltes CE zu machen.
Achja, ich hab's übrigens ohne Loop gemacht und es funktioniert trotzdem alles ruckel- und fehlerfrei. Ich weiß zwar, was ein Loop ist, aber wie wirkt sich das denn auf ein Menü aus?
...
Sowas kann ein wenig die Optik aufhellen. Nehmen wir an, der wird in die Mitte des Events gesetzt (vorher Befehle und nach dem Loop auch). So kannst du z.B. vor dem Loop alle Variablen auf den Eingangswert setzen, diese dann im Loop solange bearbeiten, bis sie so sind, wie du es willst und wenn der Loop beendet ist, noch die Ausgabe entsprechend realisieren (z.B. eine Textbox, die vom Wert der bearbeiteten Variable abhängig, jeweil einen anderen Text ausgeben kann). Kann man gut nutzen, wenn man komplexere Sachen macht, für die der Code sehr lang werden kann, da vielleicht viel geleistet werden muss. (so nebenbei gesagt, gibt es auch andere Wege, einen Loop zu realisieren, aber für Anfänger reichts alle mal).
Ziemlich wichtiger Punkt eigentlich das mit den Variablen setzen... Normalerweise ist es nich so dolle wenn man in seinen Corsur-Positionen mit einer 0 anfängt zu zählen... Also dass der erste Menüpunkt mit einer 0 beginnt... liebermit einer 1, das ist einfacher im Hinterkopf zu behalten, nur muss man dazu dann beim Initiieren des Menüs eben die Pos-variable mal auf die 1 setzen damits klappt.
Das Optische stimmt schon wobei ein komplexeres Script innerhalb des Loops auch schnell unschön ausschaut. Aber so wäre die Schoße schneller zu kopieren.
Ein schöner Punkt ist auch das Arbeiten mit Labels und Loops. So kannst du auch ganz schick mal zu einem Label springen wenn du ein weiteres kleines Menü aufrufst (z.b. eine "spiel wirklich wirkliche beenden?" abfrage)... musst dann natürlich auch ein Label definieren, dass ganz am Ende steht... ich hab das sehr oft bei meinem scriptingstil dass ich aus nem loop springe und zu labels verweise... einfach um das iwrgendwie zu strukturien.. man muss nur schauen, dass man bei irgendwelchen Abbruchaktionen ein Label hat, das ganz unten im Event steht, auf das dann im FAlle des Menüabbruchs hingesprungen wird damit der sonstige Code im Event nich angesprochen wird.
So, ich hol meinen Thread noch mal hoch wegen einem neuen Problem.
Noch einmal großen Dank für die letzten Posts, ich habe sie durchdacht und habe beim weiteren Arbeiten am Menü auch gleich verstanden, wozu die Loops gut sind! Macht die weitere Menüführung teilweise viel bequemer.
Nun habe ich jedoch ein neues Problem, an dem ich schon eine Weile hänge. Folgendes:
Ich habe eine Auswahl mit 3 Zeilen und 5 Spalten, wobei die zweite Zeile Lücken hat. Es handelt sich um eine Art Fähigkeitenbaum und in der zweiten Spalte gibt es nicht 5 Fähigkeiten, sondern nur 3.
Die Position beginnt bei mir mit der Variable 0, bei horizontalen Bewegungen (in der Zeile) zählt es sie -1 für nach links und +1 für nach rechts. Für vertikale Bewegungen zählt es -10 für nach oben und +10 für nach unten.
Alles in Einem kein Problem, nur die Lücken in der zweiten Spalte sind eben ein Problem. Ich will, dass man über die Lücken "springt". Sie zählen grundsätzlich ja als Position (in der Tabelle), für den Benutzer ist dort jedoch keine Fähigkeit.
Wie richte ich das denn ein?
Ich habe es schon mit solchen Sonderfällen versucht, die werden jedoch ignoriert:
If Var [Position] is 0 (also 1. Zeile, 1. Spalte)
If Var [Tasten] is 1 (also Taste nach unten)
Set Var [Position] is 20 (also direkter Sprung von 0 zu 20 anstatt auf 10, weil auf 10 z. B. keine Fähigkeit ist)
End
Ich hoffe, mein Problem ist klar dargelegt und wenn nicht, kann ich es ja noch mal als Bild darstellen.
Dadurch müsstest du ja dann 8 Sonderfälle haben, nämlich, wenn man über, unter, links, oder rechts neben diesen Lücken steht. Das heißt, dass du jeden dieser Fälle manuell abfangen musst, indem du z.B. die Position, an der der Charakter, Cursor (was halt verwendet wird) ermittelst, dann eine Tastenabfrage machst und wenn es eine Richtung ist, die auf so eine Lücke führt, dann lässt du den Cursor zwei Schritte wandern und gibts den richtigen Wert (+-20) aus.
Außerdem solltest du dich mal entscheiden, ob das jetzt ein Baum, oder eine Matrix (bzw. Tabelle) ist
Zitieren
)
