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>

[Flash Man]

I use and favor JSON in while working with Web technologies. Steam uses a very similar format called VDF. It can definitely represent all the data structures I think we will need.

For space saving we could even research the use of BSON.

[Gleeok]

Thanks guys; I'm still going through those. I can't believe they were able to fit so much data onto one SNES cart. Pretty amazing when you think about it...

Anyway, I've got the complete monster sprite atlas done. Loading and saving xml and resources finally works now (including sprites and animations). So I can finally load these in, expose them to the scripting engine, and draw them. Not quite at the point where we can get down to it with enemy stats vs. player stats in combat, but I think getting something like a in-game bestiary done would be a good morale victory for now. :)

[Gleeok]

Hehe...it's amazing how crazy these things get when you start picking apart every little thing. :googly:

Anyway, at the root of these I've come up with three things that can represent both simple or complex ideas, and would (should) be enough so simulate any jrpg ever made. These are:
*Buffs (essentially all equipment is like a buff. Easy for things like "all element resist +1" or "any/all stats +- some amounts")
*Modifiers (Limited to a single stat, eg; hp + 10%)
*Factors (not limited to anything, really, but require to be defined by scripts. Things like "enemy_atk_x5, exp x2" or "adds random status effect to attacks".)

At any rate we'll have to finish the battle algorithms and logic before adding anything else.