Attributes, Stats, & Modifiers, oh my!

[bobby_light]

A lot of people are dumping XML in favor of JSON. If you guys do decide to use XML, you might want to stop and consider it.
It might be a little less human readable (especially if you're not used to seeing it), but it's just as flexible if not more so than XML, while using less characters to express the same data. Supposedly there is no conceivable data structure that can't be expressed in JSON.

JSON (or possibly even YAML) is definitely a better way to go than XML. XML is ridiculously verbose; JSON is actually easier to read thanks to the removal of all the clutter the opening/closing tags bring with XML. You should go with what's most human-readable. Sure, XML would get you standardized validation, but if you're going to do things like smash tons of int values into a single text node like your example, you're losing a fair amount of that.

File size is pretty irrelevant; JSON/YAML has the benefit of being smaller, but no matter what the format it's going to be ultimately compressed anyway, and any text format is going to compress more than well enough.

[Gleeok]

Alright. I think I've the gist of everything properly sorted out. There's a lot of strange special cases, many of which can just be put into misc values though, like an item that can cast a spell or cast another spell when attacking and adds a status (debuff) effect that casts a random spell every turn (all of which should be possible with the engine - with a script)... weird.

..Anyway. Two design dilemmas:

1) equippable-by and jobs flags. If 32 character classes/etc is not enough these need to be changed to a dynamic bitset. (FFV I think only had like 22 jobs so 32 seems like it should be fine.)
1B) status effect flags. Same as above. (also same as below)

2) Elemental attributes: Similar issue,; have a fixed amount (32 total - though 20 is probably more reasonable) or a pay for what you use policy by making them dynamically sized. (see below)
2B) Elemental attribute logic: FF just uses bits for weak--strong--absorb. If we use this structure then elements only need to be three bitflags which represent elemental attribute data, and actual values need to be removed. Similarly, if actual values are kept for these then the aforementioned structure should not be used in favor of values over flags.

3) Status attributes: (Same as Elemental)

Side note: Yay encapsulation for being able to easily change stuff.

[Imzogelmo]

(all 3) - I like the dynamic sizes, for reasons I think I've explained already. But basically, I can imagine wanting to exceed some of those limits. Perhaps force bitwise flags if using more than 32 in a given chunk? I could live with that tradeoff. Or perhaps a mix of some bytes and some bits, up to a maximum size (which can be done via script anyway, not a problem). See my reasons below...

regarding elementals specifically: I used to always wonder why FF6 had separate bytes for each of the 4 elemental persuasions that it supports (in order of evaluation, they go absorb, nullify, 1/2 damage, weak, normal). I thought to myself, why not just have it store a multiplier per elemental (-2, 0, 1, 4, 2 in terms of halves)? But then I finally realized the answer: FF6 has the Debilitator, which has the effect of setting a random weakness to its target. If the target is already weak to everything, it misses. Otherwise, it will always pick an element at random, make the target weak to it, and clear any absorb, resist, or nullify that it may have. So, there is some monster which has all weaknesses already--but it also has all absorbs. Since the "weak to everything" check occurs first, this makes the monster invulnerable to Debilitator's effect.

Am I saying it can't be done with byte-per-element multipliers? Absolutely not. It would take more logic, but it certainly can be done. I'm just saying that sometimes there is a reason to do a bitwise elemental scheme. Also, if each element gets a multiplier, the multiiplier either needs to be a float, or expressed in some integral number of a fraction (like eighths). And it would also have to be signed (to account for absorb; i.e. negative damage).

---
A similar argument could be made for statuses, but I can see the flexibility that would be brought by having bytes to express a continuum rather than on/off. You could have Haste and Really Really Hasted with bytes. :) But I can't imagine Toad and Kinda Sort Toad. Some things lend themselves to binary quite well.
------------
EDIT: Another pair of design dilemmas:
1. The order of priority for elemental 'persuasions' (to use my word) is not always the same across games. If a game has a bitwise elemental scheme as above, then there is a priority (I mentioned FF6's system whereby Absorb is first and Weakness is last as an example). If there's a byte-scale to it, then it's conceivable to just add up the multipliers and get an aggregate (if that is desired), but typically the first 'match' wins in FF games so that would be a major change from norm.
2. Multi-elemental attacks: Again, noting the 'first match wins' standard, if a theoretical attack were to be flagged with fire and ice, and it hits a target with fire absorb and ice weakness, what should happen? In FF6, the full spell power would be absorbed by the target, as absorb has priority. It's conceivable to have it grant (2+(-4))/2 = 1/2 spell damage to the target by using multiples of 0.5 for each element involved. How do we handle multi-elementals, that is the question.

[Gleeok]

Alright then. Gonna just go with how FF would of done them if the old SNES carts had more room : http://www.gamefaqs.com/ps/197343-fi...iii/faqs/58936
Weakness: < 0%
Resist: > 0%
Absorb: > 100%
Status Imunity: 0 - 100%
That should be able to reproduce any other system without much trouble. It's also conceivable to rewrite the damage formulas and use something other than percentages too I guess...

2. Multi-elemental attacks: Again, noting the 'first match wins' standard, if a theoretical attack were to be flagged with fire and ice, and it hits a target with fire absorb and ice weakness, what should happen? In FF6, the full spell power would be absorbed by the target, as absorb has priority. It's conceivable to have it grant (2+(-4))/2 = 1/2 spell damage to the target by using multiples of 0.5 for each element involved. How do we handle multi-elementals, that is the question.

Yeah that's a good one. .. I don't know. I guess everyone would do it differently, but I might do something like this
-Calculate damage
-for each % of element split the damage into that many parts and modify them based on target defense for that type.
-add them back together again.
..


Also what do you mean all three? ..All of them?

[Imzogelmo]

Also what do you mean all three? ..All of them?

I mean that the statement in that paragraph applies to all 3 of your bullet points:

(all 3) - I like the dynamic sizes, for reasons I think I've explained already. But basically, I can imagine wanting to exceed some of those limits. Perhaps force bitwise flags if using more than 32 in a given chunk? I could live with that tradeoff. Or perhaps a mix of some bytes and some bits, up to a maximum size (which can be done via script anyway, not a problem). See my reasons below...

(apply this to all 3: equippable-by and jobs flags, Elemental attributes, Status attributes)

The rest up to the ---- before the Edit was exposition.

The Edit is a separate pair of issues I was raising.