Plan for implementing battlescripting
Battlescripting is a feature that users have been asking for ever since the introduction of Plotscripting.
The implementation is closely related to the Plan for script multitasking, in particular the part of having different kinds of script which pause in different situations. One idea is:
- A 'plotscript' is a script which runs on maps and pauses in battles
- Many other script types, like 'npc script', 'map script', etc, are like subtypes of plotscript, and also pause in battle
- A 'battlescript' is killed when its battle ends
- An 'attack script' or 'enemy script' or 'hero battle script' is tied to an enemy/whatever, and ends when that attack ends or enemy/hero dies.
- Other script types could run both in and out of battle, e.g. 'display script'.
- 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. See: Plan for converting battle display to slices
- Battle-specific script triggers could be added.
Merging battle and map mode[edit]
(The following was originally suggested for technical reasons surrounding invoking the script interpreter from inside battles, however is now completely unnecessary for that. It still has some merit.)
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. (partly done)
- 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 slice layer on top of the map.
- For performance, it would probably make sense to set the map layers invisible while battle mode is active
- 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)
- 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.
- However, this might conflict a bit with the semantics proposed in Plan for textboxes in battles
- 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)
- 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 big downside to this plan is that it seems like a lot of work. Also, while 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?)
This plan requires more thought!