Imzogelmo's Propsal for FF1 item data template

I. Item
A. Attributes (32 * 4 bytes)
1. Type (weapon, armor, shield, headgear, accessory, consumable)
2. SpellToCast (if used as an item, non-consumables), Effect (consumables only)
3. Power (weapon battle power, armor defensive power, consumable effectivity)
4.
5. Price
6.
7. SuccessRate (weapon hit rate, armor evade rate, consumable success)
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
B. Elemental (32 * 2 bytes)
1. ElementalAttack (weapons/consumables only)
2. (reserved for expansion of above)
3. ElementalResistance (non-weapons only)
4. (reserved for expansion of above)
5. ElementalWeakness (non-weapons only)
6. (reserved for expansion of above)
7. ElementalNullify (non-weapons only)
8. (reserved for expansion of above)
9. ElementalAbsorb (non-weapons only)
10. (reserved for expansion of above)
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
C. Status (32 * 2 bytes)
1. BlockedStatus (armors, shields, headgear, accessories only)
2. (reserved for expansion of above)
3. (reserved for expansion of above)
4. (reserved for expansion of above)
5. (reserved for expansion of above)
6. (reserved for expansion of above)
7. SetStatus (armors, shields, headgear, accessories only)
8. (reserved for expansion of above)
9. (reserved for expansion of above)
10. (reserved for expansion of above)
11. (reserved for expansion of above)
12. (reserved for expansion of above)
13. RemovedStatus (consumables only)
14. (reserved for expansion of above)
15. (reserved for expansion of above)
16. (reserved for expansion of above)
17. (reserved for expansion of above)
18. (reserved for expansion of above)
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
D. Miscellaneous (32 * 2 bytes)
1. EquippableClasses
2. (reserved for expansion of above)
3. (reserved for expansion of above)
4. (reserved for expansion of above)
5. (reserved for expansion of above)
6. (reserved for expansion of above)
7. (reserved for expansion of above)
8. (reserved for expansion of above)
9. HurtCategoryBonus (weapons only)
10. (reserved for expansion of above)
11. (reserved for expansion of above)
12. (reserved for expansion of above)
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

I recently (yesterday) renamed attributes.attributes to attributes.stats, and was thinking to extrapolate bonus-malus data from "type-specific" data. How do you feel about some additional disambiguation within the "Attributes" structure to better allow different kinds of uses of the data? -The overall goal of doing this would be faster speed, ease of use, and less code at the cost of about 100 or so bytes per 'chunk'.

For example:

[Attribute Interface Data (by any object that has attributes)]
-name
-script
-description
-misc flags and data
-[Attributes]
--[stats]
--[element]
--[status]
--[misc] <--Not applied in buff or equipment calculations.
--[data] <--lots of extra type specific data can be put in here
-[/]
-[Attribute Flags]
--lots of bits (maybe 256 -- class, family, ...)
[/]
[/]

By all means...

My goal in making these threads is to get an idea of how many bytes a "robust" data structure for items, spells, characters, and monsters would subsume. Certainly it will need to be ordered and also given a logical hierarchy.
FF1 has base stats and derived stats which are treated differently. Perhaps it would be good to subdivide stats even further?

What do you mean by derived stats?

Have you seen this?

http://www.ffcompendium.com/h/faqs/ff1bsiron.txt

Base stats: Strength, Intelligence, Luck, Agility, Vitality. These are cumulative, have a starting value and increase (sometimes) on level ups.
Derived stats: Damage, Hit%, Absorb, Evade%. These are derived from plugging the base stats into a formula.

MaxHP is, roughly speaking, treated as a derived stat too. It is cumulative, but the amount to add is derived from a formula tied to Vitality.

This is how the HP curves are seemingly different--they really aren't, but they are tied to an ever-changing base stat which varies itself based on the class.

Oh, right. 'derived'. :P I wasn't sure what you meant.

Quote:

---

D = [S/2] for Fi/Kn/Wm/Wz/Th/Ni/Rm/Rz
= [(S+1)/2] for Bm/Bz/(armed Bb/Ma)*
= LV x 2 for unarmed Bb/Ma

*BUG: Immedately after a level up, D for an armed Bb/Ma is instead [S/2]+1.
this is an actual effect and does not correct itself until you visit
the weapons subscreen. It even persists if you save and reload the
game

H% = (initial value at LV 1) + (3 x (LV-1)) for Fi/Kn/Bb/Ma
= (initial value at LV 1) + (2 x (LV-1)) for Th/Ni/Rm/Rz
= (initial value at LV 1) + (LV - 1) for Wm/Wz/Bm/Bz


A = 0 for all classes, except...
= LV for a bare Bb/Ma*

*BUG: Immediately after a level up, A for an armored Bb/Ma is instead equal
to LV, regardless of whatever armor is being worn. This is an actual
effect and does not correct itself until you visit the armor
subscreen. It even persists if you save and reload the game. This
bug does not affect special abilities granted by the armor you have
on, such as resistances to certain elements

E% = G + 48% for all classes

---

So basically characters in ff1 have 0 (except 48 evade) in these (all) stats the whole game, which are only increased temporarily by equipment and buffs. Wouldn't we just handle it in the exact same way then?

...for instance the get methods for evade could be:

Code:

---

int get_base_evade() {
  return stats[EVADE] + agility; //stats.evade could always be 48 here.
}

int get_evade() {
  int mod1 = equipment.modifiers.stat[EVADE];
  int mod2 = buffs.modifiers.stat[EVADE];
  int e =  base_evade + mod1 + mod2;
  return e;
}

---

(side thought) ..dereferencing things can get more verbose than I had thought.

Well, D is "damage" which is the base for attacks. It's not 0, it's Str/2 for all but Bb/Ma; and for the Bb/Ma it depends on if he's armed or not.
H% (hit percent) actually has an initial value whcih depends on class, and each class uses one of 3 formulas (the only thing the formulas need are the level though)
A "absorb" is 0 unless talking about an unarmed Bb/Ma; in which case it is his level.
E% is just agility plus 48.

Of course all of this is before equipment is applied.


That reminds me... level up data. We'll need some type of standard 'chunk' of data for that as well. We'll need an array of these chunks for each class (although they could use the same one, if desired), one entry per level.

True, but when you write the calculations for, say Atk, you should include stats[ATTACK] in there as well. Even though this would (by default) return 0 in FF1 since the character can only increase this by equipment and buffs, it's still implied that the ATK stat can be used if you want. ..I think, anyway. :tongue2:

Yeah, LV up data would be nice too. :P

I'm agreeing with you, but A is not attack it's "absorb" which is defense.

Yeah, confusing... Attack/Defense <=> Damage/Absorb.

From now on no more single-character abbreviations!. :P

I didn't write the guide, but in the guy's defense, it was written back when the NES was the only version and the in-game descriptions were used, so it's not too big a gripe when you read his key.
That being said, we should definitely not adopt his one-character abbreviation policy, it's very confusing. :)