Imzogelmo's Propsal for FF1 spell data template

II. Spell
A. Attributes (32 * 4 bytes)
1. Sphere (White or black, can certainly define others)
2. Effect (none, affect attributes, affect status, affect elemental)
3. EffectParam1 (which attribute to affect; which status, which elemental)
4. EffectParam2 (how much to add/subtract for attribute)
5. Price
6. Targetting (one ally, all allies, caster only, one enemy, all enemies)
7. SuccessRate
8. SpellLevel
9. FieldEffect (script to run out of battle)
10. FieldParam1 (base)
11. FieldParam2 (range)
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31. BattleMessage
32. GraphicSet
B. Elemental (32 * 2 bytes)
1. ElementalAttack (weapons only)
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. SetStatus
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
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. ToggledStatus
20. (reserved for expansion of above)
21. (reserved for expansion of above)
22. (reserved for expansion of above)
23. (reserved for expansion of above)
24. (reserved for expansion of above)
25.
26.
27.
28.
29.
30.
31.
32.
D. Flags (32 * 2 bytes)
1. LearnableClasses
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 (damaging spells only)
10. (reserved for expansion of above)
11. (reserved for expansion of above)
12. (reserved for expansion of above)
13. AttributeEffectFlags
0x0001 Subtractive (Damage to attribute)
0x0002 Additive (Healing to attribute)
0x0004 Undead Only
0x0008 Ignore Defense
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.

Could we perhaps have a little more space for sphere, so that we can add spells of various other categories to a customized game?

IE: Blue, Red, Time, Summon, etc.

(I know that Red is technically just a class restriction on Black and White, but it might be nice to have it as a sphere so that Red Mages can learn spells unique to their class, like DoubleCast.

I have it taking a whole 2 bytes (which is really overkill, it could be a few bits). 65536 possibilities there...
It could be delegated to a series of bits, maybe 4, which would still leave 16 possibilities (which is about all I can imagine at the moment for sphere).

Actually, that brings up an interesting point. How easy/difficult would it be to have multiple accesses to the same data? A lot of times you need a field that is only 1 byte, so it would be handy if you could have the same field be 1, 2, or 4 bytes depending on how it was used. I'm talking, of course, of unions. Perhaps even making a basic type that is a union of 1 4-byte integer, 2 2-byte shorts, and 4 1-byte char entries. That could lead to problems in portability though, so I don't know.

Quote:

Originally Posted by Imzogelmo

It could be delegated to a series of bits, maybe 4, which would still leave 16 possibilities (which is about all I can imagine at the moment for sphere).

This is what I meant. It looked like a lot of the two bytes was empty space, and the one-bit assignment for sphere felt a little constraining. Even allowing just three bits would give a total of eight possible classifications for spell sphere, which would cover pretty much all the classic forms of Final Fantasy Magic. Adding the fourth would allow people to assign spheres to 'magic' abilities, such as a list of martial arts 'spells' that only one character uses.

Ah, but what I'm saying is that each line in the above template proposal is already 32 bits. Having 32 bits where 3 are needed is indeed overkill. I just listed 'white or black' as that's all FF1 needs (could assign 0x0000 to white, and 0x0001 to black). Certainly this can be expanded to have 0x0002 for red, 0x0003 for blue, 0x0004 for summon, 0x0005 for gray/effect, 0x0006 for ninja, 0x0007 for whatever...) It's basically a menu-restriction. Point being-- 32 bits is still way too many, as you really only need 3, 4, or maybe 5 at the outside. You're never going to see 65000 different "spheres" of magic. Of course, if that is the case, each spell pretty much is a sphere unto itself, which may in fact be desired in some scenario (probably the designer is using that 4-byte value for something else though).

Each game would be able to define these bytes as it wishes though, or that is my understanding at least. That's the reason for making it so large. My thinking is that all of these are big enough except character, which I think needs to be larger due to having a spell book (and I'm afraid it's still too small, I'll post more in that topic later).

The reason things like elements and status effects were 2 bytes each was for the possibility of percentages or actual values. I know that early FF only uses flags for these:
weak->none->nullify->absorb (1 byte for these would still be better than 4bits though)

I just figured one extra byte gives you the option of more modern things like:
[fire infuse - spell that buffs a character's fire element]
-fire atk : +25%
-water def : -25%

or something...
It is tricky though, because to perfectly emulate the early FF games flags are actually better I think.
It's also possible to make all the stats, etc.. dynamic or variable sized. (all types must share the same amount in the game though). This has only an overhead of 48 bytes (I think) (or 96 if compiled on x64bit). [edit]per-item overhead that is what I meant./

This is why I made the attributes stuff templated in the beginning - so it could be easily changed later on. I'm open to suggestions.

Quote:

Originally Posted by Imzogelmo

Ah, but what I'm saying is that each line in the above template proposal is already 32 bits.

OH!

I thought each line represented one bit, with the whole array coming to 2 bytes. I didn't realize you meant that each line was 2 bytes.

That's why I was concerned. The way I was interpreting your presentation, I thought there was only one gate for Magic Sphere, but there's actually 32. That's way more than enough.

Thank you for clarifying.

Just to further clarify, I should have said 16 bits, not 32. 2 bytes = 16 bits. Sorry about that. Still, way more bits than needed, but the template can be defined as the questmaker (what are we going to call it for FFC?) sees fit.