Roles:
Gameplay Designer, Programmer, Sound Designer, Artist
(February 2024)
(Please note that all assets are subject to change.)
[MONOCOOK] is a multiplayer RPG prototype that uses Active Time Battle (ATB) combat mechanics. The game's main hook players can join and leave turn based combat at any time.
OVERVIEW
-
4 Player Active Time Battle (ATB) RPG
-
Made with Unreal Engine 5 (Blueprint)
-
Players and Enemies can jump in and out of Combat at any time
-
Prototyped in about 1 year
MY CONTRIBUTION
PROBLEM: How to make jumping in an out of combat?
Having never programmed an RPG from scratch, this project was quite the challenge, especially since
it's multiplayer. To make this demo work, I had to solve a few big problems.
The design intent is for combat to be joinable and leaveable at all times. From what I understand, moving players in a multiplayer game to sub-rooms is a tricky endeavor. So to circumnavigate that, we simply just made combat scenes far away and teleported players to them over a transition. This allows us to hold multiple combat rooms as their own separate object. From there, each room handles it's own ATB combat in real time.
While this does mean each player is simulating all combat at all times, even if they aren't in the room,
the unpredictable behavior of joining and leaving combat would leave most other options with some
considerable drawbacks having to both spawn and despawn assets. Thanks to Unreal's robust replication system, the syncing of network objects wasn't too much to handle either.
PROBLEM: How to make collaborative cooking accessible?
The cooking system involves players joining a shared rest area and offering ingredients to make a collaborative dish. With the groundwork laid out in combat, rest areas are not that different in execution. The cooking system is a whole different sequence, but at a high level, it's its own room too. After that, cooking a dish is as simple as looking up valid recicpes in a table.
PROBLEM: How to make a workable Ability System?
Being the only programmer on the team meant I had to have a way for the ability system to be workable and modular for all designers who wanted to balance the game. In most turn-based RPGs, a table of abilities would suffice, being that attack animation and damage values are the only real variables.
In an ATB system, the timing of each ability matters. If a player were to leave mid-attack from an enemy, they might actually have a chance to dodge the damage. So when the actual damage calculation occurs really matters.
(The Timeline triggers the events in any order the designer chooses.)
Due to their lighter overhead, we chose Widget Blueprints to act as our ability arbitrator. Being that they have animation timelines and event graphs built in, this means:
-
Abilities can be fully customizable, so long as you can call an event, the ability can run any arbitrary code a designer wants. Customizable animations? Special edge case checks? An attack that has overworld repercussions? All can be handled through simple event firing.
-
All abilities are split up into separate objects. While it is a higher overhead than a table, this allows for multiple developers to work on separate abilities simultaneously without version control collision and/or lockout issues.
-
Abilities are separate from their baseline statistics. While impractical sounding on the surface, this means that multiple abilities can reuse other attacks without recursive issues. For example, if an attack was meant to hit 4 times, firing the damage calculation from a table lookup 4 times is a lot simpler then having to make an edge case where certain abilities can fire multiple times.
Dubbed the Ability Timeline, they are created and attached to host player during combat and handle their own timing of their ability, working closely with the combat rooms themselves. To pair down confusion, the actual calculation of an ability (who it targets, whether is heal/damage/status change, etc.) is called an Effect and is simply a struct instead.
Due to the modularity, abilities come in all shapes in sizes. In this example, a "Key" Item ability simply checks if it's targeting a door. If so, it deals a huge amount of damage to it, killing the door "enemy" quickly. To the player, you're simply unlocking the door.