Plan for implementing battlescripting

From OHRRPGCE-Wiki

Battlescripting is a feature that users have been asking for ever since the introduction of Plotscripting

This article or section is not complete. If you wish, you may finish it, and remove this tag when you are done.

• Clean up script code sufficiently to make scripts executable in battle through the same interpreter:
  • Move all of the interpreter's code into functions
    • To SUBify sfunctions, we need to handle the GOSUBs it indirectly calls in game.bas: nextsay, opendoor, preparemap, thrudoor as well as dozens of module-local variables
      • Unless there's some dirty low-level workaround?
      • ...or battle mode could have its own separate equivalent to interpretloop, and sfunctions could be broken apart into separate sections for out-of-battle, in-battle and global
      • Organise textbox state into a UDT
    • The bits of the interpret GOSUB that will be in common with battlescripting should be subified, the rest can remain a GOSUB
      • bmod.bas would have its own set of want* flags (hopefully a null set: instantaneous effects are much nicer)
  • Implement script multitasking to isolate battlescripts from plotscripts
  • Organize script command implementations into plot-only, battle-only, and universal
• Clean up battle code sufficiently that we can create sane scripting interfaces to it
  • Subify all GOSUBs (in progress)
  • Move battle variables into a small number of sanely organized UDTs for ease of access and ease of passing to subs (in progress)
  • Very important NOT to add lazy hack interfaces to un-cleaned-up battle code (more future backcompat nightmares) (Although the level of cleanliness achievable is not infinite)
• Re-implement existing attack/attacker animations in plotscripting (?)
  • AND/OR implement a high-level interface for triggering the existing animations

1. Collect underpants
2.  ???
3. Profit!

[edit] Other thoughts

• Should battlescripts reside in a separate file? Imported separately?
• How can we maintain and expand out collection of built-in attack animations using battlescripting? How can we do so in a way that makes lots of animations available to non-plotscripters, yet makes it easy for advanced scripters to add more animations without interfering with their own scripts?

[edit] Desired Interfaces

• Trigger attacks
• Manipulate turn-taking
• Manipulate menus
• Trigger spawning
• Manipulate rewards
• Directly move and animate sprites
• Display strings and rectangles (menus)
• Read keyboard input
• Access stats
• Implement formulas, such as new damage or accuracy math

[edit] An alternate possible plan

Currently, entering battle mode causes map mode (including scripts) to pause. Map mode (and scripts) resume when the battle ends.

This is very much like the way that the main menu used to work, and we successfully transitioned it to support scripting. Can the same approach work for battle mode?

• Clean up battle mode sufficiently so that battle initialization and battle main loop can be in separate subs.
  • This would have been very hard in the past, but now that battle uses BattleState and BattleSprite objects, this might not be that hard to do.
• When battle mode starts, battle is initialized, and then the battle main loop is called once per tick from the main game loop.
• Normal gameplay and scripts can be suspended while battle mode is active, in a method similar to what we used for the main menu.
• Battles can (optionally) be set to allow map activity and scripts to continue running in the background.
  • Even when map activity is allowed to run in the background, player control of the hero on the map, and non-scripted NPC movement should be suspended while battle mode is active.
• Battle would be fought on a layer on top of the map.
  • For performance, it would probably make sense to set the map layers invisible while battle mode is active (profile first to see if this is really needed)
  • Bonus! Could make it possible to specify "None" for backdrop, letting the map show through behind battle?
• Since plotscripts could continue to run on the map, we would need a "wait for battle" command that authors could use in conjunction with "fight formation" if they wanted to enable battlescripting in their game. (old games would need no changes, since battles would default to pausing map activity and scripts)
• Battle state information that is stored in BattleState, or BattleSlot would be easy to make accessible to scripts.
• When battle sprites have been rewritten to use slices, it would be easy to give access to them to scripts.
• Battle-specific script triggers could be added such as the ones listed above.
• Authors could do cool things like having fully functional text-boxes in battle, simply by moving the text box layer above the battle layer. Same goes for custom menus.
• Authors could do cool things like re-parenting their battle sprites to the map, Chrono-Trigger-style, yet still using most of the generic battle system.

The only really big downside to this plan that I can think of is that although re-writing the existing battle animations wouldn't be any harder with this system, removing the old battle animation code would not be very practical in this system (but maybe that is not such a big deal?)