Scripting API/Reference/Design thread

[Moosh]

This is all greek to me, sadly. Working on the assumption that this will work fairly similar to ZScript, could we maybe have copy/paste functionality in the built in script editor? The one thing that bugs me the most about ZScript is probably the reliance on importing scripts as .z files with a bare minimum script editor built in.

What will be the FFC equivalent of ffc scripts since there probably won't be ffcs in FFC? Will they be split into field and battle scripts and be assigned to specific maps and encounters? Could one attach a script to an inventory item or command similar to an item script in ZC. Am I being too closed minded here? Probably am.

Also kinda curious how scripting would work in a turn based battle system. Would there be some sort of waitturn() command to prevent stuff from happening between turns?

[Gleeok]

This is all greek to me, sadly. Working on the assumption that this will work fairly similar to ZScript, could we maybe have copy/paste functionality in the built in script editor? The one thing that bugs me the most about ZScript is probably the reliance on importing scripts as .z files with a bare minimum script editor built in.

What will be the FFC equivalent of ffc scripts since there probably won't be ffcs in FFC? Will they be split into field and battle scripts and be assigned to specific maps and encounters? Could one attach a script to an inventory item or command similar to an item script in ZC. Am I being too closed minded here? Probably am.

Also kinda curious how scripting would work in a turn based battle system. Would there be some sort of waitturn() command to prevent stuff from happening between turns?

I don't know how that would work since stuff like the battle engine is not done yet, so I can't give you any sort of good answer. There also is no editor yet. You can use any code or text editor available. This is mostly language, basic features for now. Sorry. ..

Also I can see why you are confused. Don't think of this as similar to ZC scripting. Think of it more like Game Maker (yuck) scripting (but faster and better times infinity... f**k you GM... cough.. shoot, ..I digressed...).

Why would you need things like item scripts at all anyway if you can create scripts dynamically? ...I suppose there would be at least three ways: events, objects, and through scripts, anyway. ..At the very least you could create any kind of script you wanted through another script. Example:

class MyObjectThatCreatesObjects
{
  void run() //runs every logical frame
  {
    // NOTE: you do NOT need while true here!
    wait(60); //wait one second
    game.create_object("MyObjectThatCreatesObjects"); //create a never ending object creating object!!! :P
   
    //note; after so many objects are created the engine throw an exception and close your game so this is a bad idea.
  }
};

Events and Map objects have not been designed yet, however.

The battle engine will probably be real-time with a bool for turn-based. :) The BattleActor class (or whatever) might just implement the ATB system. (since it is arguably 99% real-time anyway.) I don't know for sure though since it doesn't exist.

[Flash Man]

... could we maybe have copy/paste functionality in the built in script editor?

This will be a native feature of the editor, because it will be a (standard) Windows* Application. If things have not changed very much, then the zquest editor is an Allegro Application.

*As currently scheduled.

[Imzogelmo]

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

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

[Imzogelmo]

At the risk of a pun, I think we're on the same page as far as menus. It has to be flexible enough to handle dynamic and static text, intuitive as far as a tree of selections goes, and quick to produce from an end-user.

[Gleeok]

At the risk of a pun, I think we're on the same page as far as menus. It has to be flexible enough to handle dynamic and static text, intuitive as far as a tree of selections goes, and quick to produce from an end-user.

I think you mean U and I are on the same page. ...I mean, ..yeah. Not looking forward to it, but I think I have some good concepts that are easy enough to add. I'd like to get a battle loop first, but definately been thinking about it.

Forgot to mention but RPGLib is set up as a weird moduled unity build thing. That way no matter how many more files I add to it, it won't break and there's no need for makefile bs. It just compiles 3 .cpp files that include all the other files. I *could* set up the other project that way if it becomes an issue.