Attributes, Stats, & Modifiers, oh my!

[Gleeok]

Yep. What the title says.

Here is my crappy editor work-up from a little while ago: (It won't look this crappy later though)
http://i235.photobucket.com/albums/e...mat_AD/me1.jpg
http://i235.photobucket.com/albums/e...mat_AD/me2.jpg

Here's how I had/have it:
-The editor will allow you to rename any or all names of attributes/status_conditions, etc. to anything you want.
-There is support for 32 integers (stats), 64 16-bit integers (status/elements) and a shit ton of true false values.
-Attributes are basically stored as arrays with no knowledge of what it stores, just that it can represent a percentage or be added or multiplied together with other attributes. In this way it has no concept of things like "HP" or "Agility" at all. Consider this:

We have equipped 2 swords, 3 armors, and 12 accessories (hey, why not right?).
Suppose armor A increases all elements by 20 percent and lowers speed, B increases only HP and defense, and C increases all sorts of weird things but adds the status flag assigned to "Poison". (Forgetting about accessories for now.)
We'd like to just say that the players stats are [ base + a + b + c ] (armor only here)
There are a few quirks:
-Suppose that multiple items that modify by percentage are equipped. What is the order of operations? Do they stack like in Valkyrie Profile 2? ie; multiply, then multiply again. ..or are they non cumulative?
This also applies to buffs too I guess.

Back to more on what does the engine "needs to know": What is HP anyway? Is it edible? Can I @#$% it?
Suppose the battle engine sees that enemy 4 has -12 HP and decides to remove it. Suppose you gave it "Zombie" status, or cast Life 3 on it or something and now it's gone so you have to write a script to workaround the fact that it was removed in the first place. Why not just have the Battle Engine controlling script say "engine.remove_enemy(e)". This also allows scripts to customize death animation/effects, bring it back to like, or whatever. So we could say knowing about stats and effects are a bad idea to things that have no business knowing about them. If we just follow good c++ object oriented paradigms it will allow the most flexibility.


So... Attributes and modifiers are pretty important to get right at the get go since they cannot be changed easily. (This means you have to demand stuff be put before it gets to the shipping station)


[edit] Just to be clear; is this a reasonable way to do this, enough room for custom use? Should item and spell data use a different structure than characters and monsters?
Thoughts?

[ctrl-alt-delete]

Just one.

Oh my sweet Jesus Christ this looks awesome, why have you been keeping it from us??

[CJC]

Percentage boost items should add their percentages together and then apply it to the current total. In that way, they don't balloon with exploitation stacking and they also are less detrimental when positive and negative percentages are equipped simultaneously.

IE: If item A and item B give a Defense boost of 2 and 5 respectively, and item C and D give a Defense boost of 12% and 7% respectively, then the attribute would become "(Defense + 2 + 5)*(1+[12+7]/100)"



So enemies and 'actors' (the characters the player controls) will be tracked in the same manner? Does that mean they share the same limit (So say, 512 slots would make room for 12 actors and 500 enemies)? I was going to use 'backup' character slots to handle a few complicated status ailments I have in mind (like Toad), and one of my biggest concerns was wasting all the player character slots with that sort of thing. But if I can just prune some enemies to make room, then it's not a problem.



Also, I agree with Kolt. This is made of awesome.

[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.