All characters have attributes that are affected by events that occur during the encounter. The currently acting character’s portrait (expertly rendered) appears at the bottom of the screen. Their attributes with current and maximum values, appear in the upper left. Since battlers have different attributes, a given attack (debuff) or buff will have different effects on different battlers.
The Simple Buff skill, for example, uses the Help0 attribute of its user to add to the Mana of its recipient. But if the recipient has no Mana attribute, there is no effect.
Simple Buff and Simple Debuff appear repeatedly in the action list on the right side of the screen, as they are the first two actions implemented. They are assets, which can easily be created and modified. I made one in C++ and the other in Blueprints in order to get the process of adding an action as smooth as possible either way.
The majority of the game is spent in some encounter or another, so the systems should be flexible enough for the designers to be able to keep it engaging through the whole game. An ‘encounter’ is an asset that is created to design a battle, and consisting of several fields, including:
Which enemies may appear
How many of these enemies will appear, usually in the form of a range to pick a random number from for each available enemy
Any buffs or debuffs they might start with
Where the player characters and enemy characters start the battle
The characters controlled by the player are brought in to the encounter from some other context (usually some sort of exploration mode).
The battlers run on to the field and get in to position. They spawn at random points around the edge of the pitch and take their initial positions on the grid, one faction per side.
Since neither faction is taking a turn at the beginning, everyone starts out defending. A faction will be picked at random. The fastest member of that faction is up first, and then…
The first battler takes their turn. This is one of the many places where a simple concept must be broken down to be put into code. “Take a turn” must take in to account several possibilities, like status effects or environmental effects affecting the battler that activate at different parts of the turn (before, during, after), or actions that affect the normal flow of the turn, e.g. conferring extra actions or avoiding some of the aforementioned status effects.
To take a closer look let us use the debug view that focuses on a single battler.
A turn has several states:
0: Between: This is the state that precedes the battler’s turn. It is actually a state of the faction more rather than an individual.
1: Ready: The battler is the next to take an action. Here the player or AI would be making a decision.
2: Acting: The battler is taking the action decided up in the previous state.
3: Finished Turn: After the battler acts, there is space for the consequences of the action to unfold, as well as any thing that needs to happen after the battler has taken its turn, e.g. expiration of turn based buffs and debuffs.
Now we are again between battlers, and the process starts again for the next one.
The flow of an encounter goes from state to state per battler, battler to battler per faction, faction to faction per turn, and finally turn to turn. The debug text on the left keeps track of what is happening.
There are several static camera angles I used to help me debug movement and as steps to figure out some of the actual camera angles. There are also a few different layers of debug text which can be turned on and off.
In this update I added environmental actors tentatively called “idols”. They exist to alleviate a problem that has always bothered me in the genre; most battles outside of boss encounters feel very similar. There may be new abilities to use and be wary of as the game progresses, but since the mechanics are largely the same and the environmental changes are largely cosmetic over hours and hours of gameplay, there is a staleness that sets in. The idols are neither foes nor friends, but with careful planning and some luck, they can turn the tide of battle in your favor.
Adding the idols was straightforward thanks to battle system being designed with an open ended number of factions in mind. Another faction was added to the encounter object, the types of actor that appear in the faction were specified, and everything fell in to place. The idols take turns and move in a way slightly different from the members of other factions, but this was simple to incorporate into since the actors themselves are responsible acting and reporting their states.
The standard flow of an encounter is implemented but there is much, much more to do to make a polished battle experience, from beginning to end. Battler interacts, better camera angles, and an actual ending to the battle are just some of the next steps, but the first will likely be some more user facing UI. I expect that as the system develops, this will be useful in determining what is important for the player to know.