Clearly the C++ side will have to control the battle loop.

Various games have used different methods of organization within that loop, though. I suppose that's where some of scripts have to take their cues.

FF1, for instance, has all characters to input their commands, from first to last. They cannot be skipped, but anything can still be cancelled and changed until the last character's command is confirmed.Then all combatants (characters and monsters) execute in order of some initiative value.

FF6 has speed stats for each combatant (subject to modifiers) and those are used to fill an ATB gauge. When the gauge is full, the command selection menu comes up (characters only, monsters just go to the next line in their attack script). Each command has a specified 'wait time,' (and it only depends on the command, not the character) so at a specified tick in the future the command will execute. And of course when the time comes, it executes and the ATB gauge resets. Characters in the ready-to-take-command state can also be skipped, forward or backward through the queue, if that is desired.

Conflicts for scheduling are handled behind the scenes (although I suspect it just occupies the next non-conflicting battle 'tick').

Another thing to note is the actual attacks have to be very fault-tolerant. The attacker may now be immobilized, or the intended target may no longer be valid, forcing the engine to re-target according to some criteria. Statuses may now be applied which alter the targeting (confusion), hit percentage (blind), etc. So there have to be specified hooks for these types of conditions, and checking at input time is not always sufficient (as intervening attacks may have changed the battle).


Hit determination and actual damage scripts are going to need access to few things: attacker attributes, target attributes, and spell/attack attributes.


Question: What kinds of math routines will we have at our disposal? I'd suggest we have a sort of standard set for clamping, lerping, etc.