Schadensberechnung AKS

[Chemluth]

ist nicht viel Rechnung... du planst einfach 2 Waitevents ein... das eine machst du davon abhängig wie viel Geschick du hast und das andere von der Rüstung...

[Corti]

Ich möchte dir einen Rat zukommen lassen. Machs nicht zu kompliziert.

Statsvergabe kann helfen, dem Spieler die Möglichkeit zu geben, zu prägen, wie sich sein Charakter spielt, das ist toll, weil Spieler das Gefühl hat, es sei seine geistige Leistungs/Entscheidung, die dazu führte, dass er die Gegner wegsmasht.

Mal was grundlegendes zu Stats und deren Berechnung, weil ich das Gefühl hab, dass du da bei einigen Sachen durcheinander gekommen bist. Die Stats, deren Beschreibung sollte imo vermitteln, welcher Weg zum Ziel durch dessen Wahl gegeben wird.

Beispiel:

• Stärke -> Härter zuhauen
• Kritisch Treffen -> Chance doppelten Schaden zu machen
• Tempo -> Schneller schlagen, öfter handeln
• Verteidigung -> mehr wegstecken können

Ein Kniff um das ganze rechnerisch äquivalent zu machen ist folgender:
Es gibt einen verstecken Grundschadenswert, und alle anderen Stats werden prozentual dazugerechnet. Normalweise wird Atk oder wie es auch heisst immer direkt in die Formel verrechnet als Atk-Def oder so, dieser Ansatz verrechnet Atk als zusätzliche Prozente an Schaden.

Beispiel:
+Spieler verursacht auf nem bestimmten Level 100 Schaden.

Alle Werte (Stärke, Crit,Tempo) können maximal auf 100 gebracht werden, wobei 1 Statpunkt jeweils 1 % mehr Schaden, 1 % kritisch zu treffen oder 1% Tempo bedeutet.

Annehme: Spieler vergibt 20 Punkte in Stärke, 10 Punkte in Crit und 25 in Tempo.
Ein Schlag macht dann 20% mehr Schaden, also 100 Schaden *1,2 = 120 Schaden und hat eine 10% Chance kritisch zu treffen. Wenn ein Tempo-loser Schlag alle 2,5 Sekunden möglich ist, senkt das Tempo diese Zeit auf 2,1875 Sekunden. (denk dran: 100% Tempo entspricht nicht 2,5 Sekunden sondern, 1,25 weil dadurch die Zeit zwischen schlägen halbiert und der Schaden / Zeit verdoppelt wird -> +100%)

Woher kommt der Grundschaden:
Der basiert auf dem Level des Charakters. Mit jedem Level wird er etwas stärker. Im Maker gibts diese Statskurven, die kann man schön manuell auslesen und dafür verwenden. Somit ist für jeden Charlevel ein Zahlenwert verfügbar. Dieser Zahlenwert wird jeweils um die Prozente modifiziert.

Stichwort Einseitige Statsvergabe:
Das Makerspiel "Der schwarze Magier" löst das wie folgt. Man bekommt keine Statspunkte, die man vergibt, sondern neutrale Punkte. Statserhöhungen werden von diesen neutralen Punkten erkauft. Je mehr Stärke man zB hat, desto teurer wird der nächste Punkt Stärke, oder vergleichsweise günstiger werden die andere Stats, der Spieler wird also animiert , die andere Stats ein bischen mitzuziehen und kann eher mal einen Stat nachziehen wenn er feststellt, dass er zB zuviel Schaden bekommt weil der Vert. vernachlässigt hat.

____

Wenn Fragen sind, frag. Nur keine Scheu.

[Chemluth]

ein sehr nettes Prinzip... aber ist ein Prozent pro Skillpunkt nicht ein bisschen wenig? so wirkt sich das doch kaum auf den Schaden aus....

[Corti]

Jaein~ die Prozente werde ja auf den Basisschaden draufgerechnet. Jedes mal wenn man ein Level-Up bekommt und damit die Möglichkeit Punkte zu vergeben steigt ja automatisch der Basisschaden. Ein Teil des rohen Kraftgewinnes passiert quasi nur durchs aufleveln, der 2. Anteil passiert durchs vergeben der Punkte, womit der Spieler die Charakteristik des Schadens steuert.

In gewisser Weise ist natürlich 1% mehr Schaden nicht viel. Aber 1% Krit ist auch nicht der Unterschied zwischen nie kritten und dauernd kritten, genau wie zB der Spieler nicht "woah das merkt man voll" denkt wenn du ihm zB 0,5% Ausweichen durch Geschick mitgibst.

In der Praxis wird der Spieler z.B. voll auf Atk gehen, hat dann schnell mal 40 Punkte da drin, und die +40% merkt man dann schon ziemlich deutlich. Gleichzeitig könnte er auch auf 40% Krit. gehen~ der Unterschied ist dann zwischen z.B. 280 Schaden machen oder 200 Schaden und häufig mal 400 durch Krits.

Sinnvoll ist es natürlich, mit dem Basisschaden irgendwo bei 100+ anzufangen, damit die Prozente nicht in den Rundungen verschwinden, aber in nem eigenen AKS sollten Schadenszahlen die bei 100 beginnen und bei 3000+ enden kein Problem sein und schöne große Zahlen aufm Bildschirm hat doch auch was geiles, oder?

Das beschriebene Prinzip habe ich mal für ein javabasiertes AKS erdacht, aus dem leider nie etwas geworden ist, allerdings stecken da schon mehrere Iterationen des Durchdenkens drin, das ist schon solide was die Zahlenwirtschaft angeht.

[Chemluth]

hmm wollte die Zahlen eher klein halten... sind überschaulicher, nicht so protzig und lassen sich leichter anzeigen

ich glaub ich hab mir ein ziemlich umständliches Skript ausgedacht um Schadenszahlen per pictures anzuzeigen.... ziemlich viel Text... wisst ihr ein kurzes einfaches Skript dafür?

[Corti]

• Zerlegen der Zahl in 1er, 10er, 100er etc.
• Reservier dir ein paar Picture-IDs
• Pack die Ziffern nicht in einzelne Pictures, sondern in einige riesige Grafik die dann 10 Pixel breit und 3000 Pixel mit einer Ziffer alle horizontal 300 Pixel
• diese Grafik verschiebst du dann so im Bild, dass die Ziffer angezeigt wird, die angezeigt werden soll.
• Grund: Verschieben (MovePicture) einer riesigen Grafik ist performancesparender als minikleine Grafiken oft neu anzeigen (ShowPicture)

[Chemluth]

das mit dem zerlegen der 1er 10er und 100er hab ich hinbekommen, aber mein Skript ist dafür total umständlich glaube ich... hat jemand vielleicht eine praktischere Vorlage dafür?

hmm bis jetzt hab ich jede Ziffer als einzelnes Bild gemacht... wie sehr wirken sich denn viele kleine Bilder auf die performance aus?

[Nemica]

Naja, Show Picture ist der größte Ressourcenfresser des Makers... je mehr davon desto schlechter.

[R.D.]

Naja, Show Picture ist der größte Ressourcenfresser des Makers... je mehr davon desto schlechter.

...

Das ist nicht ganz richtig, sobald du ein Bild angezeigt hast isses okay, dann bleibst auch da und mve picture Befehle verbrauchen kaum was. Es ist nur ein Problem wenn du in einer Schleife ein Bild per ShowPicture Befehl immer wieder anzeigst, also mit kaum waits dazwischen.

[Chemluth]

kommt es dabei auf die Anzahl der angezeigten Bilder auf dem Bildschirm an oder darauf wie oft Bilder angezeigt werden?

[Nemica]

Ich bezog mich auf die Anzahl der Show Picture Befehle, nicht die Pictures selbst.

[Corti]

Ich erklärs mal so:

• 10 Verschiedene Ziffern per ShowPicture auf einer Picture ID anzeigen funktioniert, führt aber zu ner kleinen Verzögerung, je nach Rechner und anderen Geschehnissen kaum merkbar bis leicht nervig, in nem AKS wenn viele Bilder animiert werden kann das zum Problem werden. Vorteil: du verballerst nur eine Picture ID
• 10 verschiedenen Ziffern als 10 kleine Bilder laden (per Show Picture) und dann mit MovePicture anzeigen, was man grad braucht ist im Livebetrieb am schonendsten. Nachteil: 10 Picture IDs verbraten und davon hat man je nach Version nur begrenzt.
• Der "Kniff" ist das große Bild, auf dem sie einzelnen Ziffern sind. Das große Bild wird einmal geladen, das frisst Performance, und dann nur verschoben, was sehr performanceschonend ist. Trotzdem braucht man so für 10 Ziffern nur eine Picture ID zum anzeigen.

Hier, evtl. hilft das hier zum Verständnis: