Turn-based RPG
joshxpainter.wixsite.com/insignia
2015-2017
OBJECTIVE
I've always been curious of what it takes to make a mobile game. After hearing countless success stories regarding the explosion of the mobile industry and how individual developers could create entire games that succeed in a free-to-play market, it naturally attracts my attention.
With this project in particular, I wanted to apply my knowledge of systems design, and see where my strengths and weaknesses lie. I've made countless different 'systems' before, and most of them are chopped together rather quickly for solo projects and prototypes; I wanted to create something scale-able. A system architecture that gave the player a ridiculous amount of customization while designing in the forethought of being able to extend content of the game later.
I began with a simple singular objective: recreate the equipment/animation architecture that allows a 2D animated character to act as a 3D RPG character, i.e. equip 100's of different armor pieces, weapons, particles, etc. despite using hand-drawn 2D assets.
INSIGHT
I knew of a perfect example of a title that had already accomplished what I wanted to do, nearly 14 years ago - Maplestory. I loved this game as a kid and even picked it up 3-4 times over the years just to reminisce and see what was new.
As I laid things out, I found a couple of interesting quirks that came with the territory of designing these systems. The first nugget I stumbled upon was a 'mannequin' system. I like to think of each sectional region of the character that has various Z-depth needs to be treated as a separate entity. This means that torso would be separate from the arms, separate from the legs, separate from the helmet, so on and so forth.
Each individual piece of the 'mannequin' had its own animator and each animator had a specific setup that coordinates the animation sequence perfectly with the other pieces. Getting this to work required a lot of coordination from both art assets and code.
Equipment Customization
I quickly ran into another predicament of armor customization that forced to me rework a lot of truths I had assumed beforehand: what if a player equips an armor piece that reveals their character in some way? What if they wanted "hide helmet" functionality commonly found in many RPGs?
This question made me rethink how much customization freedom I was really giving the player. This meant now that skin color, facial expressions, eye shape, hair style, an everything under the kitchen sink had the possibility of being part of the mannequin system.
All of these had to be synced up and animated in unison.
I took a deeper look at how Maplestory appears to players at a surface level. If you wear a magical hat that "hides your helmet", then your character's head will show, facial expressions and everything. So I reconsidered the human skeleton underneath the armor mannequin. I needed to essentially animate a base character model behind the armor, and reveal it only when necessary.
I did this by adding a simple boolean to equipment that let's my system check for revealing the human extension part that corresponds to that equipment piece. Now I could check when the player equips something, should a part of their humanoid body be revealed and animated with the rest of the mannequin?
Player Character - Head Visible
Player Character - Head Not Visible
COMBAT
Designing the combat for this game required a moderate amount of research of popular turn based games. While this wasn't my first attempt at creating a 'Pokemon-like combat system'. I initially wanted to make something more complicated than Pokemon's child friendly typing system. But after careful evaluation, I began to find the underlying complexities that make Pokemon as tactical as it is at higher levels of play. The game has become gruelingly complex in its algorithms and special case evaluation since the days of Red and Blue versions. Even the original games had a fairly strong logic sequence to evaluate turn order, exception predicates, and status effects. The trickling of information and what-if cases calls for a well thought-out and all encompassing design.
So, where do we start?
I chose to begin with a lookup tool that allows any component to access all given information of any ability in the game. Each ability is an instance of a class that contains all applicable information regarding the ability. This means that my logic, as well as animators, audio components, etc. can use information that is all organized in a singular 'vault' of archived data. I can also use all of this information to evaluate the state of combat as the game plays out.
Now that I knew what I was working with, I needed a logical ordering to handle the combat state.
What does the player want from this experience? Should the combat be entirely fair? Should the enemies resolve abilities the same way the player does? Who gets to go first? Does the player have abilities that enemies don't and vice versa?
Stats & Abilities
Finalized Ability Animation
Concept Ability Prototype
I chose to use a system that promotes player stat management and tactical evaluation. While this is a turn-based RPG, it's a mobile game where the combat should be simple at some points and ramp up in difficulty at others. I wanted an experience that offers a rewarding challenge for overcoming a fight via application of game knowledge for Hard Mode. For a more casual experience, Easy Mode should use stats and logic to give the player an advantage.
I chose the following stats to represent a character's feats in combat:
Power, Defense, Speed, and Prowess
Power defines your desire to deal big damage with both Strikes and Abilities.
Defense is your resilience in combat defining how well your character can take a hit or avoid status conditions.
Speed increases your dodge chance and gives move priority when attacking.
Prowess makes you an efficient killer on the battlefield, increasing your execution threshold and damage on specific Abilities/Strikes.
I wanted to minimize the number of stats a player must evaluate to keep the game relatively simple. I feel that these 4 stats help differentiate core characteristics of play-styles that my 4 classes would specialize in.
Knights - Focus in balancing Attack, Defense, Speed, and Prowess
Occultist - Focus on Attack and Prowess to deal heavy damage at the cost of being vulnerable
Cutthroat - Focus on Prowess and Speed making them slippery and lethal
Guardian - Focus on Defense and Attack allowing them to take a beating while dishing them out
Architecture
Dialogue System
While working on the dialogue system, I ran into a familiar friend/foe: a need for a queued action system. I had to create a seamless cutscene system that would run a large amount of actions in sequence while being capable of being skipped. Skipping cutscenes or dialogue in a video game is vital to those of us who just want to get on with the gameplay. This means that some form of input must interrupt the train that is an action sequence at any given moment.
I began with a fully-fledged action queue system that would be able to make function calls based on the callback completion of a previous action or function call. This is an extremely flexible system I had in mind (as I've had to put this system together in C++ for a previous game), but it was a bit much for what I needed. All I really needed was something tailored specifically to all possible actions in a cutscene, rather than all possible actions ever. This lead me to trying a different approach.
Using sets of dialogue contained within several strings of arrays that defined the speaker, their image source file name, and of course what they wanted to say or think via a text box.
I feed this information through a "script database" that contains every line of every cutscene within the game. There I can specify who's speaking and what actions they're performing in tandem with their words. This all gets translated into a larger "script" that my typewriter effect writes out to the HUD.
"But how do I skip?!"
I began with a simple SKIP button that was revealed upon tapping the screen. After some testing, the feedback I got told me this wouldn't work. Having actions and UI trying to work together became a problem, and I had to rework the system to better fit the player's expected use.
I then moved to two separate queue systems. One queue to control actions and characters, and one queue to control UI and dialogue.
I could now have the 2 queues communicate, while also being able to fast forward them. Now my actions would always sync with the dialogue, and skipping was not a problem, because each queued action awaits player input to continue.
Now the player can tap the screen to force the text to print out quickly, and tap again to move onto the next line of dialogue.
A dialogue handler is called whenever input is detected. It analyzes the state of the dialogue system and decides what action to take next.
_gif.gif)