Selbstgemachte Item-Menüs

[Alan]

Hallo Leute,

ich hätte da mal eine Frage an euch: Nehmen wir an, ihr habt ein RPG-Projekt am Laufen, das relativ umfangreich werden soll. Nun wollt ihr ein Item-Menü basteln - aus Pictures. Das Problem: Es werden VIELE Items werden und die Anzahl der unterschiedlichen Items steht zum Zeitpunkt der Menüerstellung noch NICHT fest (wird sich aber im Bereich von 100-150 Items bewegen). Und jetzt die Frage: wie macht ihr das? Eine Liste, oder doch ein Raster (vergleiche Zelda)... Was sagt ihr dazu? Welche Methode erscheint euch als guter Durchschnitt zwischen Übersicht und Einfachheit der Technik? Schwierige Frage, ich weiß. Kann mir jemand helfen, der damit schon Erfahrung hat?

[MysticT]

Also ich bevorzuge eine Liste, die sich dann eben auf mehrere Seiten verteilt...
Man kann natürlich auch ein Raster machen (dann nimmt man aufgrund der enormen Items-Zahl lieber CharSets), allerdings kann man dann meist nicht genau erkennen, was dieses Item darstellen soll. Das liegt eben hautpsächlich an der Auflösung. Der Spieler wird also mehr nach oben (oder sonstwohin) gucken, wo der Name des Items angezeigt wird...
Und in diesem Fall ist man eigentlich auch wieder bei der Liste.:p
Wenn du zu Beginn des Spieles aber schon sehr viele Items planst, aber noch nicht weißt, wie viele es dann sein sollen, bietet sich aber doch eher das Raster an... Man kann natürlich auch ein Raster (oder auch eine Liste) so skripten, dass alle Items immer ab dem Beginn aufgelistet werden und keine feste Position haben, jedoch ist das ein Haufen Arbeit. Jedes mögliche Item müsste also in das Positions-Event aufgenommen werden, wobei dann bei 99 Schluss ist (mehr Event-Seiten hat ein Event nicht). Mit Positions-Event meine ich eine spezielle Item-Position, z.B. in der Liste, den obersten Eintrag. Und du musst verhindern, dass Items doppelt angezeigt werden. Je mehr Items desto mehr Aufwand wird das, weshalb es sich in meinen Augen nicht lohnt.... es wächst einem irgendwann über den Kopf.

So, wie ich dein Anliegen jetzt verstehe, wäre daher der Beste Kompromiss ein Raster mit festen Positionen. Meine Meinung, vielleicht fällt dir auch was Gutes zur Problematik der Grafiken ein.

Viel Erfolg!

[Alan]

@ MysticT: Ja, in diese Richtung gingen auch meine Gedanken. Ich hab auch schon mal ein Item-Menü gemacht, das bis zu 100 Items auf einer Liste darstellen konnte, von denen man immer 5 gleichzeitig sehen und dann eben scrollen konnte, aber das war dermaßen viel Arbeit, da beispielsweise ein Item hinzuzufügen, dass ich beschlossen habe, dass sich der Aufwand nicht lohnt... Ein Raster wäre also auch deiner Meinung nach die beste Lösung, eventuell noch mit mehreren Seiten zum Umschalten (eine Seite Waffen, eine mit Rüstungen, eine mit Schlüsselgegenständen usw.) Allerdings glaube ich nicht, dass es nicht realisierbar ist, das Raster so zu gestalten, dass die Items "nachrücken", also ohne feste Positionen, da hab ich schon einen Plan, es ging nur mal um die prinzipielle Entscheidung ob Listen oder Raster besser sind. Thanx für deine Meinung!

Möchte sonst noch jemand etwas dazu sagen? Eure Meinungen sind stets willkommen!

[Kelven]

Ich greife in solchen Fällen meistens zu einer Ringliste. Jeder Gegenstand hat eine feste Position, wird aber nur angezeigt, wenn er auch tatsächlich im Besitz ist. Das würde bei 5 Plätzen in der Liste so aussehen:

Aktueller Gegenstand - 2
Aktueller Gegenstand - 1
Aktueller Gegenstand
Aktueller Gegenstand + 1
Aktueller Gegenstand + 2

Wenn man weniger als 5 Gegenstände hat, werden einige doppelt angezeigt, aber damit kann ich leben, da sowieso nur auf den aktuellen Gegenstand zugegriffen werden kann. Bewegt der Spieler nun den Cursor, wird die Liste solange durchlaufen, bis ein Gegenstand erreicht wird, der im Besitz des Spielers ist. Bei der Liste haben die Gegenstände wie gesagt eine feste Position, d.h. ID 1 ist z.B. immer ein Heiltrank usw. So ist das Hinzufügen von neuen Gegenständen auch kein großes Problem.

[Alan]

@Kelven: Na, genau so hab ich das damals doch auch gemacht (Sogar mit einer Windows-mäßigen Scrolleiste am Rand) - allerdings muss man nach jedem Mal, wenn der Spieler durch die Liste scrollt, die Picture-IDs neu verteilen, da man insgesamt ja nur 50 zur Verfügung hat (RPG-Maker 2003 bzw. 2000 mit Picture-Patch). Hat man jetzt über 50 Items, kann nicht jedes Item seine eigene ID haben, daher müssen die IDs auf die im aktuellen Listenausschnitt angezeigten Items verteilt werden, die sich ja bei jedem Tastendruck verändern - und diese Bedingungs- und Anzeigeliste wird bei 100 Items ganz schön lang, zumal das ja in zwei Richtungen, nach oben und unten, funktionieren muss... Das System an sich finde ich aber sehr schön, ich wünschte, ich könnte das so machen, aber bei einer dreistelligen Itemanzahl steckt da SO viel Arbeit dahinter, das ist es mir nicht wirklich Wert, wenn ich ehrlich bin...

Aber Moment, mir fällt gerade ein, wenn ich die ganze Itemliste in Bereiche unterteile (Waffen, Rüstungen etc.) würden es vermutlich in keiner Kategorie viel mehr als 30 werden, das wäre dann wieder ein vertretbarer Aufwand... Irgendwie bin ich aber immer noch ein Freund des Rasters - ich bin so hin- und hergerissen zwischen diesen Methoden ;)

[Caine Luveno]

Die Liste wird gar nicht lang XD

Bzw. Ich habe zwei Events ind enen ich ein neues Item einfügen muss. Einmal das Event zum auslesen mit "Have Item"-Condition und ein Event welches das Picture anzeigt.

Mehr nicht ^^ Alles andere macht mein Script. ^^

Und das ist weißgott nicht viel Arbeit. XD

[Kelven]

@Alan
Man braucht nur 5 Pictures, eines für jeden Platz in der Liste. Natürlich müssen die Bilder dann immer ausgetauscht werden, wenn der Spieler in der Liste weiterschaltet. Die Liste selber ist wie ein Ringmenü aufgebaut. Ein Eintrag ist immer im Fokus und auch nur der kann ausgewählt werden. Die anderen Einträge sind nur zur Anzeige da. Für die Anzeige der Pictures brauchst du 5*(Anzahl der Gegenstände) Forcs. Mit dem XP wäre das einfacher, da man dort Text direkt auf den Screen zeichnen kann.

[Alan]

@Caine Luveno: Funzt das auch bei mehr als 50 verschiedenen Items im Inventar? Also entweder hast du da ein echt geniales Skript oder wir reden nicht ganz vom selben Problem...

@Kelven: Das mit dem Fokus versteht sich von selbst. Allerdings habe ich das so gemacht:

Eine Map mit 4 wesentlichen Events. Event 1 ist das Steuerevent, läuft auf parallelem Prozess und fragt die Tasten ab bzw. ergreift dann die entsprechenden Aktionen. Bei den Tasten oben und unten wird jeweils eines der anderen Events aufgerufen, die "Scroll up" und "Scroll down" heißen. Sie speichern lediglich die Picturebewegungen. Sobald die Bewegungen erfolgt sind, wird das letzte Event in der Kette aufgerufen. Es dient sozusagen als "Refresher" (blöder Name, aber was besseres ist mir nicht eingefallen). Es macht im Prinzip nichts anderes als nachzuschauen, welche Item-ID gerade den Fokus hat und dann alle 5 Pictures neu zu setzen - und DA gibt es dann eine Monster-Bedingung ab.

Vielleicht geht es anhand eines Beispieles anschaulicher: Die 5 Items aus dem Listenausschnitt haben von oben nach unten gesehen die IDs 1 bis 5. Die ID's 1 und 5 sind unsichtbare Pictures, die die nächsten Elemente der Liste darstellen, sobald diese verschoben wird. 2 und 4 sind halbtransparent und 3 ist vollständig sichtbar (Fokus). Jetzt wird die Liste um 1 nach unten gescrollt - 1 wird gelöscht, 2 wandert auf die Position von 1, 3 auf die Position von 2 und so weiter. Damit das auch beim nächsten Aufruf klappt, kommt der Refresher dazwischen. Das Picture, das die ID 2 hat und auf der Position von Picture 1 sitzt (daher unsichtbar ist), bekommt die ID 1 zugewiesen, die ID 3 wird zu 2 und so weiter, wobei 5 dann zu einem komplett neuen Item wird, das vorher nicht im Listenausschnitt war. Und genau beim Refresher spießt sich das Ganze dann, weil man erneut den Besitz jedes Items überprüfen muss und dazu noch feststellen muss, ob das Item gerade auf der Liste ist und wenn ja auf welcher ID. Das sind dann EINIGE Bedingungen, vor allem mit vielen Items. Einfacher wäre es natürlich, jedem Item eine Picture-ID zu geben, doch dann beschränkt sich deren Anzahl auf 50...

Oder habt ihr da ein anderes System? Also, es ist zwar schon lange her, dass ich dieses System auf die Beine gestellt habe, aber eine bessere Lösung fällt mir auch heute auf die Schnelle nicht ein...


Apropos XP: Kennt ihr ein gutes Tutorial, mit dem man Ruby von Grund auf lernen kann (also auch, wie man es richtig in den "normalen" Makercode einfließen lassen kann und so)? Ich kenne beispielsweise Delphi, das ist Ruby recht ähnlich, doch die Synthax ist eine komplett andere, aber das nur am Rande...

[übelster Held]

hier.. hab ich irgendwann mal gemacht (2k):
http://rapidshare.com/files/22283618/itemmenue_ueHseins.rar.html

zeigt items in chronologischer reihenfolge an...
(wenn ein item aufgebraucht wird, wird das darauffolgende angezeigt...)
zwar werden die bilders nicht so mit fokus angezeigt, sondern
bisschen anders, das zu verändern dürfte aber kein prob sein...
(schließlich sollst du dich von den code nur inspirieren lassen...^^)
sollte eigendlich beliebig erweiterbar sein...

mfg
üH

@ roter zahn: gitti gitt..^^

[Pincky]

@üH

Danke:D
genau sowas hatte ich auch gebraucht *abschleck*;)

[Alan]

@übelster Held: Wow, also ich muss es mir noch genau ansehen (hab ich im Moment leider gerade keine Zeit für), aber DAS sieht doch mal vielversprechend aus! Ich muss mich aber erst in den Code einlesen, sollte ich Fragen haben - darf ich mich dann an dich wenden? :D Nein, ernsthaft, erstmal vielen Dank!

OK, also wenn dieses Item-Menü hält, was es verspricht, dann habe ich eine Lösung für mein Menü gefunden - aber wenn sonst noch jemand Vorschläge, Anregungen etc. hat, dann tut euch keinen Zwang an :D