This is my second step in an attempt to respond to the various comments and suggestions around this community to implement pre-battle setup and options (cf. calls for a "deployment phase"). The goal here is to cater to those who want an added level of strategy and control in the planning of their battle engagements--or, more pointedly, to allow the player to choose who will join them in battle, rather than the cryptic mix provided by the engine.
The Prebattle Deployment kit adds an option to the pre-battle menu that the player is presented with during any field encounter with an enemy party. With Tactics at level 2 or higher in the party, the player can choose to "Plan who will join you in battle". To allow for its function, a "Record Battle Size" menu option is also added to the Camp->Take an Action menu. Here the player must enter the battle size as set it is set in options (since the commands do not allow access to options settings from within code). This simply records the Battle Size, but does not impact the settings of the game. It only needs to be done once (unless the player edits their battle size setting) and then this will be stored in the savegame.
The Plan Deployment presentation lists each troop type that is in the player's party in the order they are listed in the Party Window. For each troop type in the party a number box appears, allowing a selection from 0 to the number of non-wounded troops of that type. The player can set the exact number of each troop that he/she wishes to spawn at the start of the battle. The presentation displays the number of troops that would be available to the player and holds the player's selection to that limit. Finally, across the bottom are currently three options: Scrap All--clear all number boxes to 0; to Reassess--return to the encounter menu without setting the deployment; or to Ready Troops--save this deployment and return to the encounter menu.
The selected troops will be the only troops to spawn with the player at the start of the battle, but the remainder will be available in reinforcement waves. The method used currently maintains
the number of ready-to-upgrade troops. While the exact amount of XP gained by troops in their progression toward the next level cannot be stored, the player should notice minimal changes to his/her party.Screenshots Galore
Note in the screenshots above that the troops at the top of the Party Window (the mounted and ranged troops) and thus Natively most likely to appear in battle are set to 0 in this test; they do not appear at the start of the battle.Code
Considering its size, I opted to not place the code in spoilers here. Instead it can be downloaded from the M&B Repository: Repository Kit Download
The following are modified:
- 2 triggers added to lead_charge to edit the player's party
- 1 script to get more information during the battle advantage calculation
- 1 menu option added to camp action
- 2 menu options added to two menus (simple_encounter and join_battle)
- 1 condition operation added to the start of simple_encounter and join_battle
- 1 condition operation added to all menu options of simple_encounter and join_battle
- 2 presentations added
- 9 constants defined
- 0 globals added; globals from Native presentations are used sparingly
- 0 slots added; party slots 47-51 (for centers) are used for "p_main_party", and troop slots 37-38 (for ladies) are used for soldiers
Quasi-technical discussion of method:
The presentation records the number in the troop's number box to a troop slot. Before the mission begins, a 'before mission start' trigger in lead_charge fires and checks the value of the troop slot of each troop-type in the player's party against the number of that type of troop in the party. Any "extra" troops are removed from the player's party just before the spawn.
The engine can only spawn from what is available to it and since the player's party is now ONLY the troops that the player wants in the first round, it is forced to spawn those troops.
After the spawn, an 'after mission start' trigger fires and uses the backup copy of the player's party (which is used to calculate casualties natively) to recall how many troops of each type SHOULD be in the party total, and adds the removed troops back to the players party so they can appear in reinforcement waves.
Currently, I am using the first 31 registers as the 'names' of the number box overlays used in the presentation. As only 60-some registers are defined, this limits my ability to expand the system to either more than one battle round, or to including more troop types. I'm unsure which way to go...my hunch is that the vast majority of player parties do not carry 30 unique troop stacks even if they have 10 or so companions, in which case I can add a second round, but I may be wrong.
The alternative, of course, is to create a huge number of new global variables (100 or so per round) to accommodate all of the possible troop types. So many globals seems unwieldy..and renews my frustration at the need to use global variables just to go between tuples of the same presentation.
Somebody helped greatly in clearing up my understanding of overlay reference IDs. Using troop slots to store the reference ID shortened the code exponentially and now will allow for all troops type in the party (regardless of number) to be accessed and opens up the possibilities for doing multiple rounds in the future.
As always, comments, questions, criticisms, suggestions are more than welcome.Checklist to Version 1
- Bug testing and squarshing
- Wrap for installation via sphere's ModMerger
Move to M&B Repository A version merged with Prebattle Orders
- Expand use to sieges, etc.
Allow set battle size presentation to be called from deployment screen if battlesize=0 Try for ways to not lose stack XP (troops waiting for upgrade)
- Cleaning up the presentation
Expand the number of troop types available (from 30 to 60)
- Add ability to specify deployments for further reinforcement waves?
- Bugfix for presentation truncating the player's party list
- Bugfix for 'undead' troops becoming available during multi-round battles
- Bugfix for correct number of troops available to be deployed, based on currently wounded party members
- XP for "ready-to-upgrade" troops is maintained
- Can accommodate as many troop types as are in the player's party
- If the player hasn't recorded a battle size, will call the Record Battle Size presentation before opening the Plan Deployment presentation
- Battle Size menus renamed from 'Set Battle Size' to 'Record Battle Size' to more accurately reflect their function
- Cleaned up and exponentially shortened the presentation code