Magiesystem

1. offizieller Beitrag

    Wie genau geht es wieter mit dem Magiesystem?


    Bleibt es so wie jetzt, das für alle Meisterungsstufen einzelne Dateien vorliegen, oder sollen die später mal für jeden Zauber zusammengefügt werden?


    Also in der Art dass man bei den Kreaturen dann nicht angibt:


    ability meteor_shower_basic


    sondern was in der Art:


    ability
    >> type meteor_shower
    >> mastery basic
    /ability


    oder ability meteor_shower basic


    Jetzt mal egal wie sinnvoll das formatiert ist, aber ihr wisst was ich meine. Das die ability eben ein datentyp mit 2 Variablen ist, solange es sich um ein spell handelt, versteht sich. Müsste man dann spells und abilities trennen?


    Ich würde gern Rahmen für die Meisterungsstufen so wie in H3 einbauen.
    Magieschulen sind erstmal nicht so entscheidend, aber ne Eigenschaft damage_type (physical/fire/earth/water/air/...?) einzubauen wäre sinnvoll, damit man Immunitäten/Resistenzen und andere Schadensmodifikatoren einbauen kann.


    Sollte ja auch machbar sein, dass man Zusatzeffekten bei Zaubern Vorraussetzungen mitgibt, so wie bei den Heldenablities wie "Meister der Stürme". Also so zum Beispiel (wieder mal die Syntax nicht ernst nehmen):
    Müsste dann im code ja nur ne Abfrage passieren, ob die Kreatur (also der Held) die entsprechende ability besitzt.


    effect1 lightning_bolt_damage
    effect2
    >>> requires master_of_storm
    >>> type ightning_bolt_stun
    /effect 2


    Das würde natürlich wieder etliche Freiheiten im Skill und Magiesystem geben, ohne am Quellcode arbeiten zu müssen.

    Ein sehr guter Punkt, den du dort ansprichst! Genau oder so ziemlich genauso wollte ich das umsetzen.


    Zitat

    Müsste man dann spells und abilities trennen?

    Zumindest innerhalb eines Kampfes nicht. Außerhalb des Kampfes hat ein Held dann eben Spruchkenntnis (ja oder nein) sowie diverse Fertigkeiten (Zauberei, Magieschulen etc.). Im von dir beschriebenen Stil wollte ich dann Zauberspruchdateien erstellen, die unter bestimmten Bedingungen einige Faktoren der Sprüche verändern. Herauskommen soll dann eine Ability, die im Rahmen ihrer Inkarnation dann nicht unbedingt wüsste was sie jetzt für eine Fertigkeitenstufe darstellt, aber sich richtig verhält. Für Kreaturen, deren Sprüche eh immer festgelegt sind, würde ich allerdings eher für die herkömmliche Idee plädieren.


    Also im Beispiel sähe das dann so aus:


    slow_unskilled würde halt als effect1 slow_unskilled und eine ATB_cost con 10000 (also einen vollen Zug) standardmäßig besitzen. Je nach Fähigkeiten des Helden werden dann zu Kampfbeginn (oder besser nur, immer wenn sich seine Fertigkeiten ändern, sonst wirds vielleicht ein bisschen viel mit der Ausleserei) seine Zaubersprüche in die passenden Abilities umgeändert. So zumindest ist im Moment Vorstellung (und du hast offenkundig eine sehr ähnliche :) ), damit man für Dinge wie den Eisblitz nicht 32 unterschiedliche Fähigkeiten (4 Grade Spruchmeisterschaft * 2 Grade Meister des Eises * 4 Grade Zaubereibeherrschung, wobei man letztere sicher auch anders einbauen könnte) erstellen muss. Alleine der Übersicht zu Liebe. Zauberei auf diesem Wege einzubauen hätte dann den Vorteil, dass man nicht für Massensprüche explizit wieder einbauen muss, dass es dort nicht wirkt und ähnliche Ausnahmen.


    Zitat

    Magieschulen sind erstmal nicht so entscheidend, aber ne Eigenschaft damage_type (physical/fire/earth/water/air/...?) einzubauen wäre sinnvoll, damit man Immunitäten/Resistenzen und andere Schadensmodifikatoren einbauen kann.


    Ja das wird innerhalb eines näheren Zeitrahmens passieren. Die Funktion TakeDamage() fragt bereits dmg_type (magie, fernkampf, nahkampf, pure) sowie dmg_source (feuer, wasser, erde, luft, physisch) ab. Eine andere Frage ist, bauen wir die Resistenzen in Form von Specials oder als eine Reihe von Eigenschaften (wie Attack, Defense usw.) ein. Ich tendiere im Moment zu Letzterem (wie man das dem User dann präsentiert ist ja nochmal eine andere Frage).

    • Offizieller Beitrag

    Wo wir gerade dabei sind: Ich denke leichter zu lesende Dateien wären nett, im Moment ist es ja immer nur einfacher text.
    leerzeichen und absätze sind sowieso auch ziemlich unpraktisch zum trennen von ausdrücken bzw zum setzen von werten.
    z.B. hier ein hoffentlich besser lesbares Format, würde ein paar Umstrukturierungen mit sich ziehen;
    ich würde nämlich Grundsätzlich nur den Effekt an sich angeben, nicht die mastery-stufe, dass macht es unnötig kompliziert.
    Bei den requirements (jedenfalls so, wie ich das wort verstehe ;) ) stelle ich mir vor, dass man wirklich benötigte Voraussetzungen, um den spell zu casten / die ability zu triggern angibt. So wie es im Moment ist liest es sich noch etwas merkwürdig, natürlich könnte man das aber auch so wie es jetzt ist lassen. Allerdings würde ich es bevorzugen requirement und effect zu trennen
    Trennung könnte grundsätzlich mittels Semikolon ';' erfolgen, Zuweisungen per ="value" .


    Basic Initialization sollte klar sein.
    Requirements gibt nur die Voraussetzungen an, aber nicht, was passiert, wenn man die Voraussetzung erfüllt. Wobei... vielleicht ist das doch doof.
    Mana / ATB Cost braucht nur einen Wert, sonst schreibt man sich nen Wurm, wenn man alle Fähigkeiten und Artefakteffekte(!) berücksichtigen muss, die ihrerseits dann aber entsprechend definiert sein müssen, beispielsweise könnte ein Artefakt so aussehen:




    Ist nur ein Vorschlag, geht mir auch eher um die generelle Lesbarkeit als um die Technik wie was aufgeteilt ist. Wenn man allerdings, so wie es jetzt ist, "verschachtelte" Sachen hat ( wie ich das bei requirement + effect1 verstanden hab ), sollte man das besser erkenntlich machen, beugt dann auch misparsen vor ;D da könnte man dann fast schon xml nehmen ;D
    Beispiel:

    Code
    <requirement value="dark_magic:1">
  <effect value="slow">
    <effect_mastery value="basic" />
  </effect>
</requirement>


    oder sowas... :D


    *Edit*: So wie die slowed.txt im Moment aufgebaut ist, finde ich sie nur sehr schwer zu verstehen und ziemlich untransparent

    Zitat


    leerzeichen und absätze sind sowieso auch ziemlich unpraktisch zum trennen von ausdrücken bzw zum setzen von werten.
    [...]
    Trennung könnte grundsätzlich mittels Semikolon ';' erfolgen, Zuweisungen per ="value" .


    Dass ich im Moment Whitespace zum Trennen verwende hat den einfachen Grund, dass der Streaming-Operator im Zusammenhang mit Filestreams Whitespace bereits als Trennzeichen versteht und so eine Implementierung deutlich leichter macht. Irgendwann können wir gerne einen großartigen Parser einbauen. Wenn man ehrlich ist, ist Whitespace als Trennzeichen nun auch nicht viel schlechter als ein "=" oder ein ";".


    Zitat


    Bei den requirements (jedenfalls so, wie ich das wort verstehe Augenzwinkern ) stelle ich mir vor, dass man wirklich benötigte Voraussetzungen, um den spell zu casten / die ability zu triggern angibt. So wie es im Moment ist liest es sich noch etwas merkwürdig, natürlich könnte man das aber auch so wie es jetzt ist lassen.

    Den Spell überhaupt casten zu können würde bei meinem Beispiel durch "obligatory_requirements" geregelt. Im Normalfall wird das sein, dass ein Spruch bekannt ist und bei höherstufigen Sprüchen das entsprechende Magielevel. Bei Massenzaubern noch die entsprechende Spezialisierung. Das einfache "requirement" in meinem Beispiel gibt einfach nur an, welche Bedingung erfüllt sein muss, damit die Veränderung in der nächsten Zeile (bzw. unabhängig von der Zeile, aber halt der nächste Befehl) gegenüber der grundlegenden Ability stattfindet. Welche Worte dafür nun speziell gewählt werden können wir ja abstimmen ^^


    Zitat

    So wie die slowed.txt im Moment aufgebaut ist, finde ich sie nur sehr schwer zu verstehen und ziemlich untransparent


    Das liegt daran, dass ich sie nicht hübscher geschrieben habe.


    Du kannst allerdings bereits in der aktuellen Implementation beliebig viel Kram (wie Basic Initialisation usw) in die Dateien schreiben, solange du aufpasst, dass die Schlüsselworte direkt (mit irgendwelchem Whitespace dazwischen) von ihren Argumenten gefolgt werden. Wenn du ein Wort verwenden willst, welches beim Auslesen auch eine Bedeutung hat. Dann solltest du das irgendwie _verfremden. Der Sicherheit halber habe ich eingebaut, dass nach // das nächste Wort ignoriert wird und alle meine Kommentare als ein Wort geschrieben. Notwendig ist das eigentlich aber nicht.


    Funktionales Beispiel aus fire_ball.txt:


    Die ASCII-Art oder Kommentare zu den Kommentaren machens jetzt nicht übersichtlicher aber die Botschaft, dass man sich eine große Menge an Lesehilfen selbst hinzufügen kann ist, glaub ich klar.


    Wie auch immer - ich halte es für unsinnig jetzt allzuviel Energie und Zeit in einen besseren Parser zu investieren, weil man
    1.) überraschend viel machen kann in Sachen Lesbarkeit
    2.) eine andere Lösung deutlich aufwändiger, fisseliger und nerviger zu schreiben wäre als es bei dieser Implementation der Fall war.

    • Offizieller Beitrag

    Naja, ich bin es bei meinen Java Projekten so gewohnt, dass ich mir vorher ein dateiformat überlege und mir nen kleinen parser dazu schreibe, denn mit Strings und Dateien rumhantieren geht in Java erstaunlich einfach, wie das in c++ aussieht kann ich natürlich nicht beurteilen.
    Aber es ging mir auch gar nicht ausschließlich um die Lesbarkeit, sondern um so kleinigkeiten wie

    Code
    type 		10				// take_damage
change_type 	0				// absolute
timing 		11				// instantly_after_effect_is_applied 		<-- könnte auch ohne "_" geschrieben



    Ist es nicht schöner "type take_damage" hinschreiben zu können als "type 10"? Da muss man nämlich irgendwann andauernd überlegen was das tut, solange keine Kommentare dabeistehen, die man sich dann wiederum sparen könnte. Wenn ich eine Datei erstellen würde, müsste ich dann ja die zugehörigen Zahlen/Ability-Identifier kennen oder eine komplette Liste haben, da immer rausgucken zu müssen ist nervig.
    Hm, mein Schreibstil klingt immer so angreifend, ist aber nicht so gemeint :D Naja, ich hoffe du weißt was ich meine, ansonsten versuch ich es nochmal zu erklären ^^
    P.S.: Natürlich gibt es auch massenweise fertige (XML-Parser) für C++, das find ich aber unsinnig, wollte ich nur mal erwähnt haben

    Zitat

    Ist es nicht schöner "type take_damage" hinschreiben zu können als "type 10"?


    Ja klar ist das schöner. Für mich persönlich war das nicht so wichtig, aber ich sehe schon, dass ich mit meinem Zahlengedächtnis eher die Ausnahme bin (innerhalb des Codes wird sinnigerweise per Präprozessordefinitionen ohnehin auf Zahlen dafür verzichtet). Da es natürlich sinnvoll ist, wenn auch Andere bereits jetzt damit anfangen können ein paar Fertigkeiten zu schustern, bin ich gerade dabei den Parser in dieser Hinsicht zu erweitern. Zum nächsten Release wollte ich sowieso mal aufschreiben, was es inzwischen alles für Faktoren gibt, welche Werte die haben können und wie das die Fähigkeiten beeinflusst.


    Ich hatte mich zur Klassifizierung wo immer es ging dafür entschieden Integer zu verwenden, weil das imho der mit Abstand elegantere Datentyp ist. Auch deutlich schneller, was vielleicht oder eben vielleicht auch nicht bei fortgeschrittenem Projektstatus mal eine Rolle spielen könnte.


    Zitat

    Hm, mein Schreibstil klingt immer so angreifend, ist aber nicht so gemeint

    Passt schon :) Du bist halt sehr motiviert bei der Sache ;)


    Zitat

    Natürlich gibt es auch massenweise fertige (XML-Parser) für C++, das find ich aber unsinnig, wollte ich nur mal erwähnt haben


    Wenn ich Ahnung von XML hätte und/oder ich nicht beim Programmieren noch so viel Neues lernen würde, wäre ein fertiger XML-Parser vermutlich die schönere Alternative gewesen. Das Schöne ist ja, dass man das im Zweifelsfall relativ leicht austauschen kann, falls ein Mensch mit entsprechenden Kenntnissen hier auftaucht.

  • Forum

    Hat das Thema geschlossen.