top of page
Technical Game Designer
Kenechukwu Umelo
Turn-Based Wrestling Brawl
Area of Focus: Systems Design & AI Programming
Time of Development: 1 Month
Goals:
-
Script a custom turn-based battle system inspired by Fate/Extra (PSP, 2010) with a wrestling spin.
-
Design AI utilizing a Utility AI system for decision-making during rounds.
-
Prototype an authentic wrestling game for mobile devices.
A solo-developed turn-based prototype in Unity in three months. The prototype draws heavy inspiration from the 2010 PSP game Fate/Extra, which featured a unique battle system that this prototype implements. For this project, I take that battle system and shift the design from fantasy to wrestling, completely overhauling the turn-based battle system to deliver a cool, authentic experience for players.
Custom Battle System:
The core loop of the game revolves around the custom-built battle system, where Rock, Paper, Scissors is played in 6-round intervals with clear actions of who wins each round. The player picks 6 decisions that will be weighted against the AI's decisions, and therefore execute a wrestling action sequence against each other. This gameplay focuses mainly on players predicting the AI's actions.
In Fate/Extra, there are three options: Attack, Break, or Guard.
In this prototype, the options are Strike, Reversals, or Grappling. I extended the battle system feature to include finishers and reversals.
Fate/Extra Battle System Gameplay
Early Gameplay of Battle System
The backend logic of the battle system runs on a Finite State Machine (FSM). Based on research, FSM is widely used in many turn-based games and their combat systems, as it makes it easier to manage turns and actions. I implemented one for this battle system, which features the following states: Begin, Decision, Clash, Yield, Draw, Pinning, and Ending. I named these to be easy for a developer to read, and each state has heavily scripted logic underneath, keeping the workflow easier to test and debug.
More Info on Finite State Machine
The FSM was built to ensure that the logic for how each sequence is executed remained separate but contributive. To ensure readability for players, I implemented a camera system that adjusts its angle based on the state to communicate changes in the battle system while maintaining the authenticity of the wrestling match on screen.
The FSM originally consisted of 6 states, excluding the Yield State. It was added because there were animation interference issues when they were executed and across other states (mainly between decision and clash states).
Begin
Clash
Pin
Decision
Draw
End
The Yield State doesn't have an action to see; it simply runs a decision evaluator system for the decision the AI and Player make during a round, and selects a winner based on the preset rules for actions that beat one another, like Rock, Paper, Scissors.
Decision Logic & Custom Inspector Tool
Since players had 7 actions to choose from, I scripted a quick decision system within the Yield State that easily handled the first three actions. Here's what it looked like:
Original Function for Evaluating Decisions
The initial setup worked for a while during early development, but once finisher and signature actions were added, the system proved non-scalable for supporting them in the long run, as each would have needed to be implemented manually. I needed a more automated direction for picking a winner, which required a whole new (and separate) script that can be referenced in the Battle System. Here is how I refactored it:
New Ruleset Script
This version allows designers to create rule sets in the inspector instead of hand-coding outcomes (basically, which action beats another action enum), then check what the AI and player picked, either executing the clash state with the winner selected or the draw state if the choices are the same.
I was initially satisfied with this system, but I wanted to push further by demonstrating its readability to others, including my hypothetical team. I turned this system into a custom editor inspector, which allowed me to view certain rule sets and test and debug them if any were incorrect or missing.
Utility Decision Making For AI:
During the early stages of development, the AI had its picks randomized and shown to the player for counterplay. Now, like Fate/Extra, some of the AI's decisions are hidden, leaving the player to predict and try to counter their actions.
My approach to designing a utility system for the AI's decisions was to dynamically update their choices using consideration curves for each available action. This basically allows them to consider things like health, player momentum, and whether they have required their signature or finisher actions.
For example: A player could have struck the AI three times, which allows the player momentum consideration to score high (0.7 - 0.9) on their grapple action utility. Or maybe when they finally activate their signature, which will score high on their signature consideration, will allow them to automatically trigger their signature.
Now this worked......too well. With these considerations taken into account in each round, the AI was either completely predictable or just action-spamming.
AI utility scoring with no randomness gameplay
To combat this, I added some randomization to the scoring to allow some unpredictability in their consideration scores. Making the decision improved the wrestling sequences and made the AI less predictable when the player is deciding what action to choose.
bottom of page