Thorough comprehension to the default RMMV battle flow implementations

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
This topic aims to share my understandings to the default RMMV battle flow implementations, and I'll share the most advanced stuffs I know here fully. So you're assumed to have at least:
- Thorough comprehension to the default RMMV battle system on the user level
- Decent battle related javascript coding proficiency(experienced plugin developer having written at least dozens of decent battle related plugins with decent code qualities)
- Solid understanding to the default RMMV battle flow implementations
The focus of this topic corresponds to 'Applying' in the new version of the Bloom's Taxonomy.

Contents
I.Roles Of Battle Flow In Battle
1. Battle Elements
2. Without Battle Flow
3. Battle Rules
4. Summary
II. RMMV MVC Architecture
1. Model
2. View
3. Controller
4. Application To Battle Flow
5. Summary
III. RMMV Constraints
1. Successor Of RMVXA
2. Implication To Battle Flow
3. Summary
IV. Essences Of Default RMMV Battle System
1. Separation Of Inputs And Outputs
2. Batch Processing Nature
3. Mixing Paradigms
4. Summary
V. Battle Flow Design
1. Scene_Battle
2. BattleManager
3. Window_BattleLog
4. Summary
VI. Battle Flow Implementation
1. Scene_Battle
2. BattleManager
3. Window_BattleLog
4. Summary
VII. Battle Flow Code Qualities
1. Invariants
2. Correctness
3. Robustness
4. Coupling
5. Cohesion
6. Flexibility
7. Summary
VIII. Summary

Before actually covering any of the above contents, I want to explain why this topic's structured this way:
1. The main focus of the basic knowledge and solid understanding counterparts are what and how respectively, so this topic, which are supposed to be on an even higher level, should focus on why.
2. As the battle flow's always a component of its underlying battle system, the first part for answering the 'why' question is to thoroughly comprehend the roles of the former in the latter.
3. As a battle system of a game's always a part of the game, the latter's architecture will naturally dictate the former's design, which is vital in answering the 'why' question.
4. As the codebase of the battle flow's open to RMMV users, in which some of them will want/need to thoroughly comprehend those source codes, it's vital in fathoming the implication of the demanded thorough comprehension as constraints applied to the battle flow, ultimately restricting its design choices.
5. As the battle flow's a part of the default battle system, the former must be designed and implemented in ways conforming to all the latter's essences.
6. Therefore point 2 -5 must be taken into account when designing the battle flow, which determines its implementation.
7. Finally, applying code qualities to the battle flow and further grasp its core characteristics, which eventually aid in thoroughly comprehending the battle flow. Only those code qualities I think have anything special and important when it's applied to the battle flow will be mentioned.
I'll start to talk about the contents in the upcoming replies in this topic. For now, let's cite the detailed battle flowcharts as both a preparation on what I'm going to cover and a revision on what you're assumed to know already:

Battle Frame Update -
Default RMMV Battle Frame Update.JPG
Battle Start -
Default RMMV Battle Start.JPG
Action Input Phase -
Default RMMV Battle Action Input Phase.JPG
Action Execution Phase -
Default RMMV Battle Action Execution Phase.JPG
Battle End -
Default RMMV Battle End.JPG
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Now let's talk about I.Roles Of Battle Flow In Battle in depth.

Battle Elements
Scene
The scene's just the whole RMMV screen with UI in battle. It contains all the other visible battle and UI elements.
It's needed because the default RMMV battle system is a GUI battle system rather than a CLI one, and a GUI needs to be visible by users in order to work.
Also, a GUI needs to have graphical elements that can be manipulated by users, so the battle scene needs to decide what UI elements will be used.
Therefore, the battle scene's at the highest level among all battle elements, meaning that it's the best place to get the overview of the battle system.
Hence it's only natural for the battle scene to not interact with any low level element directly. Rather, it should delegate such tasks to intermediary elements, whose tasks can be as simple as forwarding.

Windows
There are 2 main types of windows in the battle system - Those taking inputs from users, and those showing outputs to users.

The former type includes the party command window, actor command window, skill window, item window, actor window and enemy window.
They're the key UI elements in the battle as they're the primary means for the users to engage in the battle system.
After all, unless all actors are confused, in autobattle or not movable, the battle just won't play on its own, as it needs user inputs in order to proceed.
Therefore, the tasks of the input windows are directly determined by the kinds of inputs available in the battle system.
Each input window's focused on receiving a specific kind of user inputs.
In the case of the default battle system:
- The party command window lets users decide to fight or try to escape
- The actor command window lets users choose from all available commands for the currently selected actor
- The skill/item window lets users choose from all available skills/items for the currently selected actor
- The actor/enemy window lets users choose from all available targets for the currently selected skills/items by the currently selected actor

The latter type includes the status window and log window. While the latter's also responsible for coordinating action execution timings, that won't be covered here.
While no output windows should be necessary in the default battle system in theory due to them being able to be replaced by sprites(e.g.: some plugin replaces the log window display with sprites showing equivalent info), the formers are still used instead of the latter.
Regardless of the medium(window, sprite, etc), the key is to deliver vital info to users at the right time.
Such vital info can be divided into 2 basic types - Those needed by users to decide what they can do, and those needed by users to know what battlers and effects have done. Both of these info must be delivered at the right time so users can always have the updated info.

In the case of the default battle system, The status window covers the former type in the Action Input Phase and the latter type in the Action Execution Phase, while the log window covers the latter in the Action Execution Phase.
Specifically, the status window shows the actor status info, which are about the current actor states, while the log window shows the latest change of battler status info, which can be caused by actions, states, buffs and debuffs.

Note that windows are high level elements in the battle system as they're the UI elements and interact with the scene directly.

Sprites
There are mainly 4 kinds of sprites - Battler sprites, state/buss/debuff sprites, action sprites and damage sprites(numbers).
The battler sprites inform the existence of battlers and their key statuses, like having a negative state, attacking, guarding, waiting and collapsing.
The state sprites inform which states the battlers have. For those having multiple states, the one having the highest priority will be shown.
The action sprites inform which skill/item's currently being used. As only 1 action can be executed at the exact same frame and every action has at most 1 action sprite, having multiple action sprites at the exact same frame should just be outright impossible.
The damage sprites inform the resource(hp/mp/tp) change in battlers. It can be due to actions, states and/or events.
In theory, due to the existence of the status window and log window, only the enemy and damage sprites are needed. It's because the those windows all the info the battle sprites, state sprites and action sprites have. However, they're still included, due to the default battle system being a sideview battle system.

Note that sprites are low level elements in the battle system, so they won't interact with the scene directly.
For instance:
- The battler spriteset bridges the scene and the battler sprites
- The state sprites are components of the battler sprites, meaning that the latter utilizes object composition
- The action sprites(animation sprites) are initialized by battler sprites, as an action must always be executed by at least 1 battlers(and exactly 1 for any Scece_Battle based battle systems without complete rewrites)
- The damage sprites are initialized by battler sprites, as only battlers can take damages

Battlers
While the battler sprites represent the visual parts of the battlers, battlers have much, much more than merely visuals.
In fact, battlers also have their own business logics and states which are encapsulated in some other objects - Game_BattlerBase, Game_Battler, Game_Actor(for actors), Game_Enemy(for enemies), making these classes abstractions of the aforementioned functionalities.

For instance, determining whether a specified battler can use a specified skill/item at a specified moment isn't an arbitrary decision made by an arbitrary component, but rather judged by the relevant parts of the battler business logics and states in the battle object.

Note that these battler objects are low level elements in the battle system, so they shouldn't interact with the scene at all.
While in the case of the default battle system, Scene_Battle still access Game_Battler internals extremely sparsely, almost all of such interactions are still delegated to the windows and BattleManager.

Actions
Actions, which have their own business logics, are the primary medium for battlers to interact with each other, which makes progresses in battle.
As actions can only be executed by battlers and the battler objects(i.e., not the visuals) will be responsible for this, actions are low level elements in the battle system, so they won't interact with the scene at all.
Instead, they interact with the battler objects and the BattleManager.
Note that the action business logics are completely separated from the action visuals, as they're indirectly linked by their skills/item data.

Events
In theory and sometimes in practice, a battle in the battle system can have no events at all, but they're still supposed to play a significant role in the battle system.
Because of their optional yet useful nature, the battle system isn't designed around events, it's just designed to make using events easy, simple and small tasks.
To facilitate this, the battle events are designed around the battle system instead - Bending the latter just to make the formers work seldom works.
This also implies that events should better be a low level element in the battle system, as its optional nature means that the higher its level, the more likely the battle system will have to design around the events rather than the other way around.
In the case of the default battle system, events interact with the BattleManager.

Without Battle Flow
Motherboard Analogy
A motherboard typically has a number of key components. Neither the motherboard nor any component will work on its own.
However, if the motherboard just has those key components and slots for inserting other components, having those components combined with the motherboard still won't work if the circuits in the motherboard were absent.
Even if the motherboard does have circuits, those circuits still can't be arbitrary. Instead, they've to be carefully designed and implemented so the entire system works as a whole. It's because they determine how the components interact with each other, and there are set rules behind such interactions.

Similarities To Battle System
Applying the motherboard analogy to the battle system, a battle consists of the aforementioned key components.
Each of those component won't work on their own in battles, so they've to interact with each other in order to work.
However, such interactions can't be arbitrary, as the battle system's its goal under its context, which can only be set by meeting certain conditions and conforming to certain constraints. Those interactions will have to be carefully designed and implemented in order to achieve all these.
It's where the battle flow comes into play. The battle flow's designed to integrate all the battle rules to ensure they're all conformed and no unnecessary restrictions are imposed.
Therefore, to thoroughly comprehend a battle flow, one must first thoroughly comprehend its underlying set of battle rules.

Battle Rules
As the 2 main phrases of the default battle flow are the Action Input Phase, which are focused on taking inputs from users and AIs, and the Action Execution Phase, which are focused on producing outputs based on received inputs, battle rules should be divided by input rules and output rules.
While you're supposed to have grasped them all already, I'd still cover them here in order to reason about the relationships between the battle rules and the battle flow.

Input Rules
1. If there are no inputable actors in the Action Input Phase, the entire phase's skipped and the Action Execution Phase's commenced.
2. Players must first choose whether to fight or try to escape.
3. If players choose to escape, then a successful escape means battle end with escape, while a failed one will make all actor not inputable, which is subject to the 1st rule.
4. If players choose to fight, then players must input from the 1st action slot of the 1st inputable actor to the last action slot of the last inputable actor.
5. Players can't skip any action slot nor inputable actor or change the input sequence in the 4th rule.
6. Players can cancel the previously inputted commands all the way back to that in the 2nd rule, unless they've inputted the last action slot of the last inputable actor.
7. The Action Input Phase can only process player inputs and nothing else.

Output Rules
1. If all actors or enemies are dead, then the battle's won or lost respectively(the battle's still lost even when both are dead).
2. If no battlers can execute actions, the entire Action Execution Phase's skipped and the Action Input Phase's commenced unless the 1st rule's applicable.
3. The action execution sequence among all battlers are descendingly sorted according to their speeds.
4. Only 1 battler can execute actions at the exact same frame.
5. Only 1 action can be executed at the exact same frame.
6. Only 1 battler can be targeted at the exact same frame.
7. The Action Execution Phase can never process any player input, unless they're requested by events.

The keys aren't those specific details of those rules themselves, but rather how those rules dictate the design and implementation of the battle flow.
Strictly speaking, the role of the battle flow's to ensure all key components conform to all battle rules by designing and implementing their interactions.

For instance:
- Removing the 2nd input rule by disallowing escape will immediately mean removing the party command window and its linkage with the 1st inputable actor in battle.
- Removing the 5th input rule will immediately break the doubly linked list for all action slots of all inputable actors and introduce a new bug causing supposedly cancelled actions to be executed.
- Removing the 7th input rule and/or the 7th output rule will immediately demand a complete rewrite of the entire battle system.

Summary
Battle Elements
A battle consists of the below key elements:
1. Scene(Highest level) - The whole GUI of the battle which determines which of the other elements will be used
2. Windows(High level) - The UI elements taking user inputs and key info delivery medium
3. Sprites(Low level) - The visuals of battler, state/buss/debuff, action damage which interact with the scene via sprite sets
4. Battlers(Low level) - The collection of battler business logic which interacts with the scene via BattleManager and windows(with few exceptions)
5. Actions(Low level) - The action business logic and medium for battlers to interact with each other
6. Events(Low level) - The optional yet useful user-defiend triggers that interact with the scene via BattleManager

Without Battle Flow
All the other key components simply won't work as they lack the interaction mechanisms which are dictated by battle rules.
The role of the battle flow's to design and implement such interactions that conforms to all the said battle rules.

Battle Rules
As the 2 main phrases of the default battle flow are the Action Input Phase, which are focused on taking inputs from users and AIs, and the Action Execution Phase, which are focused on producing outputs based on received inputs, battle rules should be divided by input rules and output rules.
The keys aren't those specific details of those rules themselves, but rather how those rules dictate the design and implementation of the battle flow.
Strictly speaking, the role of the battle flow's to ensure all key components conform to all battle rules by designing and implementing their interactions.
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Now let's talk about II. RMMV MVC Architecture in depth.
You're highly encouraged and recommended to grasp what MVC is first if you haven't already.
Summarizing some reasons for using MVC in RMMV:
1. RMMV has many event listeners due to the fact that it's mainly event driven, which are mostly high level and application specific.
2. RMMV has many business logics, which are mostly low level and problem domain specific.
3. RMMV has many presentation logics, which are mostly also low level and problem domain specific, but probably belonging to different problem domains from those of the business logics.
4. To facilitate establishing, grasping and stablizing the big picture combined by all the high level application specific elements, that big picture should be easy, simple and small, meaning that those high level application specific elements should be as thin as possible and as far away from the lower levels, which are more prone to frequent nontrivial changes, as possible. Check the fat controller antipattern for details.
5. As RMMV belongs to certain problem domains, it should be able to reuse, at most with some minor tweaks, at least some business logics and presentation logics in the latters, which are mostly about how something can be done.
6. Therefore those high level application specific elements should be about control flow deciding which business logics and presentation logics should be used under what circumstances.
7. Business logics and presentation logics should be separated as much as possible, as the formers and the latters belong to different domains, meaning that they've different reasons to change. Check the single responsibility principle for details.
8. As presentation logics are to present data, which are handled by business logics, which are called by high level application specific elements, the entire architecture naturally fits into the MVC architectural pattern.

Model
Note that in RMMV, model isn't mainly about data, but rather business logics, including those handling data.

Managers

While not all manager classes in rpg.managers.js are pure model, i'll still list some that are obviously model:
DataManager - It stores all business logic for accessing the database, including those loaded as game objects during the game execution
BattleManager - It stores all business logics for implementating the battle flow of the battle system, especially the Action Execution Phase
In the case of the BattleManager, it might seem to be a hybrid of the model and controller, as it delegates most low level tasks to Game_Action, Game_Actor, Game_Enemy, Game_Party, Game_Troop, Game_Event, Game_Interpreter and Window_BattleLog.
However, BattleManager takes no user inputs in battles at all, and actually doesn't even care what they are or whether they exist. It's because all user inputs in battles are handled by Scene_Battle.

Recall that the Action Input Phase only allows user inputs and bans everything else while the Action Execution Phase only allows user inputs requested by battle events and bans any other user inputs.
Therefore, BattleManager is still mostly a model, as it implements all the business logics used by all the commands issued by the event listeners in the Action Input Phase and implements the entire business logics in the Action Execution Phase.
Strictly speaking, though, if we define the user of the BattleManager to be the battle system, then the BattleManager should instead be regarded as a hybrid of a controller and model, as the business logics of the Action Input Phase become the event listeners, which listen to the inputs from the battle system, of the battle flow. It means that RMMV should be regarded as using HMVC instead.

Game Objects
Almost all game objects, possibly except Game_Interpreter, are nearly pure models. For instance:
1. Game_Action handles all business logics for an action, which consists of the subject, the skill/item, target scope and targets, and speed, to be inputted, cleared, validated,evaluated and executed.
2. Game_Battler handles all business logics for a battler, which consists of so many aspects of a battler, which has dozens of states and uses tons of data from the database(some of them are accessed via Game_Item), that it's not practical to enumerate them all here lol(Game_Battler is quite a fat model after all)
Off topic: I think object composition can actually be applied at least a bit more in Game_Battler, even though it'll probably lead to noticeably more callbacks which make the codebase slightly harder to grasp

3. Game_Unit handles all business logics for a group of battlers belonging on the same side, including their selections based on certain criteria, wrappers for issuing the same commands and/or queries to all battlers in the group, and functions aggregating certain elements of those battlers.
On a side note: Due to the inevitably frequent access to the database and the stateful nature of the problem domains behind these models, those business logics have to be abundant, meaning that it's extremely hard not to bloat any model without having too many models. Hence RMMV has to reach a fine balance which is rather difficult to achieve.

View
Note that in RMMV, most views get most data from the model rather than the controller, which somehow dictates which views are used sometimes.

Sprites

Basically, all sprites are at least mainly views. For instance:
1. Sprite_Battler handles all presentation logics for rendering the battler sprites, including their poses, positions, visibilities, state/buff icons, damages being taken, etc.
2. Spriteset_Battle is basically everything visible besides windows in battles, including battler sprites, by wrapping all those belonging to the same side.
Note that the sprite set has the isBusy function, checking whether any sprite/animation's busy. It's used by the battle flow to prevent executing anything new before finishing any existing executions, meaning that sprites need to be coordinated in battles instead of totally functioning independently based on their received commands only. This somehow contrasts with some of the MVC intents, which are supposed to let the views be updated in real time.

Windows
Roughly speaking, windows can be divided into 3 categories:
1. Windows only showing outputs
2. Windows only receiving inputs
3. Windows showing outputs and receiving outputs
The 1st one is mostly a view, while the others are usually hybrids of view and controller, because many graphical components in windows are drawn by the windows directly, instead of being delegated on lower level views. For instance:
1. Window_BattleStatus only shows outputs, which are the most important statuses of all actors currently in the battle, including their hp/mp/tp, states/buffs, which one's the currently inputting one, which one's being targeted(by showing the change of many of the aforementioned statuses), etc
2. Window_NameInput only receive inputs, as what characters and how many of characters can be inputted are totally independent of everything else, meaning that they're encapsulated and are effectively immutable.
3. Window_PartyCommand shows outputs by indicating whether players are allowed to try to escape, and receives inputs by letting players choose whether they're to try to escape or to fight.

A window that stands out is Window_BattleLog, as it also coordinates the sprites during action executions. Therefore, the only way to not treat it as a model is to regard the entire coordination among the views as a high level presentation logic. That's 1 reason why the roles of the Window_BattleLog can be so confusing, deceiving and elusive for many of its readers.
Unfortunately, thinking that Window_BattleLog is only responsible for showing the battle log window's one of the most costly, deadliest and most insidious mistakes one can ever make when trying to thoroughly comprehend the battle flow, as it can easily lead to the complete unawareness of the synchronizations from the action execution business logics and the action execution presentation logics that are supposed to take place in an interleaved manner, which is central to keep the action executions in a visibly sequential approach.
In short, Window_BattleLog plays a much, much more important role in the battle flow implementation than what it seems to be, so it's vital to thoroughly comprehend it.

Controller
Windows
Windows that only receive inputs, and show outputs and receive inputs, are hybrids of view and controller.
When it comes to the controller parts, windows normally play the role as the event listener implementations.
While Scene_Battle defines which event listeners are used and which events triggers which behaviors for each of those event listeners, windows actually implement these linkages.

For example, Window_BattleSkill lets players selects a skill among all the available ones for the current action slot of the currently inputable actor.

While which skills are available are delegated to battler business logics, how to not let players select unavailable skills and let them select available ones are responsibilities of the skill window. Also, it needs to know which skill's actually selected by the players, as it's the only component receiving such inputs.
After selecting a skill, the control will be passed back to Scene_Battle.
In other words, Scene_Battle is a high level controller while windows having the controller functionalities are low level controllers.

Scenes
Battle scenes are, and should be, pure controllers, as it's the highest level element in battles.
Basically, Scene_Battle has 2 responsibilities - Dictates which windows and sprites are to be used in battles, and sets which behaviors to be triggered given which received events for each event listener used. Of course, because all scene's are also responsible are running the game loop, Scene_Battle must also run the Battle Frame Update.
Recall that Scene_Battle should illustrate the big picture completely, concisely and precisely , meaning that it should be easy, simple and small.
As the 2 main phase in the battle system's the Action Input Phase, which only receives player inputs and does nothing else, and the Action Execution Phase, which only receive inputs requested by events, Scene_Battle should be focused on the former and let BattleManager handles the latter.

Application To Battle Flow
Model
Here, the problem domain behind the business logics of the battle flow are all the underlying battle rules governing the battle system.
Recall that the battle flow implementations focus on the existence of battle phases, their implementations and their transitions.
Besides the Action Input Phase, which only allows player inputs and nothing else, meaning that it's mostly a controller, all the other parts of implementations are nearly pure models.

While most models are low level elements, in the case of the battle flow, it's not a low level element, and is the highest level element among all models in the battle system.
It's because:
1. Scene_Battle directly delegates the whole Action Execution Phase and all business logics of the Action Input Phase to BattleManager, which is largely, albeit not entirely, about the battle flow implementations.
2. The battle flow delegates many lower level tasks to many other business logics, including those of actions, battlers, events, etc.
It means that, in order to thoroughly comprehend the business logics of the battle system, one should first thoroughly comprehend the battle flow in order to grasp the big picture.
Only then, one can effectively and efficiently simulate how the battle system runs in their head, which is vital in getting what's really going on behind the scenes.

View
In essence, the battle flow has pretty much nothing to do with any of the views, as battle flow's not about presentation logics at all.
Even if the entire view coordination presentation logics handled by Window_BattleLog is considered as a high level aggregate view, the only key to the battle flow is that the action execution business logics and the action execution presentation logics have to be run in a interleaved manner in order to keep the sequential nature obvious, as how those views are coordinated are delegated to a high level view - Window_BattleLog.
Recall that the role of the battle flow's to ensure all key components conform to all battle rules by designing and implementing their interactions.
As no battle rule has any concern on any presentation logic at all, the actual battle flow's implementation's aligned with what it's supposed to do and what it's supposed not to do.

Controller
Recall that controllers are high level application specific elements, meaning that all event listeners in the battle system should be specially designed around it.
For instance, the need of the party command window, which is an event listener receiving events indicating whether the players try to escape or fight, comes from the battle rule letting players to have such a choice to begin with.
Because only the Action input Phase, which is sequential in nature, is almost a pure controller, adding/editing/removing any event listener can lead to at least tiny corresponding changes to some of the others.
For example, if the party command window were not needed, then the Prior Command, which navigates from the currently active event listener to the previously active event listener, would have to stop at the 1st action slot of the 1st inputable actor, meaning that the head sentinel node of the doubly linked list linking all action slots of all inputable actors would be removed.

Similarly, when starting the Action Input Phase, Scene_Battle would also need to ask the BattleManager to setup the index of the 1st inputable actor instead of opening the party command window.
Therefore, one should first thoroughly comprehend the whole sequence of controllers before adding any new one to the sequence, or editing/removing any one already in the sequence.
Even seemingly minor changes, such as just adding a new key to allow triggering the Next Command without first completely inputting the current action slot of the currently inputable actor, can already have devastating consequences if one doesn't really know what he/she's truly doing.
Recall that a completely inputted action slot will never be cleared, even when Prior Command is triggered to return to previous action slots.
It means that, a seemingly correct yet actually buggy implementation of the above perceived tiny change can lead to action slots that should have been cleared to be actually executable, which can lead to unintended user experience including fake empty action slots and exploits leading to executing actions without paying their costs.

Summary
In RMMV, model isn't mainly about data, but rather business logics, including those handling data.
Some managers, like DataManager and BattleManager, and most game objects, like Game_Action, Game_Battler and Game_Unit, are models.
Strictly speaking, though, if we define the user of the BattleManager to be the battle system, then the BattleManager should instead be regarded as a hybrid of a controller and model, as the business logics of the Action Input Phase become the event listeners, which listen to the inputs from the battle system, of the battle flow. It means that RMMV should be regarded as using HMVC instead.

In RMMV, most views get most data from the model rather than the controller, which somehow dictates which views are used sometimes.

Basically, all sprites, like Sprite_Battler and Spriteset_Battle, are pure views.
Note that sprites need to be coordinated in battles instead of totally functioning independently based on their received commands only. This somehow contrasts with some of the MVC intents, which are supposed to let the views be updated in real time.
Windows that only show outputs, like Window_BattleStatus, are mostly views.
Windows that only receive inputs, like Window_NameInput, and shows outputs and receive inputs, like Window_PartyCommand, are hybrids of view and controller.
In the case of the Window_BattleLog, the only way to not treat it as a model is to regard the entire coordination among the views as a high level presentation logic.
For windows having controller responsibilities, they're event listeners implementing the linkages from the received events to the specified behaviors, even though such linkages are specified by the battle scene.

Battle scenes are, and should be, pure controllers, as it's the highest level element in battles. It dictates which windows and sprites are to be used in battles, and sets which behaviors to be triggered given which received events for each event listener used.
Scene_Battle is a high level controller while windows having the controller functionalities are low level controllers.


When it comes to the battle flow:
Model -
1. The problem domain behind the business logics of the battle flow are all the underlying battle rules governing the battle system.
2. Besides the Action Input Phase, which only allows player inputs and nothing else, meaning that it's mostly a controller, all the other parts of implementations are nearly pure models.
View -
1. In essence, the battle flow has pretty much nothing to do with any of the views, as battle flow's not about presentation logics at all.
2. As no battle rule has any concern on any presentation logic at all, the actual battle flow's implementation's aligned with what it's supposed to do and what it's supposed not to do.
Controller -
1. Because only the Action input Phase, which is sequential in nature, is almost a pure controller, adding/editing/removing any event listener can lead to at least tiny corresponding changes to some of the others.
2. Therefore, one should first thoroughly comprehend the whole sequence of controllers before adding any new one to the sequence, or editing/removing any one already in the sequence.
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Now let's talk about III. RMMV Constraints in depth.
You're highly encouraged and recommended to have a solid understanding on the default RMVXA battle flow implementations.

Successor Of RMVXA
Being a successor of RMVXA means the RMMV codebase can't be too different from that of the former or else too many RMVXA scripters would fail to become a decent RMMV plugin developer within reasonable amount of resources, thus reducing the amount of decent RMMV plugins, which will ultimately make the whole RMMV ecosystem suffer.
Nevertheless, when it comes to be battle system, RMMV at least has the following significant difference from RMVXA:

Visual Change
Those being familiar with both the RMVXA and RMMV battle systems should know that RMVXA uses front view(and enemy sprites have no pose at all) while RMMV uses side view with battler poses.
On the user level, that are mostly visual changes as they doesn't change how the battle system itself works at all, so that might make some non scripters/non plugin developers think that such change's trivial.
On the design and implementation level, however, such change actually adds a significant amount of new complexities that are at least slightly alien to most RMVXA scripters, except those already familiar with side view scripts supporting battler poses.

Unfortunately, there were not so many RMVXA scripters having experience in working on such scripts when RMMV's just released, so their path of adaptation only becomes even more challenging.
When it comes to the battle system design, now it'll also have to know all the battler poses to be supported, and primarily, what each of them means and when to change to which one.
On the implementation level, this will mean extra dependencies among the battle flow, battler business logic and battler presentation logic.
Managing such dependencies shouldn't use elegant but advanced Javascript ES5 techniques, or many RMVXA scripters will suffer by trying to catch up; It shouldn't use basic but smelly(adding lots of bad technical debts) workarounds either, or developing related RMMV plugins can become a misery.

Language Change
Those being both a RMVXA scripter and RMMV plugin developer should know that RMVXA uses Ruby 1.9.x and RMMV uses Javascript ES5.
Those being familiar with the former but not the latter when RMMV was just released should have experienced the amount of difficulty and effort needed to learn the latter.
Also, back when RMMV was just released, there were not many RMVXA scripters that were also already familiar with Javascript ES5.
Just asking/guiding/helping such RMVXA scripters to learn Javascript ES5 without having something familiar with to refer to would take weeks, if not months, before they can have become familiar with it.

In order for them to quickly adapt to RMMV plugin development, they'll have to constantly try to grasp the RMMV codebase as they're learning Javascript ES5.
As most of them are likely used to the way the RMVXA codebase works, they'll naturally cast many expectations that have worked in the RMVXA codebase to the RMMV one.
The more unexpected elements they've found in the latter, the more probably the harder for them to grasp it and thus Javascript ES5.
After all, grasping a codebase can help them grasp the language used by that codebase, so this factor should be regarded as vital when designing the RMMV codebase.

On a side note: Of course, there were some RMMV plugin developers that were already familiar with Javascript ES5 but have no RMVXA, or even any previous RM experience at all. This case will be discussed later.

Structural Change
When it comes to the battle system, there are 2 major changes: The Action Execution Phase implementation shift from Scene_Battle to BattleManager, and the action damage implementation shift from Game_Battler to Game_Action.
Recall that, in both RMVXA and RMMV:
The battle log window and the status window are held by Scene_Battle by instantiating them there and nowhere else.
The Action Execution Phase needs to show the battle log window and update the status window at timings only known by itself.


In RMVXA, as all these implementations are in Scene_Battle, the interaction between the Action Execution Phase and those windows are easy, simple and small.
In RMMV, however, those windows are held by Scene_Battle but those timings are held by BattleManager, which implements the Action Execution Phase.
Any experienced RMVXA scripter/RMMV plugin developer knows that accessing BattleManager from Scene_Battle's much easier, simpler and smaller than the opposite as the former's effectively a static class while the latter's always instantiated into exactly 1 object but it's not a singleton.

As all windows held by Scene_Battle are supposed to be private, letting BattleManager to access them directly would violate information hiding and risk turning their interactions into spaghetti code.
Instead, RMMV uses dependency injection - setter injection in this case, by asking Scene_Battle to pass those window instances held by it to BattleManager, which reference them as private variables thorough the whole battle.
Note that neither constructor injection nor method injection can work here at all.
The former won't work here at all as BattleManager's effectively a static class and has no real constructors.
The latter won't work here at all as only the Action Execution Phase, which are implemented solely by BattleManager, has the needed timings, meaning that Scene_Battle won't know when to inject the dependencies this way, otherwise dependency injection would be meaningless, pointless and useless here in the first place.


While many RMVXA scripts also uses dependency injection, often it's used unconsciously, as it's just a natural technique for us and we're used to it.
However, as RMMV uses dependency injection to let the Action Execution Phase to show the battle log window and update the status window at timings only known by itself, RMMV plugin developers now have to be conscious on this long used technique in order to quickly adapt to this structural change.

On the other hand, as the battle system doesn't care much about the specific details of the action damage implementation, shifting it from somewhere to somewhere else doesn't mean much to the battle system.
At most, it means that now actions become a noticeably more active component in the battle system due to it having more responsibilities which should have been its responsibilities to begin with.

Implication To Battle Flow
Learn New Language vs Learn New Framework
Recall that there were also some RMMV plugin developers that were already familiar with Javascript ES5 but have no RMVXA, or even any previous RM experience at all.
It's normal for them to tend to think that the RMMV codebase mixes different conventions, styles and even paradigms for no good reasons, as they weren't familiar with the RMVXA codebase.
For instance, the absence of using self executing anonymous function to wrap the implementations, those $dataXXX($dataItems, $dataSkills, etc) , $gameXXX($gameParty, $gameTroop, etc), Game_XXX(Game_Action, Game_Battler, etc), and Window_XXX(Window_BattleStatus, Window_BattleLog, etc), and the underuse of functions as first-class citizens may become unnegligible eyesores for them.
So it's understandable for them to think that the RMMV codebase's badly written, as they just don't have the big picture.
On the other hand, if the RMMV codebase's just to accommodate their expectations, it'd become too hard for the majority of RMVXA scripters having no Javascript ES5 experience to adapt quickly enough.

So the RMMV codebase has to find the thin balance between these 2 groups of potentially decent RMMV plugin developers.
In other words, it's to make a reasonable compromise between learning a new language and learning a new framework.

Clearly, the RMMV codebase design leans towards the path of asking them to learn a new language using the existing framework.

It's reasonable as Javascript ES5 is only new to those having no such experience, and there are many such experienced developers, meaning that guides, helps and tutorials are readily available for the formers to learn.
On the other hand, a new RM framework would be new to the entire mankind as it doesn't exist anywhere anytime before in the earth.
If the new RM framework were actually too similar to other existing frameworks from other companies, RM would risk taking lawsuits.
Therefore, if RMMV used a new RM framework instead of inheriting most from RMVXA, the RMMV plugin developer community would end up stumbling in the dark for quite a long time.
So the default RMMV battle flow implementations, or at least its designs, must be based on those of the RMVXA, meaning that thoroughly comprehending the latters will greatly facilitate the thorough comprehension to the formers, at least for those also being RMVXA scripters.

P.S.: While continuing to use Ruby instead of switching to Javascript would solve the above conflicts, doing so would only introduce even larger troubles, as one of the cornerstones of the core business values of RMMV is reflected by this part of its marketing slogan - "versatile enough for any platform", it's to use Javascript in order to make the game run on browsers so it can be effortlessly ported to at least Android and iOS, otherwise that process wouldn't be "easy enough for a child".

Limited Changes Available
As mentioned, the default RMMV battle flow implementations, or at least its designs, must be based on those of the RMVXA.
With the aforementioned Action Execution Phase implementation and action damage implementation shifts, which are themselves nontrivial changes, there's not much room left for the default RMMV battle flow implementations to change before it'd be so different from that of the RMVXA that RMVXA scripters having no Javascript ES5 experience would have a hard time to adapt quickly enough. Hence RMMV can't fix all the brittle, leaky and restrictive designs inherited from the RMVXA.

For instance, recall that Prior Command will never clear any previously inputted action slots, which will cause just adding a command to trigger Next Command without completely inputting the current action slot of the currently inputable actors will cause seemingly cleared actions, potentially with uninputted targets, to be executed, thus causing surprising bugs.
While fixing it can be as simple as just clearing the action slot(on actor/enemy cancel for clearing targets and on skill/item cancel for clearing item to be precise) upon Prior Command, there's at least 2 reasons not to fix it:
1. This design flaw doesn't matter as long as ending the Action Input Phase can only be done by traversing its doubly linked list linking all action slots of all inputable actors to its tail sentinel node.
2. Fixing this design flaw can cause the implementation to be more colossal, complex and convoluted than it needs to be, which is a potential violation of KISS.

Another example is injecting the status window instead of the refreshStatus function of Scene_Battle to BattleManager.
While this design flaw has at least the following issues:
1. BattleManager doesn't need the whole status window but only wants its refresh function to be called at the right time.
2. This design hardcodes the assumption that only the status window needs to be refreshed at that timing, which can cause troubles for some RMMV plugins.
3. The extensibility required by RMMV means the necessity of the refreshStatus function as a seam in BattleManager just to call the refresh function of the status window, causing a direct violation of DRY as it does the exact same thing as the refreshStatus function of Scene_Battle but only differs from the timing to be called.
However, injecting the refreshStatus function of Scene_Battle would have to treat it as a first-class citizen that is bound to Scene_Battle even when it's called by BattleManager, which can be foreign to many RMVXA scripters having no Javascript ES5 experience.
It's generally more important to ensure sufficient amount of RMVXA scripters can adapt to RMMV plugin developement sufficiently quickly than improving the codebase quality when it's already reached the bare minimum for most RMMV plugin developers.


On a personal note: If there will be something like RPG Maker MV Ace, I think many of these design flaws will be at least partially fixed, as the change from Javascript ES5 to Javascript ES6/7/8+ should be drastically smaller than that from Ruby 1.9.x to Javascript ES5.

Summary
Successor Of RMVXA
Those being familiar with both the RMVXA and RMMV battle systems should know that RMVXA uses front view(and enemy sprites have no pose at all) while RMMV uses side view with battler poses.
When it comes to the battle system design, now it'll also have to know all the battler poses to be supported, and primarily, what each of them means and when to change to which one.
Those being both a RMVXA scripter and RMMV plugin developer should know that RMVXA uses Ruby 1.9.x and RMMV uses Javascript ES5.
In order for them to quickly adapt to RMMV plugin development, they'll have to constantly try to grasp the RMMV codebase as they're learning Javascript ES5.
As most of them are likely used to the way the RMVXA codebase works, they'll naturally cast many expectations that have worked in the RMVXA codebase to the RMMV one.
The more unexpected elements they've found in the latter, the more probably the harder for them to grasp it and thus Javascript ES5.
After all, grasping a codebase can help them grasp the language used by that codebase, so this factor should be regarded as vital when designing the RMMV codebase.

When it comes to the battle system, there are 2 major changes: The Action Execution Phase implementation shift from Scene_Battle to BattleManager, and the action damage implementation shift from Game_Battler to Game_Action.
RMMV uses dependency injection - setter injection in this case, by asking Scene_Battle to pass those window instances held by it to BattleManager, which reference them as private variables thorough the whole battle.
RMMV plugin developers now have to be conscious on this long used technique in order to quickly adapt to this structural change.

Implication To Battle Flow
RMMV codebase design leans towards the path of asking them to learn a new language using the existing framework.
RMMV battle flow implementations, or at least its designs, must be based on those of the RMVXA, meaning that thoroughly comprehending the latters will greatly facilitate the thorough comprehension to the formers, at least for those also being RMVXA scripters.

With the aforementioned Action Execution Phase implementation and action damage implementation shifts, which are themselves nontrivial changes, there's not much room left for the default RMMV battle flow implementations to change before it'd be so different from that of the RMVXA that RMVXA scripters having no Javascript ES5 experience would have a hard time to adapt quickly enough. Hence RMMV can't fix all the brittle, leaky and restrictive designs inherited from the RMVXA.
It's generally more important to ensure sufficient amount of RMVXA scripters can adapt to RMMV plugin developement sufficiently quickly than improving the codebase quality when it's already reached the bare minimum for most RMMV plugin developers.
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
Now let's talk about IV. Essences Of Default RMMV Battle System in depth.

Using message passing to abstract out the default RMMV battle system(actually any Scene_Battle based battle system), a battler is both a message sender and receiver, and an action is a message with each target invocation being a copy.
Each sender has its own input message queue storing all messages to be sent; Each receiver has its own rules to determine whether a received message copy is to be deleted(eva/mev), replied(cnt), sent back(mrf) or taken as is.
Each message has the following components:
1. A method to determine whether this message can be sent by checking whether the sender is available(movable) and can pay the cost(action cost) of sending the message
2. A list of recipients(action targets)
3. Contents to be delivered(changed applied to) to each recipient
4. Number of copies(repeats) to be delivered to each recipients
5. A method to determine the absolute priority(action speed) based on the message contents and sender
6. Notifications to be shown to everyone(action animations and action info shown on the battle log) when sending the message

Separation Of Inputs And Outputs
The core UX of the default RMMV battle system is to use an actor combination to use some action permutations to fight a an enemy combination having their own action permutations, by emphasizing combinations and permutations.
Therefore, the default RMMV battle system UI must, by design, highly encourage and recommend players to think in combining actors and permutating actions into a completed set.
This can only be done by ensuring that the action permutation always include all available action slots, meaning that they must all be inputted before executing any inputted action.

Similarly, once all available action slots are inputted, they must all be executed before allowing further inputs, or the predictability of the action permutations will be drastically reduced by letting new inputs alter the effects of the already executing action permutations.
As predictability is the cornerstone of promoting strategic and tactical thinking when planning action permutations, all inputs should be banned when executing the set action permutations.
So the default RMMV battle flow must be divided into inputs only and outputs only.


On a side note: Due to some intentionally incomplete designs to be completed by plugins(to keep the editor easy, simple and small), actor permutation, not just combination, is actually important, as indicated by the fact that the one with the smallest party/troop index among all actors/enemies that can perform substitute(cover) will always be chosen to do the job.

Inputs Only
As mentioned, the Action Input Phase only allows inputting actions for inputable actors and nothing else.
Using the message passing abstraction, the Action Input Phase is to completely fill all message slots(action slots) in the newly allocated input message queues of all available senders by letting players and AIs input available messages for all inputable ones and letting those uninputable but available(i.e., autobattle/confused) senders to input available messages themselves.
In order to ensure that while keeping the UX easy, simple and small to maintain, the Action Input Phase enforces players to input from the 1st available message slot in the 1st available input message queue to the last available message slot in the last available input message queue before proceeding to the Action Execution Phase.
That way, players can always clearly remember which actors have inputted what actions and how many actions, even though it'll cause amending an action that needs several Prior Command to reach a bit painful.

The key role of the Next Command/Prior Command in the Action Input Phase is to transfer control from the an available message slot to another one.
In the default RMMV battle system, an available message slot only allows players to choose 1 of the following:
1. Completely fill this available message slot and proceeds to the next one
2. Goes back to the previous one(or when the head sentinel node in the doublt linked list's reached, the party command window)

This design is intentionally restrictive to keep its implementations easy, simple and small.
For instance, if the battle flow would allow players to use Next Command without first completely inputting the currently inputting action slot(regardless of whether it's already completely inputted or not), then the implementation would also have to check whether that action slot's completely inputted or not.
While this check itself's not much a trouble, the presentation would also have to at least inform players that such Next Command is invalid, like by playing a SE for an invalid move.
These changes alone without further explanations would likely confuse lots of players using the current UI design, which doesn't even show all the action slots of an actor, let alone which action slots are already inputted.
Therefore, this seemingly trivial change, when combined with the constraint to ensure all inputable action slots are inputted, can actually mean lots of seemingly unrelated changes, like redesigning the status window/actor command window to show the current action slot status.

P.S.: A reason to disallow leaving some inputable action slots empty is to ensure no players will do that by accident, as such mistakes would be extremely costly and hard to be undone once the battle proceeds into the Action Execution Phase, which is supposed to ban all user inputs.

Outputs Only
As mentioned, the Action Execution Phase bans all user inputs except those requested by battle events, which is discouraged by design and rare in practice.
Using the message passing abstraction, the Action Execution Phase executes the following tasks:
1. Combines all input message queues from all available senders into a single output message queue descendingly ordered by the message priorities.
2. Sends the 1st message that can be sent in that output message queue to all its recipients and removes that message from that queue.
3. Repeats 2 until the battle ends or all messages in the output message queue are sent.

Note that the action permutation, not just combination, is the key in forming the output message queue, as the order of actions to be executed is vital, due to the fact that even a slightly different ordering can already lead to drastically different results.
Therefore, the action permutation cannot be random or based on something totally unrelated, like the priority of party vs troop, priority based on party/troop member index, etc.
Instead, as each battler has its own agi and each skill/item has its own speed, it's only natural to combine them to form the speed of an action, which is used to determine the action permutation in the output message queue.

Also, in order to clearly illustrate the effects of the action permutation with potential counter attacks/magic reflections, each action invocation should be immediately followed by its action invocation presentation, and an application to each target for each repeat should also be immediately followed by its action effect presentation. That's why action execution business logic and action execution presentation logic should take place in an interleaved manner.
For the very same reason, the following 3 of the most fundamental foundation should be preserved:
1. Only 1 battler can execute actions at the exact same frame.
2. Only 1 action can be executed at the exact same frame.
3. Only 1 battler can be targeted at the exact same frame.

Batch Processing Nature
Collect Inputs In Real Time
While players are always enforced to input from the 1st inputable action slot of the 1st inputable actor to the last inputable action slot of the last inputable actor, when to input the currently inputting action slot should be controlled by them, as the goal of the default RMMV battle system is to promote players to use strategic and tactical thinking to plan for an action permutation.
If there were a time limit, players will also face an additional pressure that is completely against the UX supposed to be delivered to them.
If there were no time limit, however, the default RMMV battle system will never know when players will make what inputs in advance.
It means that all player inputs must be received in real time, meaning that the Action Input Phase must wait for such inputs and receives them immediately when players produce them.
Note that the raw inputs received are never which skill/item nor which target scope with its target is selected, but rather just a confirm key, cancel key, direction key, etc, combined with the current state, like which windows are active, which item is currently selected by the cursor, etc.
The real time processing part when receiving inputs is to turn data into information instantly - From raw key events to meaningful action contents.

On the other hand, as the default RMMV battle system is supposed to collect all player inputs before processing any, the number of player inputs available must be known in advance, otherwise the Action Input Phase could end up just waiting forever and the Action Execution Phase could never commence at all. That's why the number of action slots for each battler is always determined upon the start of the Action Input Phase.
However, on the battle system level, the whole battle flow still largely resembles batch processing, as inputs are still collected and processed as a batch.

It's just that the UI in the Action Input Phase needs to appear as running in real time in order to always ensure immediate feedback for all player inputs.
Produce Outputs As A Batch
Strictly speaking, it's possible for the default battle system to produce outputs in real time, if battle events are designed that way. However, that's rather an edge case.
Considering the output message queue as a batch of messages to be processed sequentially, it should be crystal clear and obvious that the Action Execution Phase uses batch processing.
What makes the Action Execution Phase special from ordinary batch processing is the following 4 cases:
1. It's possible for a message in the output message queue to become unable to be sent, due to, say, its sender becomes unavailable
2. It's possible for a message in the output message queue to be sent back to its sender or generate a reply, due to, say, magic reflection and counter attack
3. It's possible for the battle to end before when the output message queue still has messages, due to, say, all enemies become dead
4. It's possible for a message to be halted by its battle events that demands immediate attention from players
It means that some messages in the output message queue are dependent on each other, and some messages there depend on the global battle context to determine whether they'll be sent.

Also, some battle events, like displaying a text, are essentially interrupts, as they'll stop everything else and requires players to react accordingly before the Action Execution Phase can resume. Therefore, the Action Execution Phase must have an interrupt handler, even though it's not interrupt driven as it's still just a special case of batch processing.
Technically, at the start of the Battle Frame Update in the Action Execution Phase, it checks whether any battle event needs to be run. If there's any, that battle event will be run and everything else in the subsequent Battle Frame Updates will be stopped before it's done. Therefore that check functions like an interrupt handler.
(Loosely speaking, magic reflection and counter attack are also effectively interrupts, as they stop the original action execution and only let it resumes after the magic reflection/counter attack's completed.)
All these contrasts from ordinary batch processing, where most elements in the batch are independent of each other, and the processing just need them all to be present, thus not needing any interrupt to take place.

Mixing Paradigms
Event Driven
Recall that the Action Input Phase must wait for user inputs in order to collect a predefined number of messages to be sent.
This needs the Action Input Phase to request the game loop to constantly check if some specific keys are pressed in order to be always able to immediately detect user inputs.

However, such functionality actually has almost nothing to do with the default RMMV battle flow, as the latter just define what should be done when which events take place.
Therefore, it's much, much more desirable to leave those low level details to a low level module(Input in RMMV). The Action Input Phase should just map from an event to a function handling that event.
This design is completely aligned to event driven programming, as that function becomes an event handler.

The key behind such a setup is that, only the Action Input Phase has the 'what to do given what's inputted' part, and only the players have the 'when to input what' part.
It should be crystal clear and obvious that while these are 2 completely different responsibilities having completely different reasons to change, they need to collaborate together in order to achieve something meaningful in battle. Event driven programming bridges the gap using event handlers, while still not needing any side to know any implementation details of the other, thus preserving encapsulation.

All these mean that, attempting to thoroughly comprehend the Action Input Phase by trying to thoroughly comprehend how pressing a specific key can lead to a specific function being called is ineffective and inefficient to begin with, as the latter is completely beyond the scope of the former.
Instead, one should recognize the existence of event driven programming and identify the event handlers in the Action Input Phase, then trust that those event handlers will do the job well. It's because the reason to use event handlers is to delegate the timing from the Action Input Phase to a module that can detect just that, and delegation is based on trusting that module.

This further implies that, thoroughly comprehending the Action Input Phase implementation demands a thorough comprehension to its user level counterpart, as event driven programming is all about user inputs, and one must first know all the user inputs available in the Action Input Phase before being able to identify all their event handlers.
Procedural
Recall that Action Execution Phase executes the following tasks:
1. Combines all input message queues from all available senders into a single output message queue descendingly ordered by the message priorities.
2. Sends the 1st message that can be sent in that output message queue to all its recipients and removes that message from that queue.
3. Repeats 2 until the battle ends or all messages in the output message queue are sent.

While BattleManager still delegates many lower level tasks to lower level objects, like actions and battlers, when it comes to the battle flow, BattleManager is still in charge, by getting information from those lower level elements, like asking an action to be executed to inform its validity, and then making decisions on what to do with these lower level elements, like actually executing that action.
In short, while BattleManager itself isn't a real object in battle, it directly manipulates some real ones by deciding what they should do based on their current states, albeit not in ways violating information hiding.

Therefore, the Action Execution Phase is mainly procedural in spirit, as evident by the static class BattleManager, because of how the procedural mindset works:
1. A program consists of a sequence of codes to be executed one by one
2. Some sequence of codes are grouped into procedures to maintain the appropriate abstraction layer and promote code reuse
3. Procedures are typically algorithmic and composed in a temporal fashion - Codes are grouped into a procedure as they must always execute at the same time with the same ordering
4. Codes are to get information from data and make decision based on those information
5. The scope of reading codes are based on the starting and ending points of the execution, so reading a program tends to be done from the top to the bottom following the code execution paths
The corresponding practice when reading and writing procedural codes is functional decomposition.

So when reading the Action Execution Phase, one should first define the scope to be read. The following scopes are ordered with the highest level being the top:
1. How the codes execute from the start to the end of the Action Execution Phase
2. How the codes execute from starting executing the 1st action to ending executing the last action of an Action Execution Subject
3. How the codes execute from starting to ending executing an action
4. How the codes execute from starting to ending invoking an action to a target
5. How the codes execute from starting to ending a repeat in an action invocation to a target

One can start from top down or bottom up approach, or even their hybrid.
For instance, a top down approach can look like this:
1. The Action Execution Phase first order all the inputted messages descendingly by speed, then ask each sender to send all its messages until no sender's left or the battle's ended
2. Asking a sender to send all its messages involves first displaying a globally visible sending notification and then actually sending each message to its recipients
3. Sending a message to its recipients involves sending it to each recipient one by one
4. Sending a message to a recipients involves sending the inputted number of copies to that recipient
5. Sending a copy to a recipient involves first displaying a globally visible receiving notification and then actually deleting/replying/sending back the message or taking it as is
A bottom up approach can just look like the above with the opposite ordering.
A hybrid approach is usually used when an abstraction layer somewhere in the middle is especially difficulty to grasp.
For instance, if the 3rd layer is this case, then one can first grasp the 2nd and the 4th layer, then try to use them to grasp the 3rd layer, by grasping how the 2nd layer uses the 3rd layer and how the 4th layer is used by the 3rd layer.

Therefore, to thoroughly comprehend the default RMMV battle flow, one must first grasp both the event driven and procedural mindset.
Unfortunately, these 2 mindsets are very different from each other:
1. Event driven mindset is based on binding, delegations, handlers, while procedural mindset is based on algorithms,code execution paths and control flows
2. Event driven mindset is mainly about what to be done based on what events are detected, while procedural mindset is noticeably more imperative(and is very, very imperative in general)
3. Using procedural mindset to read event driven codes would demand lots of mental context switches - frequently jumping between 'what to do given what's inputted' part and 'when to input what' part
4. Using event driven mindset to read procedural codes would demand extreme care - arbitrary 'identifying' timing as events(like functions named by onXXX) when no such thing exists could end up with obscene misunderstandings

Summary
Using message passing to abstract out the default RMMV battle system(actually any Scene_Battle based battle system), a battler is both a message sender and receiver, and an action is a message with each target invocation being a copy.

Separation Of Inputs And Outputs

Action Input Phase is to completely fill all message slots(action slots) in the newly allocated input message queues of all available senders by letting players and AIs input available messages for all inputable ones and letting those uninputable but available(i.e., autobattle/confused) senders to input available messages themselves.
Next Command/Prior Command in the Action Input Phase is to transfer control from the an available message slot to another one.


Action Execution Phase executes the following tasks:
1. Combines all input message queues from all available senders into a single output message queue descendingly ordered by the message priorities.
2. Sends the 1st message that can be sent in that output message queue to all its recipients and removes that message from that queue.
3. Repeats 2 until the battle ends or all messages in the output message queue are sent.
Note that the action permutation, not just combination, is the key in forming the output message queue, as the order of actions to be executed is vital, due to the fact that even a slightly different ordering can already lead to drastically different results.
Also, in order to clearly illustrate the effects of the action permutation with potential counter attacks/magic reflections, each action invocation should be immediately followed by its action invocation presentation, and an application to each target for each repeat should also be immediately followed by its action effect presentation.

Batch Processing Nature
While players are always enforced to input from the 1st inputable action slot of the 1st inputable actor to the last inputable action slot of the last inputable actor, when to input the currently inputting action slot should be controlled by them, as the goal of the default RMMV battle system is to promote players to use strategic and tactical thinking to plan for an action permutation.
The real time processing part when receiving inputs is to turn data into information instantly - From raw key events to meaningful action contents.
However, on the battle system level, the whole battle flow still largely resembles batch processing, as inputs are still collected and processed as a batch.

It's just that the UI in the Action Input Phase needs to appear as running in real time in order to always ensure immediate feedback for all player inputs.

What makes the Action Execution Phase special from ordinary batch processing is the following 4 cases:
1. It's possible for a message in the output message queue to become unable to be sent, due to, say, its sender becomes unavailable
2. It's possible for a message in the output message queue to be sent back to its sender or generate a reply, due to, say, magic reflection and counter attack
3. It's possible for the battle to end before when the output message queue still has messages, due to, say, all enemies become dead
4. It's possible for a message to be halted by its battle events that demands immediate attention from players
It means that some messages in the output message queue are dependent on each other, and some messages there depend on the global battle context to determine whether they'll be sent.
All these contrasts from ordinary batch processing, where most elements in the batch are independent of each other, and the processing just need them all to be present, thus not needing any interrupt to take place.

Mixing Paradigms
Action Input Phase must wait for user inputs in order to collect a predefined number of messages to be sent.
The key behind such a setup is that, only the Action Input Phase has the 'what to do given what's inputted' part, and only the players have the 'when to input what' part.
Event driven programming bridges the gap using event handlers, while still not needing any side to know any implementation details of the other, thus preserving encapsulation.

While BattleManager still delegates many lower level tasks to lower level objects, like actions and battlers, when it comes to the battle flow, BattleManager is still in charge, by getting information from those lower level elements, like asking an action to be executed to inform its validity, and then making decisions on what to do with these lower level elements, like actually executing that action.
In short, while BattleManager itself isn't a real object in battle, it direct manipulates some real ones by deciding what they should do based on their current states, albeit not in ways violating information hiding.

Therefore, the Action Execution Phase is mainly procedural in spirit, as evident by the static class BattleManager, because of how the procedural mindset works:
1. A program consists of a sequence of codes to be executed one by one
2. Some sequence of codes are grouped into procedures to maintain the appropriate abstraction layer and promote code reuse
3. Procedures are typically algorithmic and composed in a temporal fashion - Codes are grouped into a procedure as they must always execute at the same time with the same ordering
4. Codes are to get information from data and make decision based on those information
5. The scope of reading codes are based on the starting and ending points of the execution, so reading a program tends to be done from the top to the bottom following the code execution paths
The corresponding practice when reading and writing procedural codes is functional decomposition.

Therefore, to thoroughly comprehend the default RMMV battle flow, one must first grasp both the event driven and procedural mindset.
 
Last edited:

DoubleX

Just a nameless weakling
Veteran
Joined
Jan 2, 2014
Messages
1,616
Reaction score
670
First Language
Chinese
Primarily Uses
N/A
@DoubleX is it possible to have the images uploaded elsewhere? Photobucket ruined it :(
It's done, and I've polished the post a bit.
While this post's incomplete, I'm afraid that I don't have the time nor energy to finish it(From V. Battle Flow Design onwards), so I guess I'll leave it like what it's now :)
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

ESAMarathon on Twitch, now streaming "Eat Girl". Yep, that's the title of a game... Apparently it's a Pacman knockoff.... Which is of course the only logical conclusion one would get from a name like "Eat Girl". :kaopride: I can't believe anybody would think anything else! :kaoback:
Super stoked i just finished my first town in my project, by finished i mean i can always add more decorative aesthetics and the NPCs don't talk yet but the mapping is complete and all the important chess pieces are present!
My brain: Hey, I have an idea how to make the transition to the main story quest in The Wastes more natural!
Me: Good!
My brain: You need to remake the hotel you start out in, it's not realistic enough.
Me: Ok... This was unexpected, but I can do it.
My brain: Now make each hotel floor 5 times as large to match the main part. Oh, you also need to make a bunch of new npcs to fill in the space on these maps.
Me: Crap.
Should be able to release Haxe MV/MZ next weekend.
It look that somehow MZ tracks are messed up (for example battle4 is obviously a theme, castle2 is a ship, ship1 is a scene and so on..). Maybe they just named them after with some ambiguity.

Forum statistics

Threads
100,608
Messages
977,791
Members
132,224
Latest member
nallovint
Top