Imzogelmo's Propsal for FF1 character data template

III. Character
A. Attributes (32 * 4 bytes)
1. Class
2.
3. CurrentHP
4. MaxHP
5.
6.
7. Strength
8. Vitality
9. Agility
10. Luck
11. Intelligence
12. NumberOfHits
13. Attack
14. Hit
15. Defense
16. Evade
17. MagicAttack
18. MagicDefense
19. MagicBlock
20. HitPercentUp
21. Unknown
22. Critical
23. LeftHand
24. RightHand
25. Head
26. Body
27. Accessory1
28. Accessory2
29. Level
30.
31. Experience
32. SpriteSet
B. Elemental (32 * 2 bytes)
1. ElementalAttack (from weapon)
2. (reserved for expansion of above)
3. ElementalResistance(from non-weapons only)
4. (reserved for expansion of above)
5. ElementalWeakness (from non-weapons only)
6. (reserved for expansion of above)
7. ElementalNullify (from non-weapons only)
8. (reserved for expansion of above)
9. ElementalAbsorb (from 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
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. CurrentStatus
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.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25. PermanentStatus
26. (reserved for expansion of above)
27. (reserved for expansion of above)
28. (reserved for expansion of above)
29. (reserved for expansion of above)
30. (reserved for expansion of above)
31.
32.
D. Miscellaneous (32 * 2 bytes)
1. ClassFlags
0x0001 Cannot use magic
0x0002 Hold magic points until upgrade
0x0004 Upgrade has occurred
2.
3.
4.
5.
6.
7.
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.
E. SpellBook (64 bytes) (Note the added block of data here)
1. Level1Spells (3 * 2 bytes)
2. Level2Spells (3 * 2 bytes)
3. Level3Spells (3 * 2 bytes)
4. Level4Spells (3 * 2 bytes)
5. Level5Spells (3 * 2 bytes)
6. Level6Spells (3 * 2 bytes)
7. Level7Spells (3 * 2 bytes)
8. Level8Spells (3 * 2 bytes)
9. Level1Charges (2 bytes)
10. Level2Charges (2 bytes)
11. Level3Charges (2 bytes)
12. Level4Charges (2 bytes)
13. Level5Charges (2 bytes)
14. Level6Charges (2 bytes)
15. Level7Charges (2 bytes)
16. Level8Charges (2 bytes)

You'll note I added a block "E" to this template. After looking over it, I'm thinking it needs to be still larger. While it is only 64 bytes (same as every other block), i think we probably want to have more than 24 spells per character (enough for FF1 but not FF6 for instance). Since I'm assuming a 2-byte index for spells (seems reasonable) and some games have a lot of spells-per-person, that block may need to be even larger, like say 256 bytes, so that each person could in theory have 128 spells.

On the other hand, it could be stored in a separate data table, if the option to add whole new data tables were to exist. I'm not sure how/if that would be done though.

Just my 2 cents.

EDIT: This is not to say it's not plenty of space for FF1; just that it doesn't leave much wiggle room for future designs, which is why I suggest it be increased even if just for character data.

I just thought of a math problem for someone to try and solve:

a 32-bit signed integer can hold up to 10 places. - (+ or -) 2147483647 -
What would the formula be for reading or writing a digit in a multiple of 10 from said number. :eek-new:

// num is the number in question
// place is the name for the digit you want, 1, 10, 100, etc. A well-formed place will be an integral power of 10, but let's not count on that

int get_digit (int num, int place)
{
if (place < 0)
// choke and die with nasty error
else if ( place < 10) return num% 10;
else return get_digit((int) num / 10, (int) place / 10);
}

// if you can guarantee that the number requested is 'well-formed'...

int get_digit(int num, int place)
{
return ((int) num / place) % 10;
}

// maybe you're expecting places named 0, 1, 2,... instead of 1, 10, 100...
int get_digit(int num, int place)
{
return ((int) num / pow(10, place)) % 10;
}

Quote:

---

Originally Posted by Imzogelmo

int get_digit(int num, int place)
{
return ((int) num / pow(10, place)) % 10;
}

---

Ahh. That's what I had! :weirdo: ..I could probably do one with exp10, log or something.. but I think this version is the best.

Anyhoo, what I was hinting to was; why not just treat MP like most rpg's do: Just a MaxMP and MP variable (with some maths for FF1). (That way I don't have to hack anything fancy in also.lol) :lazy:

Well, the original FF1 had no MP; it just had spell 'charges' based on level. You could never cast more than 9 of a certain spell level before you had to sleep in an inn, house, or cabin. Later versions of FF1 kept the spell level attribute (for restricting use until a certain level) but switched over to MP for the actual spells cost. I think part of the original's challenge was beating stuff without spamming high level spells, especially on a long dungeon. With the MP system, you have no reason to use out-dated spells once you get the higher ones. (Why use Fire when Fire3 will do?)

Nevertheless, I left attribute/stat 5 and 6 open just for such anticipation. :)

Is it possible using fancy math to make the MP curve compatible with that idea? I submit that it is not. While you can make the higher level magic cost enough that you wouldn't have the MP to cast it more times than your level would permit, making it cost that much would make you able to cast a ton of lower-level spells. I'm not against it in principle, if the game calls for it, but to simulate FF1's system you have to limit spells of all levels, and an MP system has no way of enforcing how you spend the MPs.

That being said, you could have an MP stat that isn't really MP. Since you asked this question right after the get_digits question, I'm thinking perhaps you were suggesting that each "place" be used as charges. If that's what you mean, then yep, that would work perfectly fine for simulating FF1's system except for one issue--the final place needs to be able to go up to 9, not 2 (or 4). However, why do mod 10? We're not going to show it to the player, so use a full 4 bits per level. This will work out perfectly, and let you go to 15 charges per level if desired. To elaborate:

int get_hex_digit(int currentMP, int spellLevel)
{
return ((int) currentMP / pow(16, (spellLevel -1))) % 16;
}

Since you have 32 bits, each 4 bits represents a spell level, and this will return the hex digit representing the number of charges.

Yeah, after breaking it down, I think this works a lot better than my structure of charges. We still need a list of spells per player though.

Yeah, the GBA version gives you waaaay too much MP and LVs to make you use anything but the most powerful spells. That version is the easy type by default with no difficulty option. :\

However I am a fan of the newer MP system. I was playing through the Mod_of_Balance hack and it is VERY close to the original. Obviously some things I don't like so much but others were done very well. My Black mage uses the most powerful spells only once or twice per Inn visit, and still casts fire/ice/sleep at LV 14 often. He did a pretty good job with that I have to say.

..Ah right, spells. ..ooh a piece of candy. Ooh a piece of ca...

[edit] Actually wait a minute. There's no data for it in the ROM, which means it is done using some math. ...and that is confusing.

There's data for MP in the GBA ROM-- it uses MP after all. The NES won't have it, it has the klunky 'charges' system, which I think is probably very very close to what I've proposed above (essentially using 4 bits per spell level).

OK. So we'll just stick charges in the misc[] data in the (not yet existant) LevelUp struct.

We still don't have to use level charges though. I'm fine either way. The first thing people will probably want to do is ask how to use spells like in FF4 or 6. :P

I can make some templates for FF4 or FF6 if that's needed. As long as there's enough room to handle the data, scripts can be made to utilize them.