Learning.

What's up with this.. This is a mixed bag but most of the games have this in common. Not entirely sure what to do.

II has 'learning' attached to every battle command/stat and spell;
III and V have learning inherited through jobs for abilities which in turn unlock or allow use of commands, spells, et al.
VI allows you to equip a special type of item (or any item) which lets the user learn magic at a given rate. (In fact current progress is even viewable in the spell list screen.)

So, we need a system capable of implementing the aforementioned, but one that does not need to stick it's nose nose into every part of the code that it can be used by, and not so generic that it would be less error-prone to script something from scratch rather than use as a core feature.

Thoughts?

Saw the title and thought you meant Blue Magic. Kind of relieved that it's not, frankly, as that's a big bag of worms (to be dealt with later or possibly never :disgustnew: ).

Maybe each spell/ability has a 'percentage known' variable that ranges from 0-100. Actually... it should probably be attached to the character, right? ...Either way, it'd require an variable for each individual spell, or at least some kind of array to track buildup independently.

Anyway, this 'SpellKnown' variable could be modified by battle condition:

If (Esper == Maduin) && (BattleVictory){
CureKnown = Max[CureKnown + (AbilityPoints x 3), 100]
Cure2Known = Max[Cure2Known + AbiltyPoints, 100]
}
If (CureKnown == 100){
Disp "Learned Cure!"
}
If (Cure2Known == 100){
Disp "Learned Cure 2!"
}

by item or shop:
If (LearnCure){
CureKnown = 100
}

or even by game event:
If (FightingGolbez){
MeteoKnown = 100
}


If it's a variable that can be referenced in multiple places, then creators could do really cool things like make the spell available before it's learned completely (but at an elevated cost or decreased power based on the percentage known), teach Blue Spells instantly during battle given the correct conditions, or even teach spells from chests (FF1 and FF5 both do this).


I don't know how viable tracking them individually like that would work, but if I were attempting this sort of thing (which I wouldn't, because I can't code to save my life) I'd try to do it like that.

You've hit upon something that is very crucial to make a final fantasy type of game.

I know it doesn't just apply to spells, but I'm gonna just call it spells throughout this ran b/c it's easier (skills could be thought of as physical spells with no MP cost).


There are several ways that a spell can be learned in various games:
1. Purchased from a shop
2. Learned at level up
3. Unlocked by specific event sequences
4. Learned by equipping a certain item and fighting with it for a while
5. Taking on a certain character class
6. Use some consumable item
7. Learned after victorious battle if certain in-battle conditions are met

All of those could be considered as "teachable moments" <groan>

I don't think we can discuss this without further noting that spells/skills/etc. always "belong" to a certain super-set, which determines the command and menu that the are called from.
To use a FFVI example, Pummel belongs to the Blitz category. Quadra Slice belongs to the SwdTech category. Pummel can't appear in SwdTech's list--it just can't happen.

Sure, it's my favorite, but this is not limited to that game. Several games have separate Black and White lists. It's the same idea essentially.

Now, ideally, each character will have his/her own list(s) for known spells/skills. A list per command that leads to the spell. Some characters will have more than one list.
I also should point out that having the lists be (arbitrarily) large is one of the main improvements that can be made on the FF formula.

Usually you want each character to have their own lists. There are exceptions. Gogo's lists are merely the AND of all party-members lists: in the case of Magic, it's all members in the current party. In the case of Rage, Lore, Blitz, SwdTech, or Dance, it's actually the (that's "THE") list of the representative character for that command. Since that's the exception, not the rule, I think it would be best to make the engine give everyone some lists, and if you need to make a special case like Gogo, then a special script can be inserted to build it.

------------------

How to make it as non-invasive as possible:

The battle module is probably the easiest in this regard: Only the battle-spoils routine needs to worry about learning skills. Make all character-data in-battle be a copy of the original (and use those exclusively in the battle). If it needs to be modified after the fight, modify the original. The only question here is why you learned it (natural magic at level up? A monster used a blue spell? Your magicite finally accrued enough points?). All those are valid reasons, and all would be handled in the spoils-routine.

Out of battle, I think it boils down to the event handler:
Shops are merely a cookie-cutter event; it should be able to access event commands. Purchasing the spell = learning the spell.
Event based learning (Rydia at Mt. Hobbs) is an event too. If you can make somebody walk around, you can access character data. Event commands are really something we need to nail down.
Using an item... that's a kinda tricky one. I am a fan of items that have the ability to call an event. FFVI uses events to accomplish the warp stone, tent, cabin, rename card... and a few others I can't think of. So the capability needs to be there anyway.

-------------------

What we need is an event system with commands that can reach in and modify any character's attributes. I'm not gonna call it 'global' (as that's a bad word in programming) but it's gonna be pretty close to global to do what it needs to do.

Great ideas. Let's see if we can solve them in order of easiest to more obscure.

Blue mage: Probably a script function since it is a very specific thing; whenever a battle ability is used or a combatant is targeted it sends a notify event to that script class (this is always a good idea anyway):

Code:

---

void BlueMage.SomeNotifyEvent( object performer, battle_action action )
{
  if(performer.faction == ENEMY && action.type == SPELL && action.subtype == BLUE) //or something...
  {
    if( !spellbook[BLUE].contains( action.id )
    {
        //learn the spell
        spellbook[BLUE].add(id); //maybe needs a learn queue or similar...
    }
  }
}

---

No probrem! :P

Case 2: Anything bought or acquired or learned at LV UP doesn't need to be learned in the sense of having to grind out exp, AP, or have a current learning rate data attached to it, you just get whatever it is.

Case 3: Commands, Spells, Skills, (whatever else?) have a mini subset of a simple experience point system that can be tracked and modified. ...Still not entirely sure about this except that it should be able to work in some sort of tandem with these:
* Skills - Each character can have multiple skillsets.
* Spells - Each character can have multiple spellbooks.
* Abilities - can be learned by various means.
* Classes(Jobs) - need to be able to track lv, exp, other(?) by each character.
* All of the above can be 'learned' at some given rate by exp or AP.

I suppose everything above could be handled by a super simple learning container that stores a dynamic list of data that holds an id, type, rate, exp, and lv which is saved in the save file... This would be the generic solution which, strangely enough, would still work with every conceivable data type. Even items, monsters, chests, or maps could be learned! lol. Though the downside of this is an extra step of looking in here every time something is equipped or removed etc. and having to be managed by scripts, though it's likely that most people will not go crazy with this and just use it for one or two things at most, if that.

Other Ideas?


[edit] Also not touchings events yet. (I'm not ignoring you, just that this requires a lot of dedication and time to implement - which I'm putting off until we have some level of a playable game)

I don't feel like it's ignoring... but events in the sense I'm using them pretty much *is* the game.

Add character X to party Y? - that's an event (command)
Load map X? - that's and event too
Add X HP to character Y? - still an event...
Launch battle with troop X? - event
Walk X steps right, face down? -- quasi-event, subsystem movement
Set event bit 1234 (indicating you just killed Garland)? clearly that's an event too.



Will the actual event commands be something that can be built later, or is it, as I suspect, that we will have to make them good enough, and flexible enough, that they can handle whatever situation a game-creator should want or need to throw at them? (I picture the event engine as the glue that sticks the good stuff together).


Also, this...

Quote:

---

Case 3: Commands, Spells, Skills, (whatever else?) have a mini subset of a simple experience point system that can be tracked and modified. ...Still not entirely sure about this except that it should be able to work in some sort of tandem with these:
* Skills - Each character can have multiple skillsets.
* Spells - Each character can have multiple spellbooks.
* Abilities - can be learned by various means.
* Classes(Jobs) - need to be able to track lv, exp, other(?) by each character.
* All of the above can be 'learned' at some given rate by exp or AP.

---

I'm curious about how all of this can work generically. Maybe I'm not seeing the forest for the trees here.

Quote:

---

Originally Posted by Gleeok

Case 2: Anything bought or acquired or learned at LV UP doesn't need to be learned in the sense of having to grind out exp, AP, or have a current learning rate data attached to it, you just get whatever it is.

---

What if we want to have an accessory that teaches slowly, and a shop that lets you learn it instantly (at an insane price, mind you!) It might be better to build everything with the assumption that it requires AP (or an equivalent), and just let people override the slow learning with 'Jump to 100%' items/shops/equipment.

This is not at all related to my fiendish plan to make the spells the player purchases only have 20% power and effectiveness, thus forcing them to grind them up to full strength. Not at all.
<_<

Quote:

---

Originally Posted by Imzogelmo

I don't feel like it's ignoring... but events in the sense I'm using them pretty much *is* the game.

Add character X to party Y? - that's an event (command)
Load map X? - that's and event too
Add X HP to character Y? - still an event...
Launch battle with troop X? - event
Walk X steps right, face down? -- quasi-event, subsystem movement
Set event bit 1234 (indicating you just killed Garland)? clearly that's an event too.

Will the actual event commands be something that can be built later, or is it, as I suspect, that we will have to make them good enough, and flexible enough, that they can handle whatever situation a game-creator should want or need to throw at them? (I picture the event engine as the glue that sticks the good stuff together).

---

What I picture events as is a complex system where each event is a block of data that holds the info for what the event does and can hold conditions, child events, scripts, or whatever else, and an interpreter that can process events.
What I picture scripts as is something that can do anything an event system can do plus anything else you can think of without any editor tools or long development processes.
Playing a sfx, killing the player, or fading a screen to black I don't think of as events, but an event would be able to do any of those... Make sense? O_o

FF1 is great because it requires no events, just some game switches such as garland_dead?, orb3 aquired, chest 3 in Marsh Cave B1?, etc.. which would probably come in two flavors: map switches, and global switches. ..or states... though state implies that there can be more than 0 or 1.

Quote:

---

Originally Posted by Imzogelmo

I'm curious about how all of this can work generically. Maybe I'm not seeing the forest for the trees here.

---

I thought that's what you were talking about earlier?
----:
"I don't think we can discuss this without further noting that spells/skills/etc. always "belong" to a certain super-set, which determines the command and menu that the are called from.
To use a FFVI example, Pummel belongs to the Blitz category. Quadra Slice belongs to the SwdTech category. Pummel can't appear in SwdTech's list--it just can't happen.
Sure, it's my favorite, but this is not limited to that game. Several games have separate Black and White lists. It's the same idea essentially. "
:---
Or did I misunderstand?

Quote:

---

Originally Posted by CJC

What if we want to have an accessory that teaches slowly, and a shop that lets you learn it instantly (at an insane price, mind you!) It might be better to build everything with the assumption that it requires AP (or an equivalent), and just let people override the slow learning with 'Jump to 100%' items/shops/equipment.

This is not at all related to my fiendish plan to make the spells the player purchases only have 20% power and effectiveness, thus forcing them to grind them up to full strength. Not at all.
<_<

---

I had this idea too. Basically we treat spells/skills and such as western-rpg type games. For example, look at something like elder scrolls. Items are entities and can switch between being a map-item-entity, or an inventory-item-entity etc... they can have a location or be upgraded or whatever, but there is some kind of instance of them. So I can just do that without too much hassle I think. What it will do is allow something like FF6 learned spells, or spells that can lv up, or even spells that upgrade themselves or similar.

What else does it need?
SpellInstance{
spell_id
lv
exp
flags
} //this should be the bare minimum for all FF-type games.

Quote:

---

Originally Posted by Gleeok

What else does it need?
SpellInstance{
spell_id
lv
exp
flags
} //this should be the bare minimum for all FF-type games.

---

This should be able to handle pretty much all the different versions of learning that are encountered in the various FF games. The only one I can't see working out in a straightforward manner is the Materia setup, which is duplicitous by design. People intending to use that style of magic can simply script it themselves, though.

Quote:

---

Originally Posted by Gleeok

I thought that's what you were talking about earlier?
----:
"I don't think we can discuss this without further noting that spells/skills/etc. always "belong" to a certain super-set, which determines the command and menu that the are called from.
To use a FFVI example, Pummel belongs to the Blitz category. Quadra Slice belongs to the SwdTech category. Pummel can't appear in SwdTech's list--it just can't happen.
Sure, it's my favorite, but this is not limited to that game. Several games have separate Black and White lists. It's the same idea essentially. "
:---
Or did I misunderstand?

---

There I was illustrating the skill-belongs-to-skillset idea, yes. And within that, skills would often have a %-learned attribute to them, as you've noted.

But what I'm not quite understanding is how the skill sets, spell books, abilities, etc. get attached to a given character. How can multiple such sets be attached to one character? I know it's getting off into the weeds a bit, but I'm just trying to understand; when I look at a skill set's code, will it be within a character's scope, or will it be within its own scope? Surely the data for how to execute the attack would be within the actual skill's scope, but ownership of that skill would not-- Two character's both know Blizzard, but the data for how to do Blizzard doesn't belong to either of them.

I think I just answered my own question, actually. It would end up looking something like this:

Character{
...
SpellBook[Max_spells]
SkillSet[Max_skills]
}

When issuing a command, we need to know what abilities the character has, for menus at the top level but also for building any submenus.

for (int i = 0; i < Max_spells; i++)
{
if SpellBook[i].isKnown() MasterSpellList[SpellBook[i].GetID()].DisplayName();
}

Executing a spell is gonna need to know caster and target, for damage calculations, so at that point, both of those things are known:

FigureSpellDamage(Entity caster, Entity target, Spell spell)
{
return caster.GetPower()* spell.GetEffectivity() - target.GetMagDef()
)


I guess my only real question here is how to have characters with open-ended lists of ability sets?

Yeah. Abilities are on my todo list. I suppose my question with these is whether passive abilities and assignable abilities should belong to the same list, and, if battle commands are seperate. ..I guess "commands" represent equipped abilities.. :shrug:

Also did you mean #1 or #2 here:
Character{
list<SpellBook> spellbooks //spellbook for white/black, or all
Spellbook mySpells; //all spells in the game
}
I was thinking #1 where in the case of FF1 or 6 you just use only one book.

Quote:

---

Originally Posted by Imzogelmo

I guess my only real question here is how to have characters with open-ended lists of ability sets?

---

What do you mean by open-ended lists? ..I must be thinking of something completely different.

I was just making some pseudocode there; I meant #1 for SpellBook, and #2 for MasterSpellBook, though.
But when I say "open-ended lists of ability sets", I'm referring to the possibility of having more than one list. Think of young Rydia in FF4; she had a white, a black, and a summon list. If characters only have one list, that wouldn't be possible; if they all have 3, that's just too much. Clearly, it has to be open-ended, i.e. dynamic. And the question is how to design it to be dyanamic (so that it can handle 0, 1, 3, etc. separate lists of abilities).

And that was before I thought of the possibility of an ability that belongs to more than one list--but I think it would be best to have them always belong to exactly one list (and you can make a duplicate in another list if you just had to).

Oh that's an easy one.

list<Spellbook> spellbooks;
where spellbook contains a list of spells (and by list I mean vector). It's also possible the first one might be a map... depends on how they are accessed. Haven't gone into any detail with those yet.

[edit] actually how it is written since you could have spellbooks that are empty and thus require no memory for.

So, the idea of each character having their own "spell book(s)" is a good one that seems easy enough to work out.
The skill sets--would they be inherited from the class, or specific to the character?

Quote:

---

Originally Posted by Imzogelmo

So, the idea of each character having their own "spell book(s)" is a good one that seems easy enough to work out.
The skill sets--would they be inherited from the class, or specific to the character?

---

Err... not sure. :P I am officially in the 'grey area' with most of the stuff that isn't used in FF1, or otherwise obvious in some way, so that stuff is put on the backburner for the time being. I would think that a character has the final say as to what they learn regardless of class (eg; they can learn a skill before the class can learn it) but I haven't thought about it much. I think characters also need a 'Learning' for classes too though. You're welcome to suggest something though.

For the most part they would be one and the same, but I think it has to be more of a virtual inheritance if anything. That is, it has to be up to the character to implement, because:
1. There may be 2 characters of the same class. They shouldn't share a skillset (usually).
2. The character may change classes. While you may have it belong to a certain class, they should still be accessible if you change back.

Ah, that gives me an idea. Skillsets that follow the character; accessibility that follows the class (and again, they are the same in games with characters that have one unchanging class and no 2 characters with the same class... which would be by definition, of course).