Learning.

[Gleeok]

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):

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!

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)

[CJC]

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.
<_<

[Gleeok]

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.

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?

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.

[CJC]

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.

[Imzogelmo]

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?

[Gleeok]

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..

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.

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.

[Imzogelmo]

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).