Scripting API/Reference/Design thread

[Gleeok]

I'm working on the battle engine right now so let's see if we can add a bit of the combat and battle related API to this. (Though there's too much to type everything out right now, here's a brief description.)

*Data*
-character_data
-character_class
-monster_data

(Each of the previous holds base data for attributes, sprite id's, names, script name, description, etc..)

*Game Instances*
-character (initialized from character_data. all characters are )
-party (contains arrays of active/inactive characters, shared inventory, etc.)
-monster (initialized from monster_data. normally temporary objects for battles)

*Combat Instances*
-combatant
-player_combatant (holds a reference to a character)
-enemy_combatant(holds a reference to a monster)


Attributes are pretty much done and I'm in the process of "finalizing" other things as well. All attributes of any object above can be references by scripts by:

attributes.max_param[]
attributes.stat[]
attributes.status_atk[]
attributes.status_def
attributes.element_atk[]
attributes.element_def[]
attributes.misc[]

These can be kind of tricky at first though. For example

character.attributes.stat[STR] != character.base_attributes.stat[STR];

It's easy to type the wrong one.
The difference is character.attributes is read-only since it includes all the modified values from equipment, buffs, modifiers as well, and, accidentally setting base_attributes could be bad.


*Interesting Side-Effects from the design (Due mostly to c++ code-reuse patterns..and/or it was a few extra LOC. I wasn't even planning any of this, I swear!)*
-All monsters can equip items, and hold an inventory! Imagine a group of Goblins each equipped with long swords and leather gear!
-Easily possible to have "capsule monsters" or whatever. There you go.

And that's it for now. It's a WIP.

I was just reading through to see if I can get an idea of how much would be pre-built vs. needing to be made with a script. Naturally, my mind first considers the menuing system-- any kind of Final Fantasy game has a main menu and various sub-menus accessible from it-- but the exact layout and contents of the menu would vary based on the specific details of the game. For instance, Final Fantasy IV needs 5 characters to be visible; FF V needs a job menu; FF VI needs a skills menu, etc. My point being that while they are all very similar and can probably be built from the same basic parts, the specific form that you end up with would differ based on the need of the game.

Parallel to that, I think the map would be a fairly universal module across games as well. Maps need a width, height, tileset, and of course the data (including probably at least a couple of layers). Several general things populate the map perhaps as additional layers: NPCs, treasure chests, event triggers, warps, animated tiles, layer-priority shifts, diagonal stairways, etc. It seems me that if you get the map powerful and flexible, and then a menu-subsystem.. that's 2/3 of the work right there (the battle engine being the other 1/3, of course).

Right you are. My idea for menus is this:

A specialized, stripped down UI library designed only for console-styled jrpgs. (Obviously anything that can handle this can also handle any other kind of game, that doesn't involve a mouse that is, without too much trouble.) ...And that's it. O_o ...well things like auto-layout and auto-managed lists of various types is a huge win. I think this is the best option overall in terms of useability without tons of stupid windowing layout scripts, anyway.

If you have something better though then let me know, though I think component-based is by far the easiest and most flexible.