[VX Ace] 2 Fragen

Hallo, ich komm grad bei 2 Dingen nicht weiter...
1. Bei dem Befehl "Display Choices" erscheint ja so ein Fenster mit Auswahlmögklichkeiten. Allerdings immer nur am rechten Rand. Wie kann ich also jetzt das Fenster zB am linken Rand oder in der Mitte erscheinen lassen? Das geht bestimmt über Scripte, aber da hab ich keine Ahnung von, kann mir da jemand helfen?
2. Die Schadensformel bei den Skills. Ich weiß nicht, was damit los ist, aber irgendwie will der Maker nicht so rechnen wie ich das beabsichtige. Hat der etwa ein Problem mit zu hohen oder zu niedrigen Zahlen?? Ich blick da echt nicht durch und das nervt mich um ehrlich zu sein. Also im groben ist meine Frage so: Kann mir jemand die Schadensberechnung erklären?^^

Das wärs. Wer sich damit auskennt, kann ja was schreiben, wär nett.

Zu 1: Du machst bestimmt eine Textbox und direkt danach den Chow choices Befehl?
Wenn man halt nur ein bischen Text hat so ist die Anzeige wie bei dir.
Entweder hinter die Textbox noch eine Leere Textbox machen.
Dann ist die Chow choices da wo die Leere Textbox eingestellt ist, also oben mitte oder unten +Halt Transparent oder Normal.
Dadurch das da dann nicht noch bischen Text bei der Choice steht, so sollte die Choice nun mittig sein.
(Habs nicht getestet aber so ähnlich wars damals beim VX, falls das nicht klappt nochmal schreiben dann Teste ich es noch mal durch)

Teilst du bei deinen Schadensformeln so das Kommawerte rauskommen? Der Maker kann kein Komma rechnen und somit kann es zu rundungsfehlern kommen.
Lösung: Die Zahlen vorher z.B mit 10 000 mal nehmen, dann die Berechnung normal durchführen und anschliessend das ganze durch 10 000 Teilen.
So in der Art klappte das bei einem Anzeigefehler eines "Event HUDs" wo die Rundungsfehler dazu führten das die HP falsch angezeigt wurden.
Ansonsten bitte mal die Formeln Posten und Fehler genauer beschreiben.

Hoffe das hilft, Gruß Bex

Huhu,

Zu 1)
Ein einfaches Script dafür wäre z.B. dieses:

Code:

---

class Window_ChoiceList < Window_Command
 
  POSITION_VARIABLE_INDEX = 17

  alias_method(:update_placement_without_useChoiceAlign, :update_placement)
  def update_placement
    update_placement_without_useChoiceAlign
    case $game_variables[POSITION_VARIABLE_INDEX]
    when 0  # Left Alignment
      self.x = 0
    when 1  # Center Alignment
      self.x = (Graphics.width - width) / 2
    when 2  # Right Alignment
      self.x = Graphics.width - width
    when 3  # Next-To-Player Alignment
      if $game_player.screen_x * 2 > Graphics.width
        self.x = [$game_player.screen_x - width - 32, 0].max
      else
        self.x = [$game_player.screen_x + 32, Graphics.width - width].min
      end
    end
  end
end

---

Die Position der Auswahl kann anschließend mit der Variablen gesteuert werden deren Index in Zeile 3 des Scripts angegeben ist:
Variable auf 0: linksbündige Auswahl
Variable auf 1: zentrierte Auswahl
Variable auf 2: rechtsbündige Auswahl
Variable auf 3: spielernahe Auswahl
Alle anderen Werte: Standardausrichtung


Zu 2)

Ergänzend noch zwei weitere Möglichkeiten Rundungsfehler zu minimieren:

- nach Möglichkeit erst multiplizieren und danach dividieren:
a.hp / a.mhp * 100 # => 100 bei voller HP, ansonsten 0
a.hp * 100 / a.mhp # => Gesundheit in Prozent, ohne ganzzahlige Verluste

- mit Fließpunktzahlen arbeiten:
12 / 7 # => 1
12.0 / 7 # => 1.7143
Zu beachten ist dabei dass das Spiel bei Divisionen zweier ganzer Zahlen abrundet, auch wenn das Ergebnis mit einer Fließpunktzahl multipliziert werden würde. Nur wenn bei einer Operation mindestens einer der beiden Operanden eine Fließpunktzahl ist wird auch das Ergebnis als Fließpunktzahl interpretiert.
Gerechnet wird dabei grundsätzlich von links nach rechts, wobei jedoch Klammerregelung und Punkt-vor-Strich-Regelung gelten.
12 / 7 * 1.0 # => 1.0 , da 12 / 7 zuerst ausgerechnet wird
1.0 * 12 / 7 # => 1.7143

Ansonsten sollte der Endschaden nur noch von folgenden Faktoren abhängen:
- Anfälligkeit des Ziels gegenüber dem Schadenselement
- physische/magische Schadensrate bzw. Erholungsrate des Ziels (PDR, MDR, REC)
- evtl. Volltreffer- bzw. Verteidigungsbonus sowie Varianz

Andernfalls wäre wie Bex schon schrieb eine etwas genauere Beschreibung hilfreich...

Zu 1: Durch das Script klappt das perfekt. Danke, ETeCe ^^

Zu 2: Das der RPG Maker keine Kommazahlen akzeptieren will hatte ich mir schon so langsam gedacht, finde ich aber blöd. Ist ja jetzt nicht etwas was zu anspruchsvoll wäre, oder? Die Formel war die aus Pokemon:
((2*a.level+10)/250)*(a.atk/b.def)*Basisschaden+2
Aber der Schaden war immer nur 2. Das liegt dann wahrscheinlich daran, dass wenn in der ersten Klammer durch 250 geteilt wird, immer eine Zahl unter 1 rauskommt...
Jetzt mal an die Experten unter euch: Ich hab mir eine eigene Schadensformel ausgedacht und wollte mal wissen ob die so in Ordnung ist, oder ob es daran etwas zu meckern gibt?
((((a.atk*2-b.def)+1)*((a.level*2)/b.level)+((a.atk*2)/b.def)*((a.level*2)/b.level))/2.5)+(a.atk/10)
Das ist die für den Stinknormalen Angriff also ohne Zauber oder sowas.

Aufjedenfall schonmal vielen Dank für die hilfe euch beiden :D

Ok, Lösung 1 von mir war Falsch.

Zu deiner Formel,kenne mich mit sowas nicht wirklich aus , aber seit wann haben den die Feinde Level? (Meine "b.level" soll doch der Level des Gegners sein? Die haben aber standardmässig kein Level).
Ansonsten etwas zu lang und kompliziert für mich. Darüber hinaus scheint der Angriff enorm mit wachsendem Level und ATK Wert zu steigen.

Hast du schonmal mit dem Gedanken gespielt den normalen Angriff komplett rauszunehmen und das nur über verschiedene Skills zu machen?
Das ja das Coole beim Ace man kann Waffen ausrüsten und solange sie ausgerüstet ist hab ich nen bestimmten Skill z.B.
Dann mach ich mir ein Paar passende Skillgruppen (z.B. Waffe,Zauber etc... oder ich mach mir die Mühe das die Skilllgruppe Äxte nur erscheint wenn ich eine Axt ausgerüstet habe, und das ich dann noch verschiedene andere Axttechniken lernen kann. Hoffe man versteht das späte kaudawelsch.
Angriffsbutton also komplett raus, oder gucken ob man den zu Gegner Analyse umbaut, oder irgend etwas anderes witziges.
Cool wäre auch dann könnte alles seine eigene Formel haben.

Gruß Bex

Ich hab das jetzt mal ausprobiert. Wäre mal eine Idee, aber ich weiß nicht so recht...
Und Stimmt, standardmäßig haben die Gegner kein Level. Aber ich hab das Gegner-Level Script von Yanfly drin ^^
Ich weiß aber immer noch nicht, was ich für Schadensformeln nehmen soll. Nur a.atk*2-b.def ist mir zu billig. Gibt es nicht irgendwo ein Tutorial für Schadensformeln? Es gibt doch zu alles mittlerweile Tutorials xD

Wie gesagt, du kannst mit Kommazahlen rechnen. Das passiert allerdings nur wenn du in deiner Rechnung Kommazahlen angibst.

Grund dafür ist einfach der dass die Schadensformel intern wie ein Scriptbefehl übersetzt wird und damit an Rubys Konventionen gebunden ist. Ein ganzzahliges Ergebnis ist bei der Division häufig ausreichend bzw. sogar erwünscht (unter anderem da Fließpunktzahlen nur eine gewisse Genauigkeit haben).

Rundungsfehler könntest du bei der genannten ersten Schadensformel wie geschrieben minimieren:

10000*(2*a.level+10)/250*a.atk/b.def*Basisschaden/10000+2 # <= Multiplizieren mit hoher Zahl

(2*a.level+10)*a.atk*Basisschaden/250/b.def+2 # <= Umstellen nach Multiplikation

((2*a.level+10)/250.0)*(a.atk/b.def.to_f)*Basisschaden+2 # <= Verwenden von Fließpunktzahlen wenigstens an kritischen Stellen



Zu deiner neuen Formel kann ich selbst nicht viel sagen... Am einfachsten denke ich ist es du probierst die Formel einige Male mit verschiedenen für dein Spiel realistischen Werten durch und schaust was herauskommt. :)
Ansonsten dürften die Präferenzen bei Schadensformeln vermutlich etwas auseinandergehen...

ED: Zu langsam für:

Ansonsten hat Bex aber recht, Gegner haben normalerweise kein Level. Die Formel dürfte derzeit einen Fehler verursachen wenn du versuchst das Level eines Gegners zu ermitteln (was dazu umgebogen wird dass die Formel 0 als Ergebnis ergibt).

Möglichkeiten das zu Umgehen wären entweder eine Abfrage:
(a.actor? ? a.level : 10) # <= Wenn a ein Actor ist verwende sein Level, ansonsten 10

Oder (wieder einmal) eine Scripterweiterung:

Code:

---

class Game_Enemy < Game_Battler

  def level
    return 10
  end
end

---

In Zeile 4 kann dabei bestimmt werden welchen Wert ein Gegner als Level ausgeben soll. In diesem Fall wird für alle Abfragen 10 verwendet.

Zitat:

---

Zitat von keB

((((a.atk*2-b.def)+1)*((a.level*2)/b.level)+((a.atk*2)/b.def)*((a.level*2)/b.level))/2.5)+(a.atk/10)

---

Nicht, dass ich deine Formel würde kritisieren wollen, ohne den Kontext zu kennen, allerdings scheitere ich grade bei dem Versuch, mir vorzustellen, welchen Sinn du mit einer derart komplexen Schadensformel verfolgst. Denn irgendwie habe ich so meine Zweifel, dass du bei einer solchen Formel überhaupt noch abschatzen kannst, welchen effekt welches drehen an welchem Rädchen auf den Gesamtschaden hat. Das erscheint mir als eine unnötige erschwerung des Balancings. Nur ein kleiner Punkt, der mir so aufgefallen ist:

Abgesehen davon, das die Abfrage des Gegnerlevels ein Externes Script erfordert, ist das Ergebniss von diesem Ausdruck hier in der (Spiel-)Praxis vollkommen unberechenbar:

((((a.atk*2-b.def)+1)*((a.level*2)/b.level)

Wenn du als Stufe 1 Charakter einen Stufe 2 Charakter angreifst, wird das Ergebniss durch die rechnung zu ((a.level*2)/b.level) => ((2)/2) => (1). Damit wird das Spiel in der Anfangsphase praktisch unspielbar, weil du schon einem Gegner, der nur eine Stufe Vorsprung hat, kaum mehr Schaden zufügst ... ca. die Hälfte gegenüber einem gleichstufigen gegner. Bei ansteigendem Level ... also wenn man grade erwarten sollte, das der Schwierigkeitsgrad des Spiels ansteigt, verliert dieser rechenschritt hingegen zunehmend an Wirkung und wird schließlich absolut nutzlos.

Wenn du als Stufe 50 Charakter einen Stufe 80 Charakter angreifst, sieht die Formel schon so aus: ((a.level*2)/b.level) => ((100)/80) => (1,25). Tatsächlich fügst du also jetzt einem Gegner, der schlappe 30 Level höher ist als du, ca. 25% mehr schaden zu, als einem gegner, der zu Spielbeginn 1 Stufe höher ist, als du.
Sind hingegen beide Charaktere auf dem selben Level fügst du gleich DOPPELTEN Schaden zu ((a.level*2)/b.level) => ((100)/50) => (2)

Im Klartext bedeutet das für dein balancing also:
Wenn der Level des Gegners zwar höher ist, als deiner, aber weniger als Doppelt so hoch, bekommst du immer einen Bonus auf deinen Schaden. Sobald der Level des gegners doppelt so hoch ist (oder noch hoher), wie dein eigener, gibt die Rechnung irgend einen so kleinen Wert zurück, das kaum noch Schaden entsteht. Dadurch ist dieser Rechenschritt um so fataler, jeniedriger der Level der Spielcharaktere ist. Auf Stufe 1 dürften Stufe 2 oder gar Stufe 3 Charaktere bereits unüberwindbare Hindernisse darstellen, während ein Gegner auf Stufe 50 bereits selber Stufe 100 einnehmen müsste, um einen ähnlich fatalen Effekt zu erzielen.



Und jetzt erzähle mir mal Bitte, wie du um eine Schadensformel, die als Stufe 1 Charakter, einen Kampf gegen Stufe 2 Charaktere unmöglich macht, aber ab Stufe 50 Bereits keine wirksame Reduktionen des verursachten Schadens mehr zulässt, ein funktionierendes balancing aufbauen willst. Wie ETeCE reichtig erkannt hat, gehen die Präferenzen bei Schadensformeln sicherlich auseinander. Dennoch sehe ich einfach kein Argument, welches für eine Formel im Stile von

Zitat:

---

((((a.atk*2-b.def)+1)*((a.level*2)/b.level)+((a.atk*2)/b.def)*((a.level*2)/b.level))/2.5)+(a.atk/10)

---

sprechen würde, statt einfach ein kurzes, prägnantes (und vor allem leicht im Kopf zu handhabendes!)

Zitat:

---

a.ATK*6-b.DEF*3

---

zu nehmen.

Ich setze bei meinem Spiel voll auf letzteres. Der Vorteil ist, dass ich die Skills nichteinmal testen muss, denn ich weiß bereits im Kopf, das Jeder Punkt ATK den Schaden um 6 erhöht, und jeder Punkt DEF um 3 verringert. Und das ist beim Balancing ziemlich praktisch.


[Edith sagt:] Ein paar kleine korrekturen vorgenommen [/edith]