@ Corti
Ja, wir reden aneinander vorbei. Die Reihenfolge der Rucksacksachen wird durch die Database vorgebeben, da ist die Sortierung gespeichert und das wissen wir ja auch beide, wie es aussieht. Ich beziehe mich auf die Grundeinstellung des Makers, oder in anderen Worten: auf die Art und Weise, in der die Entwickler des Programms die verschiedenen Items schon einmal vorsortiert haben. Hält man sich daran und wirbelt das nicht kopflos durcheinander, hat man eine geschickte Anordnung, mit der tendentiell häufig genutzte Dinge auch schnell über die Inventarsteuerung erreichbar sind, weil sie eine entsprechende Item-ID verpasst bekommen haben. Für ein Spiel mit herkömmlichen Spielzuschnitt sehe ich das als sehr nachahmenswert an, die Item-ID zugleich als Prioritätsangabe (Wie häufig muss der Spieler darauf zugreifen?) zu begreifen und entsprechend zu stapeln. Dadurch wird der zu Threadbeginn erwähnte vollgestopfte Rucksack nicht mehr zu einem organisationschaotischen Problem, nur weil schnell ein Heiltrank eingeworfen werden soll. Kurzfassung: Ich preise die Weisheit Enterbrains.

Zitat Zitat
Rechnest du da irgendwie rum oder sowas?
Durchaus, aber nur irgendwie und mit kräftiger Hilfe meiner beiden Kumpels hohle Hand und Bauchgefühl. Die in sich ausbalancierten Grundeinstellungen des Makers auch bei den Eigenschaftswerten (bitte kein neues Missverständnis ) lassen das ganz gut über den Daumen abschätzen und Nachkommastellenkorrelationen im Werteverhältnis der Hauptattribute als ziemlich überflüssig erscheinen.
Ein Vergleich aus dem RM2003: Standardheld Fiona hat auf Stufe 1 einen Attack-Wert von 39, auf Stufe 99 steigt der Wert auf 489 an. Ihre Agility beträgt auf Stufe 1 ebenfalls 39, auf Stufe 99 dann 514. Setzen wir das mal in Beziehung.
Auf Stufe 1 ist das Attack-Agiliy-Verhältnis genau 1:1 und damit schön kongruent. Wäre es 1:2 müsste man attributverändernde Waffen/Dinge entsprechend gewichten, also beispielweise einen Nachteil von einem Attackpunkt mit zwei Bonuspunkten für Flinkheit ausgleichen. Ginge auch, muss man aber gar nicht erst, da sich ja die Frage nicht stellt. Und dieses schöne 1:1-Verhältnis setzt sich fast ungeschmälert fort. Auf Stufe 99 ist es in der Pedantenkrümelberechnung dann ganz genau bei 1: 1,05112474... Wegen einer 5%igen Abweichung fange ich nicht an, Ausgleichstabellen und Behelfsrechenmodelle anzufertigen. Da bin ich generös und sage: Passt doch.
Der Vorteil ist nun ein doppelter. Als Entwickler ist es für mich einfacher, mit so gut wie deckungsgleichen Wertmäßigkeiten zu hantieren. Ich sage beispielsweise, beide neuen Helme geben dem Spieler einen Bonus von 4 Punkten, aber nur bei einem gehen alle Punkte in den Defense-Wert, beim zweiten teilt sich das hälftig in Defense und Mind (gut gegen Zauberattacken) auf. Und der Spieler hat es bei seinen Entscheidungen auch übersichtlich und kann ohne Spielregelstudium die Möglichkeiten auf seinen Geschmack anpassen. Mache ich als Entwickler meine Sache gut und setze den Spieler unterschiedlichen Herausforderungen aus, wird der womöglich auch beide Helme behalten und je nach Situation seine Leute neu ausrüsten. Taktik kann schon vor dem Gefecht beginnen.
Das Zahlenbeispiel setzt nur eines voraus. Man muss die austarierte Database des Makers in zumindest ähnlicher Form, die das Gewichtungsverhältnis wahrt, übernehmen. Wer an der Parameter Progression oder der Erfahrungspunkteanordnung für den Stufenanstieg herumspielen möchte, wer großflächig neue und mit dem Original nicht mehr in Beziehung stehende Zahlenwerte bei den Skill- und Itemwirkungen einträgt, wer Monsterwerte aus ihrem makervorgebenen Verhältnis von Stärke und Erfahrung löst, hat dann auch eine völlig neue Balance zu entwickeln. Wer da ändert, ohne sich recht umfassende Gedanken gemacht zu haben, ist entweder ein Glückspilz, falls das Spiel dann immer noch funktuioniert, oder hat ein schlecht balanciertes Spielspaßgrab mit Frustgarantie/Anforderungsarmut fabriziert.