Square Off

Shipped On

Team Size

Role

Creator

Duration

June 2022 - Sept 2022

Square Off was a personal project I began during my first semester at DigiPen where I built a local-multiplayer arena combat game that tried to balance the competitive tension of arena combat with the casual nature of party games.

This game was my first solo published game on Steam (as Early Access)

This project was in active development for over 4 months

I designed all the systems in this game (combat, user interfact, user experience)

I was responsible for the entire implementation of the game (writing the code, creating the art etc.)

I conducted over 45 playtests with more than 100 First Time Users

I will be continuing development on this project as part of Early Access

If you want to hear the full story - read on!

Preproduction

Where a question was asked

The Question

Square Off was an attempt to use design to answer a question: "How can I make players find enjoyment from loss?". Loss is an occurrence in life which is unavoidable and does not feel good, especially in competitive settings. For this reason, finding meaning or fulfillment from loss is particularly important across all of our experiences, including games. To begin exploring this question, I researched existing game titles to figure out how other designers made loss feel good.

A 2-player arena game, ROUNDS, player loss is balanced by providing tailwinds (benefits) to the losing player by providing a selection of randomized powerups. This, coupled with the quick round transitions and chaotic gameplay, made losing almost feel good.

ROUNDS Gameplay

Another arena party game, Boomerangfu, leverages a cute art style with quick game rounds (due to high player lethality) to make player deaths feel silly and cute while reducing the down-time after dying. Losing is never dwelled on for long.

apps.16475.14217927423059510.eac0d219-b30c-4063-879f-17d087c77c3c.jpg

Boomerangfu Gameplay

Looking at other Player versus Player (PvP) games like ROUNDS and Boomerangfu, I saw a trend of how tension from loss was reduced:

Loss was brief.
Losses empowered players.
Loss was humorous.

Moving forward from my preliminary research, I was ready to begin the design of a game that would further explore how to make loss fun, or at least not awful.

The Core Idea

From the various party games I saw during my research, I was inspired to make a party game of my own. Luckily I had been maintaining a design journal which was steadily populating with game ideas, and Square Off stood out.

A page from my design journal, where the idea for Square Off (right page) was first created.

The main premise of this game idea was that it was a party game where movement was driven by rotating the character. The appeal of this idea was its uniqueness, but I first wanted to critically examine the idea before putting time into building it in-engine. By leveraging design documentation I had crafted myself, I tried to forecast if the systems in this game could be engaging enough to become a cohesive experience for players

TellMeAboutYourGame

WhatKindsOfFun

GiveMeWhatIWant

TellMeAboutYourGame

1/4

A preliminary systems analysis on Square Off

At this point, I was confident that there was indeed a game in this idea, and all that was left to do was to build a prototype to get feedback from players.

The Tech Demo

I began rapidly building a tech demo in Unity that aligned with the design outlined in my design documentation. I programmed the gameplay in C# following object oriented programming principles I learned from my first year at DigiPen. I refrained from adding extraneous visual polish and used out-of-the-box Unity visual systems such as the Animator and Particle Systems to create a tech demo that accurately represented the core gameplay I wanted to test.

The first iteration of the Square Off prototype

I improved on the tech demo after hosting some internal playtests with designers and others who were accessible to me. It was clear that before I put this in front of more players, I had to update it to properly examine the following areas:

Which abilities did players find the most engaging?
How difficult was rotational movement and ability use for players?
How quickly could players start engaging with gameplay without being confused?

The Prototype

I made updates to my game according to the data I collected during my internal playtests:

I added ability pickups so players could choose their own abilities.
I added UI for ability-use so players could see their abilities and how they mapped to the controls.
I added a player join menu that forced players to engage with character movement controls to "Ready Up".

I now had a prototype that was ready for local playtests (with strangers).

The updated prototype after internal playtesting

I hosted 5 local playtest sessions (10 players) and recorded notes to obtain behavioral and attitudinal data to inform my next design steps moving into production. Each session was conducted virtually and included:

Introduction (provide context for the session)
Play session (take notes and observe)
Conclusion (take questions from players)
Analysis (re-organize and examine data)

The Playtest Results

There were many insights gleaned from this initial playtest that both supported the viability of Square Off as a promising game idea while also pointing out areas of improvement that I could carry into production.

Things that went well:

No player asked to prematurely end the playtest
All players understood how the basic controls worked within 1-2 minutes of playing
1-2 times during a single match players would make playful comments

Areas of improvement

100% of players thought the game took too long to begin
90% of players felt the controls felt unresponsive
90% of players did not know what abilities were on which side of their character
80% of players determined that inaction was the best strategy
90% of players chose the same abilities repeatedly
80% of player deaths were due to the environment (rather than player interactions)
50% of available abilities were completely ignored

In addition to these I also heard various player suggestions for improvements:

New ability ideas (shields, close-range, etc)
New mechanics (evasive dash, level hazards etc.)
System adjustments (hitbox sizing, move speed, jump speed etc.)

The playtest results were motivating and insightful, and I was excited to leverage this data to improve upon the various aspects of Square Off that needed to be leveled up!

Production

Where a game was built

Data Driven Priorities

I created my deliverables for production based on the playtest data I collected. I prioritized these deliverables in the same order of when they would be experienced in the game. In general, my list of deliverables could be summarized:

Improvement 1: Speed up game navigation.
Improvement 2: Increase player movement responsiveness, specifically around jumping.
Improvement 3: Reduce player confusion concerning player UI.
Improvement 4: Create a balanced set of player abilities.

I maintained a production schedule to keep myself on track, using a more sophisticated Gantt Chart from a previous project to visualize my progress.

An excerpt from my production schedule for Square Off

With priorities and a schedule, it was time to improve my prototype!

Improvement #1: Game Navigation +

As I critically analyzed feedback from players, it was clear that I needed to reduce the time between the bootup of the game and the start of actual play.

In the prototype, I had players make their customizations by pressing in-world buttons with their character avatar. They would then need to jump into a box to "Ready Up". Once all players were in their respective boxes, the game would move them to the play scene.

Square Off Prototype Ready Up Screen

Problem: Navigating from the start menu to a match is taking too long.

Solution: Replace the in-world customization system with a non-diegetic UI customization system.

Square Off Updated Customization Screen

Justification: Using a UI based approach to customization, players could "Ready Up" as fast as they could handle their controller. Additionally, if I decided to add more customizations, making changes to the UI would be as simple as adding more UI buttons and resizing icons.

I prevented accidental "Ready-Ups" by having players hold a button down as well as having a countdown.

Although players would have the final say on this system during later playtests, I felt ready to work on the next improvements.

Improvement #2: Player Movement +

One of the biggest interaction problems I observed in the prototype playtests was that players would often opt to not engage the other player if it required jumping, bringing the gameplay to a halt. The controls for the player were very "floaty" so jumping in the air made the player an easy target. In particular I saw this behavior happen most frequently when the players were at different elevations.

Player holding the high ground forces a stalemate.

Problem: Player high ground is unbalanced due to "floaty" player movement, making jumping a risky move.

Solution: Improve the responsiveness of the player controls to give players more control over their direction and movement. Increase player gravity to make the control feel less floaty and make a jumping player less of an easy target.

Player movement update (Jump Cut and Airborne Movement)

Justification: Having a jump cut allows the player to have a variable jump height, making it harder to anticipate the trajectory of a player's jump. Airborne movement also allows a player to take evasive action when jumping. Both of these reduce the risk of jumping by making it harder to hit an airborne player.

Improvement #3: Player UI +

Another important improvement moving forward from the prototype was an improvement in the user experience (UX), specifically the visual clarity of the user interface. In the prototype, I had decided to put all the player-related information (HP, cooldowns) on the player's avatar. Players found that this crowded their player avatar while also being difficult to see because of size. In addition to this, players had difficulty determining which ability was on which part of their character.

UI crowding around player avatar

Problem: Player HP bar and ability UI is crowded around the player, making it difficult to track key information such as which way is up or which abilities are attached on which part of the character.

Solution: Create a dedicated UI at the bottom of the screen for abilities, cooldowns, and player health, while double coding essential information on the avatar such as ability directions, cooldowns, and health.

Avatar/UI double coding demonstration

Justification: By splitting information between a dedicated UI area and on the avatar, new players can learn the ropes of the game by referencing the dedicated UI to get a feel for mechanics such as ability cooldowns and health where as veteran players can focus on their avatar. Although the UI did take up real estate on the screen, the levels did not feel cramped when I did development tests with 4 players.

Improvement #4: Player Abilities +

One of the last major improvements before my next playtest was updating the roster of basic abilities to meet some objectives:

Abilities need to be meaningfully distinct: They should change the way the player engage with the game.
Abilities need to be balanced: No ability should be ignored, as this reduces the variety in the game.
Abilities need to be accessible: They should be "dangerous enough" in the hands of any player, regardless of skill

In my prototype, although there were 6 distinct abilities, players quickly realized that only 3 of the 6 abilities were relevant to getting a victory, ignoring the rest. Even worse, the abilities required a high level of precision, which was frustrating for lower skill players.

Prototype Player Abilities:

Bouncer: Shoot a bouncing ball that deals damage and knocks player back
Rocket: Shoot a delayed rocket that travels in a straight line and picks up speed
Jetpack: Propel player in direction of player side, release many small projectiles in the opposite direction
Boost: Charges up, allowing player to travel great distances on release
Teleport: Immediately moves player a small distance, creating two bombs on either side of the player on teleporting
Railgun: Charges a laser that fire the full length of the map, dealing high damage and high knockback

Problem: Abilities are extremely skill dependent, difficult to use, and unbalanced.

Solution: Create an evaluation framework to allow for balancing new abilities before implementing them. Test implemented abilities against their evaluated values through frequent development tests.

Ability evaluation for two starting abilities

Justification: Using a framework that established desired ability trait scores based on characteristics relevant to the interactions between players, I could create abilities to fill particular niches:

Far: Effectiveness at interacting with players at range.

Close: Effectiveness at interacting with players in close quarters.

Corners: Effectiveness at engaging players who are not in line-of-sight.

Area: Effectiveness at covering real estate in the map.

Reliability: Effectiveness at placing or aiming the ability where intended.

Utility: Effectiveness at providing benefits asides from damaging the enemy player.

Damage: Effectiveness at reducing the health of enemy on successful interaction.

In the example above, I created two starting abilities using this framework: "Fireball" and "Ricochet". Both abilities were meant to be balanced while being meaningfully distinct.

Fireball was an ability that fired a projectile that slightly homed in on the nearest player, exploding on impact.
Ricochet was an ability that fired a projectile that bounced multiple times, homing on the player on each bounce.

I ran multiple development playtests to evaluate the design of player abilities using my framework. Both abilities reached a point where I felt comfortable officially playtesting them.

Playtesting The Improvements

By improving upon my original design over multiple iterations I was ready to shift my focus back to playtesting to evaluate my improvements and determine my next deliverables for Square Off.

Luckily for me, I was invited by my school to attend Geek Extravaganza where I could set my game up and conduct external playtests to evaluate and validate my design! I was able to get a diverse array of people to play my game, including multiple 4 player sessions. This was incredibly insightful and a lot of fun seeing players engage with Square Off.

Two playtesters playing Square Off at Geek Extravaganza

I structured my playtests like so:

Debrief players on the playtest structure
2 - 4 players would start the game and play a match (5 rounds)
During each round I would collect data (abilities used, points scored, round duration etc.)
At the end of the match I would ask 3 questions
- What did you enjoy?
- What improvements would you like to see?
- What suggestions do you have?
Take questions from playtesters

My high-level analysis of the playtest results were:

Players wanted to see more variety, specifically abilities and map layouts
The score disparity was large in 2 player games. High skill players won every time.
Score disparities between players was less in 3 & 4 player games. High skill players won most of the time.

Armed with new data and a working base-level game experience, I was ready to tackle new concerns for Square Off!

Reducing The Score Disparity

Before creating new content, I prioritized core gameplay issues, specifically the large score disparity between low and high skill players. I observed low skill players "check out" or stop trying once they realized they could not compete with a high skill player. This was especially common if players could not manage to score any points during a game. This issue tied directly with the original question I wanted to answer with this game project:

How can I make players find enjoyment from loss?

Using the data and player comments from my previous playtests, I had some constraints that I would have to address when creating my new loss mechanic:

The new mechanic should help the losing player without adding complexity to their controls
The new mechanic should not limit the winning player in any way
The new mechanic should leverage existing schemas or heuristics that players use to play the game

A complete shutout during a match in Square Off

Creating An Underdog Mechanic

To reduce the score disparity between low and high skill players, I built an "underdog system" that applied a random powerup to the player in last place (the underdog) at the beginning of each new round:

Powerups were not permanent, they were only for that round (to prevent exploitation)
Powerups scaled in strength based on how far behind the losing player was (to scale player support based on need)
Powerups were passive, the player did not have to activate them by pressing any new buttons (to keep it simple)

I based each "underdog mechanic" on behaviors I observed in low-skill players:

Spin To Win: Player deals damage near them as they move (low skill players had a tendency of charging their enemy)
Ground Fighter: Player takes reduced damage as long as they are grounded (low skill players jumped less frequently)
Retaliation: Player sends out projectiles when they are hit (low skill players were hit more frequently)
Rapid Fire Rage: Player's cooldowns are reduced as their health goes down (low skill players tended to button mash)

Underdog mechanic demonstration

Answering The Question

After multiple months of iterating on Square Off, I had to circle back to whether or not I accomplished what I had set out to do at the beginning of this project.

Did players enjoy losing when playing Square Off?

I conducted numerous First Time Users Experience (FTUE) playtests to determine if I did address this core question:

I invited strangers to play Square Off in a coffee shop
I hosted virtual playtests virtually with entire families with kids ranging from 9 years old to 22 years old)
I playtested the game with friends and family in my own home

A playtest session I ran in a local coffee shop!

The data I collected across 19 playtests could be summarized with the following highlights:

Across 5 4-player games, 4 3-player games, and 10 2-player games, there were 0 shutouts (all players scored some points)
0 players stopped playing the game out of frustration during any of the playtests
18 of the 19 playtest sessions had all players request to play multiple matches (the playtest only required 1)
100% of the players said they enjoyed the game and would play it again if it had more content

I recorded player criticisms of Square Off to carry forward in later development:

65% of players did not fully understand all the game controls until after the third match
85% of players did look at the player UI at the bottom of the screen
One ability (the Damage Stacker) was not understood by 95% of players

Another Game, Shipped

With my school semester approaching, I decided to ship my game on Steam as Early Access. It was received well during my playtests and by putting it up on Steam I could gather more data on how to improve it when I had more time to work on it.

Although Square Off certainly wasn't quite where I wanted it to be, especially considering the criticisms of the game from the last set of playtests, I realized that no game project is over complete, only shipped.

The benefits of shipping this game and gathering data from a wide array of players who did not know me personally was far better for the improvement of Square Off than if I had to keep working on it in private.

Square Off on Steam!

Reflection

Where I look back

Lessons Learned

Square Off was my most ambitious project to date. Because I was wholly responsible for every aspect of the project, I grew a lot over the course of months that it took me to build this project. I was both proud of what I had accomplished but also am reflective on how I might approach a larger project differently in the future.

The important takeaways from Square Off were:

I love shipping games. I didn't realize how much pride I would take in following through with making an idea that was in my design journal end up being a real game on a legitimate games marketplace. I eagerly wait the next window of time where I can take another idea and make it real.

Ask for help. During my time at DigiPen I have had a luxury of meeting many folks who I often would ask for advice whether it was for how to ask proper playtesting questions while minimizing the tester's bias, or how to build a tech system to dynamically add variables to players during runtime. I definitely felt out of my element due to the wide array of tasks I had to complete in order to ship Square Off on my own, but I often overcame those obstacles by asking for help when I needed it (and even sometimes when I didn't).

Experimentation is built off of a foundation. I started this project trying to explore how to make players enjoy loss, but admittedly I spent the majority of my time simply just trying to get the core gameplay to be engaging enough to be worth playing. It was only when the base systems and design of Square Off could support that player engagement, was I able to begin experimenting with systems that dealt with loss (such as my powerup system). For my next project, I will focus on making the game work before I try to make it "fun".

Set S.M.A.R.T. goals. Specific. Measurable. Achievable. Relevant. Time-bound. Whether I was trying to scope out a new ability, powerup, stage, or artwork; I would not have reached my goal of pushing my game on Steam by the end of my summer break if I did not set constraints. It's too easy to get lost theory-crafting the what-ifs, especially when designing. Luckily I kept myself on track with my long-term schedule and broke the large task of "build the game" into smaller milestones that were easier for me to keep track of. I grew a lot in terms of keeping myself accountable by working on this project.

Square Off on Steam!