This lesson explains how the combat system’s design evolved during its pre-production to help you get a sense of how I put the questions in the previous lesson in practice.
We’re going to answer:
All that starting with a constraint: we’re building a combat system inspired by Japanese RPGs.
Note that this lesson isn’t about how you are going to implement the JRPG combat demo while following this tutorial series. Instead, it describes the thought process I followed creating the demo in the first place, starting from scratch.
Here, I’m describing a method to design games with a starting constraint, fitting into a genre. That’s why, in this case, I recommend to start with the audience. If you’re creating something experimental or for an artistic purpose, you can reverse the process. Start with a toy or prototype.
Starting with the previous lessons’ questions, I built the demo with people who like Japanese RPGs in mind. Without any demographic data, I first looked at what made those games unique and how the genre evolved.
Traditionally, Role-Playing Games from Japan, as opposed to Western ones, had some of the following characteristics:
That’s a few traits at a glance and by no means meant as an in-depth look at the genre. Working as a designer, I try not to focus on what other games do to avoid copying them unwillingly. As mentioned in the previous lesson, you want some originality in your projects. To me, that can’t happen only by playing games. You get inspiration from other crafts and life experiences. A game like A Short Hike, where you climb a mountain and get to feel like exploring tracks off the beaten tracks, is a good example.
But if I were on a contract to produce a JRPG game, I would keep the above ideas in mind to make the players perceive our project.
We’re creating a turn-based combat system here, but there are many ways to approach the gameplay. You can go with strict turns or have time moving forward. You also want to give strategic options to players.
To guide decisions on that, I write some keywords and intentions regarding the player’s experience. To do so, I try to visualize the game with my mind’s eyes. A notebook handy, I let my imagination run for a moment, often walking around. When something particularly exciting or frustrating happens, I pause and scribble down some words.
We’re talking about the first hour of a project when you’re figuring out where to start.
For this project, for instance, in my thoughts, the combat actions would chain quickly. The exercise led to a battle system where time flows nonstop but slows on the player’s turn. Time keeps moving on even when characters and enemies attack. A powerful attack with a long animation delays that character’s next turn, but two characters can also act simultaneously. To assess whether that’s good or not, you’d need to test it thoroughly, which gave me a roadmap for the first prototype.
Each character has energy points that charge at one per turn. You don’t have to manage a mana-like resource that you regenerate with items. On their turn, they can use actions that cost zero or more energy. The more energy an action cost, the more powerful it is, although not necessarily in terms of damage. Powerful healing and support skills, attacks that inflict status effects, many actions with a tactical benefit require having enough energy.
With a few gameplay ideas in mind, I break them down into broad tasks. The project was straightforward to me, as it fit within a well-defined genre. The combat system only brings a little twist to something that already exists out there. Performance isn’t a problem or consideration for a 2D RPG, so you don’t need benchmarking prototypes.
I moved into code with two prototypes in mind, that I would implement one after the other:
The first prototype was an opportunity to test the implementation of the turn system, and to test different ways to manage time.
After implementing it, I liked the feel of time continually flowing and characters acting at the same time.
Creating and iterating over the first, then the second prototype allowed me to figure out the game’s design and how it should play. You can test the demo’s design directly by opening the finished Godot project.
Let’s start with the basics. There are several characters and monsters on the board, called battlers. Two parties oppose each other, using various attacks to reduce the opponents’ health down to zero.
When all members in the player’s party have no health left, the player loses. If it’s all monsters that get wiped out, the player wins the battle.
A turn bar at the top of the screen shows each battler’s position on a timeline. Battlers progressively move forward and, when one reaches the end on the right, they can take an action.
During a player-controlled battler’s turn, a menu opens and allows the player to select an action and a target.
Time slows down, but it doesn’t stop. If the player waits for too long, they give enemies time to progress towards their turn and attack. This presses the player not to wait for too long before making a decision.
On the right side of the screen, you can see the player battler’s Heads-Up Display. It shows each battler’s name, health bar, and energy points. It allows the player to monitor each character’s status and, along with the turn bar, plan their next move.
The energy goes up one point at the start of each battler’s turn. Then, the battlers’ actions have different energy costs, from zero to several points, and the costlier ones tend to inflict more damage or have powerful effects than the cheap ones.
If the player wants to use their most potent action, they’ll have to use weak attacks for several turns and plan several turns in advance. This also gives enemies more time and opportunities to attack.
That’s the general design and features of the demo you’ll get to code in this series.
In the next lesson, we’ll talk about the final demo’s code structure so you can get a sense of how we’ll implement it.
