Attributes, Stats, & Modifiers, oh my!

[Gleeok]

Yeah that makes sense. So order would not matter in that case...but they'd need to be calculated separately.

Should items only increase a percentage of the base stats, or should we add the bonuses first, add the percentage modifiers second, and then calculate?
..and I guess "buffs" should treat the "base" value as all equipped values + base value.

OR, I can add overloaded methods to the script "actors", use the above calculations by default, and you can change the default behavior by editing the base character script.

..complications make it fun.

[CJC]

Should items only increase a percentage of the base stats, or should we add the bonuses first, add the percentage modifiers second, and then calculate?
..and I guess "buffs" should treat the "base" value as all equipped values + base value.

Yeah, I figured equipment with flat bonuses would be added to the base, and then multipliers would be applied.

OR, I can add overloaded methods to the script "actors", use the above calculations by default, and you can change the default behavior by editing the base character script.

..complications make it fun.

I think this would be the safest way to code it with the highest degree of customization. Questmakers (Or whatever we're going to call them for FFC) can stick with the default for an FF style game, or experiment with the core 'actor' script to make a more complicated bonus system.

[Gleeok]

OK, check it.

So far items, characters, and monsters are stored kinda like this:

    <Monster name="Goblin" description="" script="Goblin">
        <Attributes>8,6,6,1,1,80,0,0,4,4,2,6,4,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Attributes>
        <Elements>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Elements>
        <Status>0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0</Status>
        <Flags attrib="0" elements="0" status="0" family="0" class="0" misc="0"/>
        <ItemDropSet count="0" multiple="false"/>
    </Monster>

Obviously items and players don't have a drop set, and will need some spell/skill data also (not started on that yet). Other than those, am I missing anything? ...requests?

[Flash Man]

It might make more sense to store the information using more XML elements, instead of implying a particular order with a comma delimited list. It will increase the size of the document, however it will make the format extensible by allowing more complex storage as necessary for future development.

    <Monster name="Goblin" description="" script="Goblin">
        <Attributes>
            <Attribute type="hp">8</Attribute>
            <Attribute type="mp">6</Attribute>
            <Attribute type="attack">1</Attribute>
            <!-- More attributes. -->
        </Attributes>
        <Elements>
            <Element type="fire">0</Element>
            <!-- More elements. -->
        </Elements>

        <!-- ... -->
    </Monster>

[Gleeok]

What I don't like about that is that it makes each element over 100 lines long. Multiply that by 128 and we've already got about 13,000 lines instead of a few hundred... This way should allow 3rd party interaction with the files much easier, plus it's a breeze to parse right now now.

There should be a key available which would give the string at any id though for sure, you are right about that. Something like:

<AttribStr>
  <Index id = "0" name = "HP"/>
  <Index id = "1" name = "EXP"/>
</AttribStr>

Also, last question (I think)

Spells/ Skills / Monster Skills :
-Should these use the same stats/atrributes as items, and should these be condensed into one list?

..If you make a blue mage class I guess it would be dumb to have 2 "white wind" spells. :\ Does anyone know how, say, FFIV or VI do these internally?

[Glenn the Great]

Spells/ Skills / Monster Skills :
-Should these use the same stats/atrributes as items, and should these be condensed into one list?

..If you make a blue mage class I guess it would be dumb to have 2 "white wind" spells. :\ Does anyone know how, say, FFIV or VI do these internally?

I think what the classic Final Fantasy games have is one big list of "battle effects".
This list comprises every possible action that can happen in battle, regardless of whether it is a magic spell from any school, a monster ability that players may or may not have access to, a skill, or an item.
In this manner, the code that executes these effects can be generalized.

The different schools of magic/skills/etc. are just another system that you navigate through for a battle effect to be chosen and handed off to the system that applies them.
If an effect should behave differently when used by mobs vs. by players, you define the effect twice with the same spell name but different ID numbers.

[Flash Man]

What I don't like about that is that it makes each element over 100 lines long. Multiply that by 128 and we've already got about 13,000 lines instead of a few hundred... This way should allow 3rd party interaction with the files much easier, plus it's a breeze to parse right now now.

I think that we would want to direct people to using the editor provided with the package. In addition providing a richer schema would enable those who wish to tinker with the content to better understand the format; XML is verbose. If size is the concern, then the content can always be reduced using a form of compression.

I think what the classic Final Fantasy games have is one big list of "battle effects".

That is exactly how I envisioned it; they are just repetitive effects that have slightly different calculations, visual displays and sound effects.

[Imzogelmo]

..If you make a blue mage class I guess it would be dumb to have 2 "white wind" spells. :\ Does anyone know how, say, FFIV or VI do these internally?

Yes, I have complete and exacting info for how FFVI's data is arranged. What do you need to know exactly?
All spells in the game are one table (including sub-ranges for regular magic spells, esper summons, blue magic, and enemy-only spells).

This is distinct from the list of items (a couple of items are implemented with spells, i.e. they have a unique spell that is fired off when the item is used, but that is really an exception and not the rule).

[Gleeok]

Yes, I have complete and exacting info for how FFVI's data is arranged. What do you need to know exactly?
All spells in the game are one table (including sub-ranges for regular magic spells, esper summons, blue magic, and enemy-only spells).

This is distinct from the list of items (a couple of items are implemented with spells, i.e. they have a unique spell that is fired off when the item is used, but that is really an exception and not the rule).

Great! Thanks!

Do you know if items contain the same number of bytes regardless of type? (like potion : armor)