Phoenix Arena

Overview

Phoenix Arena is an Autobattling RPG Card game developed on the Cardano blockchain. Gameplay involves choosing one of three NFT Characters, equipping them with stat-increasing Gear, choosing the skills your hero will use, then analyzing your opponents’ hero to craft a strategy for victory.

As the player, it is your job to craft the strongest strategy using the tools and information given to you. The outcome of any match is entirely deterministic. It was a design challenge to create engaging and strategic gameplay without ANY randomness. Once both players have ‘locked-in’ their heroes, the heroes automatically cycle through the chosen skills. Once one hero is reduced to 0 HP, a victor is crowned.

Almost every facet of a hero can be upgraded, including Gear, skills, and even the players’ account itself. The core game loop involves playing the game, earning loot, & upgrading that loot.

My Role

Phoenix Arena as a company is a small studio with a total of nine members. With a team this size, it’s inevitable for many hats to be worn. Though my role was “Game Designer”, I also performed sound design, narrative design, marketing, QA, & UI/UX design tasks! Here is a curated list of some of the features and processes I worked on:

  • Design core game loop (See Fig. 1)

  • Create and maintain detailed, easy-to-navigate design documentation

  • Update pre-existing gameplay systems

  • Draft engaging and comedic flavor text to expand in-game world

  • Generate all sound effects in the base game

  • Develop multiple UI/UX mockups for various screens and features

  • Perform quality assurance duties including bug tests, regression testing, & validation

  • Draft & publish multiple marketing efforts through Twitter (X), and Discord

Key Takeaways

As this was my first professional game design experience, the amount I have learned is astronomical. As this was Phoenix Arena’s first foray into the game-making sphere, I had to run off-of instinct and best practices when completing tasks and designing the game.

  • Know your audience
    Phoenix Arena is a game developed for Web3 & Blockchain technology. I focused a lot on developing systems and mechanics that appealed to the genre of our game, but did not sufficiently consider the tangible incentives our initial clientele expected.

  • Project management is essential

    The importance of having a dedicated person acting as project manager to organize teams, communicate, and distribute tasks is an invaluable resource. Development productivity would be greatly improved with this role filled to act as a liaison between teams and to manage deliverables.

  • Take time for maintaining organization

    Piggybacking off the last point, it was incredibly beneficial to take a little time each day doing some house cleaning for files and documentation. Having maintained a consistent and organized workspace, especially remotely, is essential to a productive workflow.

  • Compromising is a blessing and a curse

    There were many times when we found happy middle-grounds with the game design that improved the overall product, however, knowing when to put my foot down for the betterment of the game and not cutting systems that dilute from the core experience is better than trying to fit them in with half-baked systems.

  • Shipping games is hard

    This speaks for itself. Actually releasing a game to the public is a severely underestimated task. I was fortunate enough to be wary of this process, but going into this step unprepared may spell disaster.

Overall, these takeaways are mostly pertaining to my learning and adapting to the professional game development pipeline. I was aware of many common pitfalls in the game design field, but I was truly surprised how true the lessons I learned in college were.

Fig 6. Visual breakdown of the “Polymorph” skill & accompanying animation in Phoenix Arena

Fig 7. Visual breakdown of the “Unholy Power” skill in Phoenix Arena

Rogue Class

The rogue class was one of the simplest archetypes to define. Traditionally, rogues are sneaky, stealthy, precision fighters that aim to dispatch foes quickly and quietly. I looked to leverage the already established “Vulnerable” condition automatically applied to heroes in the cooldown state to grant extra effects on rogue class cards. This was later shaped into the keyword “Exploit” which triggered additional effects of skills if they resolved their active state while the enemy was vulnerable.

The rogue class on its own granted heroes of the class an additional 10% damage increase to vulnerable enemies, and its subclasses just aimed to really double-down on that mechanic.

The two subclasses of the rogue, the Assassin, and the Hunter, were simply different takes on this exploiting vulnerabilities mechanic. The goal was to leverage the new feature of “Basic Attacks” (See: Basic Attacks) to gain additional effects when attacking vulnerable heroes. The assassin would gain “Rapid Strike” when using a basic attack against vulnerable enemies. This keyword causes basic attacks to strike twice instead of once. The hunter, by contrast, looked to play the long-game and their basic attacks against vulnerable enemies reduces that heroes’ stamina by 1. In brief, “stamina” (formerly fatigue) is a resource that heroes slowly diminish through the course of a battle. If a hero has insufficient stamina for the stamina cost of a skill, that skill is cancelled, and they are put into the cooldown state, which also means they’re vulnerable.

The rogue, assassin, and hunter turned out very well, truly embodying the archetypal rogue we all know and love.

Fig 8. Mechanical outline of the “Slice & Dice” skill in Phoenix Arena

Basic Attacks

A part of the antiquated design referred to “Basic Attacks” as a primary gameplay element. This design space had largely been unexplored in favor of skills being the sole way of dealing any damage. However, when developing the passive abilities and really pushing the bounds of our scope, we found some space for basic attacks to be added to the core game.

Basic attacks would work as 1 second low physical damage skills that could be augmented through various means. The “Rapid Strike” keyword is an example of a status effect that solely affects basic attacks and their applications. Basic attacks are placed between skills’ players select, causing them to be an ever-present part of a heroes’ kit. Of course, some adjustments to mechanics had to be made (See Fig 9.), but those changes led to a renaissance of new abilities and interesting design concepts.

Due to their 1-second resolution time, we toyed around with basic attacks being a component of skills and their resolutions. We were able to incorporate “basic attack” into many different skills, making them an essential part of almost every class & subclass’s strategy (See Fig 10.).

Fig 3. Stun behaviors during different states in Phoenix Arena

Fig 1. Initial Game Loop developed for Phoenix Arena (04 / 17 / 2023) (Not NDA)

The Design

The design of Phoenix Arena involves managing a unique set of variables to curate an engaging gameplay experience, without any direct gameplay actions. The actions players can take are through the lens of “skills” which use a traditional trading/collectible card game format to convey their mechanics.

Despite the frame of how skills appear, calling Phoenix Arena a “Card Game” is a misnomer. Amongst many others, traditionally, card games promote decision-making, adaptability, & resource management. These are all core attributes of CCG/TCG design that share a common bond, that being; Agency.

Phoenix Arena’s auto-battling gameplay inherently means that moment-to-moment agency is entirely ignored. It’s akin to playing a game of Poker with every players’ hand revealed. However, these restrictions breed new game design innovation that involve trying to create a card game that can functionally play itself.

Here’s my contribution:

Skill Design

To outline how skills work, I feel it pertinent to start from where I started. When I joined the team, skills had the following:

  • Names, Art, & Subclass affiliation

  • Basic mechanical descriptions with no defined values (“Moderate Damage”, “Speed Increased”)

  • “Energy Cost” values that were either 2, 4, and 6. These values correlated to both; how many skills a single hero can equip (a total of 10), and how long a skill takes to resolve

  • “Fatigue Cost” values that denote how much fatigue a skill afflicts to the hero when used

The high-level concept is that skills’ Energy Cost tied into how long a skill takes, in seconds, to resolve on the timeline. Each “round” is 10 seconds long, and skills are placed along this timeline with durations equal to their Energy Cost. Most of the other mechanics had been ideated, but not really fleshed out.

Immediately, I saw potential, and had a lot of problems to iron out. I developed a system of classifying skills into 3 states: “Charging”, “Active”, and “Cooldown” to allow us some room to toy around with HOW a skill behaves whilst on the timeline.

  • Charge state: The hero gathers energy to use the skill. If a disruption effect were used against a hero in this state, the skill is cancelled

  • Active state: The hero uses the effect described on the card. If a skill has multiple Active states, the description, as written, is repeated for each Active State

  • Cooldown state: The hero has to recover from using the ability. heroes in this state are considered Vulnerable and takes increased damage.

Using these attributes, I was able to create some skill archetypes to denote how skills can behave during resolution. There was some design space for Status Effects as well, which I immediately relegated to working on a separate layer from the resolution of skills so that the effects of some skills could be felt even when the skill itself isn’t resolving. (See Fig 2.)

Fig 4. Stun behaviors with variable durations in Phoenix Arena

Fig 5. Delay behaviors when applied in different states in Phoenix Arena

Fig 2. Skill Card archetypes for Phoenix Arena

The Disruption Problem

Due to the manner of how skills resolve on a strict timeline, it was important to define how skills would interact with each other when resolving at various points. Skills would resolve simultaneously, meaning that outlining exactly what would happen if effects may disrupt a skill needed to be very clear. I developed some charts defining a fair, but still impactful system for managing Stuns at different phases (See Fig 3.). In short;

  • Stunning a hero during the Charge state cancels the entire skill

  • Stunning a hero during the Active state cancels a number of seconds equal to the Stun

  • Stunning a hero during the Cooldown state does nothing and clips the Stun’s duration to either the remaining length of the skill or the duration of the Stun, whichever is shorter. (See Fig 4.)

Though a lot of work was placed into developing the underlying systems of skill cards and their behaviors, we found quickly through testing that stuns and disruptive effects were incredibly powerful and should be restricted for the sake of balance.

This did not stop us from toying around with alternative disruptive effects later on. I found the timing aspect of the game to be quite intriguing and felt that there was some interesting design space to explore with this element of gameplay. I liked the idea of stuns and disruption, hailing from a Magic: the Gathering background, but they were clearly too powerful without any counter-play in an auto-battler. In an effort to circumvent this lack of disruption, I developed the “Delay” mechanic that allowed the resolution of skills to be split or pushed back a number of seconds.

We still needed to consider what would happen at various states when delayed, but using the framework developed for stun, I was able to come to a happy middle-ground for delay. The strength of stun was the outright cancellation of a skill when applied at the right (or wrong if you’re on the receiving end) time. Skills that were cancelled still take up the entire duration of their resolution, but leave the target vulnerable for that duration. It really felt like we were rubbing salt in the wound. However, with delay, that happy middle-ground I spoke of allowed us to simply restart the skill if delayed in the charge state, and otherwise, just delays the resolution of any further effects when applied any other time (See Fig. 5).

Despite it being significantly less punishing, we found this to be a better feeling disruption mechanic that we hoped to employ on more skills as a balancing precaution.

Improving Skills

Now that the way skills would behave in game had been outlined, there were still a great number of design limitations I worked to dismantle. Over the course of development, we changed many aspects of skills’ initial mechanics to allow for greater design space.

Energy Cost

First, we tackled the arbitrary “Energy Cost” limitations. As was mentioned, we had an odd restriction on every skill that forced their energy cost to be either “2”, “4”, or “6”. This was initially selected as there could always be combinations that could reach the 10 energy cost requirement for a hero build. I quickly identified that this limitation would really hamper design space moving forward.

I proposed an alternative system that aimed to remove this energy cost requirement, allowing skills to have any energy cost above 2 (We decided to not allow 1 energy cost skills for balancing purposes). To address the 10 energy cost requirement, we implemented a 7 skill requirement for hero builds, where the heroes’ subclass would be determined by which subclass is most represented in the 7 skills. Then, when going into gameplay, players can choose 4 skills from that set of 7 to use in battle.

Additionally, the “10-second round” was removed, allowing for a much more dynamic gameplay flow. We realized quickly that if a player happened to choose a stun effect or was able to counteract the opponents’ build in the first round, that result would not change in subsequent rounds. Creating this staggered system led to much more dynamic gameplay and more unpredictable outcomes.

Unique Mechanics

It was abundantly clear that the limitations of a time-based resolution system would make designing interesting gameplay strategies quite difficult. Skills generally performed any number of the following three actions when resolving:

  • Deal damage

  • Apply a stat increase or stat reduction

  • Sets a status effect that helps yourself or hinders your opponent

The third point was something I found to be incredibly useful to design around. Applying status effects as various buffs, and debuffs made for an effective stand-in for perpetual effects, allowing for diverse mechanics to flourish. As all of these “unique” effects of skills generally applied as a buff or debuff, I found that leveraging that super-type of “buff” or “debuff” was an effective way to incorporate more complex mechanics.

This revelation expanded the complexity of skills and what they did during their active state. Fig 6. Is a visual breakdown of the “Polymorph” skill. This largely untouched skill from its initial design simply applied a unique status effect Polymorph, then finished resolving. You can see in Fig 7. & Fig 8. The increased complexity of skills gained through using these super-types and applied status effects to leverage and access additional benefits of skills.

Class & Subclass Archetypes

From the get-go, classes and subclasses have been a core element of the Phoenix Arena vision. I found that the classes were largely homogenous, using similar mechanics and attributes through all of them. I wanted to push the emphasis on meaningful choices through developing refined visions of the classes and subclasses.

I took a top-down approach when addressing this issue. Furthermore, I took inspiration from traditional fantasy representations of our classes. The skill development involved tying the fantasy of a skills’ name and creating mechanics that conveyed that aforementioned fantasy. All the while, maintaining an overarching direction guided by my initial analysis of the classes and subclasses. This redesign process took multiple iterations and added many new features to the game as a whole, improving the quality with each new development.

One of the most notable upgrades to the game was the addition of class & subclass passives. I felt that with our limited scope on stats and mechanics, that it would be difficult to create unique feeling mechanical identities with the 3 classes and 6 subclasses. To combat this issue, the advent of class & subclass passives worked to give each class a core play style. It was crucial that all skills of a class could be used by either one of their child subclasses. The “meaningful choices” pillar required us to allow players to make unique strategies with as many tools as possible. The goal with this system is to create a broad archetypal strategy with the class passive, and allow both subclasses to utilize the mechanics in different, but complimentary ways. Let’s dive into each class & subclass to see how this process worked.

Warrior Class

The warrior class was initially a relatively simple class that turned into a much more mechanically intricate play style. From the start, the warrior class had been the archetypal bruiser-class hero. High HP, strong attack values, moderate to strong defenses. To this point, we had only created proactive mechanics, and nothing to really allow for players to take a defensive play style. This is where I decided to create the “Fury” mechanic. Fury is a stacking buff that is added to warrior class heroes every time they take damage. The idea is that skills can may have a “Fury X” cost that triggered additional effects when the hero is above “X” fury. Along with this, warriors are able to heal a small amount of HP when they’re below 30% HP.

To establish the characteristics of the two subclasses, the Paladin & Barbarian, I went in different directions with how fury could be interpreted. One thing to note is, because fury is a permanent status effect, I needed to bake-in ways to remove fury from the hero relatively consistently. With those restrictions in place, here’s what I came up with:

Starting with the paladin, I felt a “divine” fury is one that is tempered and tries to turn the other cheek, only to unleash that pent-up rage in a massive strike. This led to the idea that the paladin was an immovable object, a concept that drove much of the design of the paladin archetype. Paladins gain fury every time they are hit, but also gain some armor and elemental resistance for each stack of fury they have. When a paladin reaches 8 or more fury, their next attack deals additional damage, scaling with the amount of fury they have, then all fury is removed and the cycle repeats. This mechanic captures the fantasy of a paladin’s divine smite obliterating their foes. The paladin turned out to be quite the powerful adversary, stacking defensive attributes then removing them to devastate their foes.

Moving to the barbarian, this is where the complexity set in. I wanted to promote an all-in, no-holds-barred aggressive play style. The “raging barbarian” is a classic trope and, to compliment the paladins’ “immovable object”, the barbarian would be the unstoppable force. To capture this concept, I opted to put a time limit on all fury stacks applied to the barbarian. In exchange, a barbarian gains a fury every time they hit a basic attack. With these concepts in tandem, barbarians want to hit and get hit as many times as possible while minimizing disruption to maintain that fury for more and more powerful effects. Though a challenge to implement, I feel that this turned out to be a landmark success for the class and makes it, to this day, one of the most mechanically unique subclasses in the game.

The warrior, paladin, and barbarian are all incredibly fun & engaging archetypes. With the fury mechanic, both subclasses are able to fulfil entirely different gameplay niches. I am incredibly proud of how they turned out.

Mage Class

The mage class was one of the tougher archetypes to establish. The subclasses of warlock & wizard are very broad archetypes with a lot to explore. Rogues and warriors use physical attacks and mages use elemental attacks, which already separated them from their contemporaries, but I felt that was not enough. Simply having a class that did the same thing as their “physical damage” counterpart felt a bit boring and didn’t contribute to the “meaningful choices” pillar I’ve referred to prior.

After a lot of contemplation, I felt that the nice the mage class could occupy would be the world of status effects. Applying them, strengthening them, any number of things. However, most status effects don’t behave exactly the same, so making an overarching mechanic that comprised of all the variations of status effects was necessary. Introducing “Hexes”! Hexes are applied whenever a mage-class hero applies a debuff status effect. For instance, if you would apply the aforementioned “Polymorph” debuff, 1 hex would also be applied. Using this concept as a springboard, with the advent of basic attacks, I gave mages an increase to their basic attacks scaling with their elemental damage attribute to somewhat even the playing field in this area.

Turning the page to the subclasses, I had to establish what type of wizard, and what type of warlock these subclasses would embody. With the myriad of fire and elemental skills already in the wizards’ kit, I figured that it would be fair for this wizard to be more akin to the “red mage”. High-damaging skills, potent status effects, and strong damage all around. In contrast, I wanted the warlock to convey the selfish mage, one obsessed with power and watching their opponents crumble beneath them. With those attributes out of the way, here is what I developed.

The wizard subclass increases the damage of status effects and skills, scaling with the number of hexes an opponent has. I felt that this simple increase to the damage of the wizard allowed the elemental damage attribute to really have a dedicated wielder. It is a check for anyone skimping on elemental resistance stats making them a very deadly class.

The warlock subclass doesn’t augment the damage of status effects, rather, extends the duration of these effects scaled with the number of hexes applied to the opponent. If a damage-over-time status effect was applied for 3 seconds, with 2 hexes applied, the warlock would extend it to 4 seconds. Notably, this effect also works for buff status effects, allowing the warlock to become an unstoppable caster if left to their own devices for too long.

The mage, wizard, and warlock all used an established part of our game system to augment their play styles. They don’t differ as much as the warrior class, but still have very different play styles in-game.

Programs: Unity, Audacity, GitHub, Asana, Google Suite

Fig 9. How basic attacks interact with stuns/disruptions in Phoenix Arena

Fig 10. How basic attacks are implemented in other skills Phoenix Arena