The Crowley Zone

Genre: Turn-based role-playing game (RPG)

Software used: Unity

Role: Programmer

​

When first tasked to work on the combat system of Trials & Triumphs, we at first didn't know exactly what kind of game we would be making. We wanted to make an RPG, but that can mean just about anything in regards to how it would actually play. Things were moving slowly, so I took the initiative and tried to create a turn-based active time battle (ATB) system, inspired by classic Japanese RPGs like Chrono Trigger and Final Fantasy IX. Why this style? I'm a fan of the genre as a whole, but that style has always been my favorite. Making this system was to help guide my teammates in seeing if this was a system we wanted. If it was, we would then be able to try and modify that base system to make it one to call our own. If it wasn't what we wanted, we would at least use this to find out what is actually wanted.

Before this, I had not worked on an RPG of any kind. While I've played many (many) games in the genre, I hadn't really considered how to program such a battle system. There are many variables and components to consider, after all. How many stat types would a character have? How are damage values calculated? How do some stats affect other stats? Are there temporary stat buffs, or ways that alter damage formulas? Does an attack hit one enemy or many? Does it hit once or multiple times? Does the attack make the user move to the target? What can you target with it? These are just a handful of things to consider with the basic forms of RPG systems. Adding the ATB system adds even more to that list of questions.

So when starting out, I thought about the basic components. What occurs exactly? Each character, enemies included, has a stamina meter of sorts that fills up over time. When their bar is filled, the character may perform an action. When an action is selected, it gets added to an action queue that tries to empty itself. If character A is in the middle of performing their action and you select an action for character B, B's action will not be performed until A's action has finished. If an action is selected for character C while A's action has not ended and B's action has been queued, C's action will not be performed until after B's has finished. In a nutshell, that's how an ATB basically works. At that point, I had my task. Now, how to program that?

I decided on a system that uses three main managers: The player party manager, the enemy party manager, and the action manager. The player party manager tracks which units are controlled by the player, if they're all alive, experience gained from defeated enemies, and most importantly, sends actions to the action manager, among a handful of other things. The enemy party manager, like the player party manager, also tracks which units are enemies and if they're alive, and also decides on their actions for when each enemy unit can act and sends them to the action manager. The action manager consists of an array (a list would probably be better for this) that takes actions in, and continuously tries to empty itself in the order which actions were added to it. When an action has started, the list (and possibly the ATB stamina meters -- we decided that it does stop the meters, but I prefer not for faster gameplay) would pause until the current action has ended. When an action ends, their stamina meter is set back to 0% and starts to build up once again. Here is an example of an action, which is a standard attack.

A side thing to mention is that while the system itself is important, what's also important is the player being able to select what options they have available. Using what those classic JRPGs used as a base as well, when a character can act, they have a selection of different basic options: attacking, using a special ability, using an item, defending until their next turn, and running away. When the player selects an option that targets a specific unit, there should be a UI element that then allows the player to pick their target. The player may also choose to back out and pick a different action if they change their mind. If the player chooses to use a special ability, a list of abilities that character can do should be displayed. If the character has more abilities than there are display options, it will scroll down as the player moves down their ability list. This is done by having a display offset. Normally only 5 options can be displayed, so when first opened, the ability selection menu will show abilities 1 through 5. If a character has 7 abilities, moving down from option 4 to option 5 will increase the display offset by 1, instead of moving the cursor down. The player will then see abilities 2 through 6, but the cursor will still stay on option 4, making it look like it has moved to ability 5. At that point, if the player tries to move up to option 1 (ability 2) from option 2 (ability 3), the offset will decrease, so that abilities 1 through 5 will be displayed again. If abilities 2 through 6 are shown and the player attempts to go down from option 4 to 5, of course, abilities 3 through 7 are then displayed. At that point though, because there are no more abilities to show, pressing down from option 4 (ability 6) will move the cursor down to option 5 (ability 7), and not change the offset, as doing so would then display an 8th ability that this character does not have. Moving down from option 5 at that point will bring the cursor to option 1 and set the offset back to 0, thus bringing the player back to abilities 1 through 5. Likewise, pressing up from option 1 automatically sets the offset to the maximum it can be for that character, and moves the cursor to option 5. You can view the code for the standard selection window here, and the code for the ability selection window here.

With the way the ATB system is designed, some units might build their stamina meter quickly, while others slowly. After showing the initial builds to the group, someone had thought of a way to possibly overclock the stamina meters, or possibly use them as an additional resource for actions. A character might have an ability that increases the speed at which their meter builds, or one that slows the meter for enemies. Perhaps a character can slow their own meter, but gain increased power on their next three actions. Shortly after I began to implement this overdrive system was when the project lead had decided that the game would go in a different direction unfortunately. While it was hard to let my old code go, working on this had prepared me for the system that the game would end up using.

​

When I have more time (and money) available, this is something I would like to revisit. Or at the very least, use as a base for a new project.