designing Strike Back - 15 minute read
Strike Back is a 1v1 fighting game developed as part of GAM 200/250 at DigiPen Institute of Technology. I served as the vision holder and lead game designer on the project. The project was a really unique learning experience both in elevating my design but scripting prowess as well. I thought I'd dive more into its rich design background and methodologies used at the time to give some insight on how I designed elements of the game.
initial ideation + GAM 200/250
Strike Back was originally birthed from a conversation I had between myself and our lead programmer, Steffen Simmons. We were both big fighting game players. Steffen was a seasoned Dragon Ball FighterZ modder at the time and myself, a recent top 129th finalist at Tekken 7 at EVO 2022. At the time on extended weekends, we would go to the GameWorks in downtown Seattle to play Street Fighter III: Third Strike.
The GAM 200 course was coming up for us this semester and we asked ourselves a question:
"Is it possible to make a competent fighting game at DigiPen?"
If you're a DigiPen alumni reading this - you'll know exactly what I mean. For those not in the loop, students at DigiPen go through multiple project courses (at least did at the time of my attendance) known as "GAM". These courses are development pressure cookers where students effectively go through the entire development cycle for a game in about 5-10 months - amid other classes/life obligations they have. While the courses last 5-10 months, the distilled development duration is more like 3-6 months.
GAM 200 is the first interdisciplinary course students take where they meet/collaborate with other programmers, artists, sound-folk, and designers. Added kicker - all GAM 200 projects must be done in a custom engine built by the team's programmers. Said engine is developed from scratch for the first 5 months of development with actual game building occurring in the latter 5 months.
Understandably, Professors overseeing GAM are extremely strict about the scope in which these games are made. Every game made in GAM 200 goes through a pitch process where ultimately if you fail, your team is automatically disbanded.
design step - pitch
Given the context that either our pitch is approved or we effectively disband, I got to work initially developing the core ideas of the game during ideation. This involved doing some research. Fundamentally our development needs - some would even say pillars - were the following:
1. Development Ease
We needed whatever this game will be to be relatively achievable to develop within the scope of GAM 200/250. This meant core systems needed to be kept at the bare minimum for a fighting game with as few features needed from a technical perspective. For instance, if a whole engine feature for strikes were implemented - it wouldn't be developmentally sound to suddenly have grappling be a key part of gameplay.
2. Unique Approaches
The game and even its development needed to incorporate "uniqueness". This means really stretching development capabilities to its logical limits at the moment. Smart asset/code reuse, intelligent genre divergences, etc. Fighting Games are legendary for their asset reuse and development "shortcuts" to create unique experiences - we wanted to tap into that!
To gather some insights, I reached out to my network of fighting game peers and dug through my steam library to look at other fighting games I might have not touched as much. My goal was to really extract exactly what I needed in a fighting game to make it "competent". I wanted to see what other lesser-known fighting games did but also what their players thought were things that weren't necessary. The initial research insight I would receive be essential to molding the final gameplay of Strike Back.
The biggest takeaways from this period of insight was:
1. Every fighting game has its own unique philosophy about player/character movement.
2. Sprite reuse is largely uncontroversial.
3. Motion inputs weren't necessarily a must.
4. Outside of direct gameplay, most avid fighting game players don't care for other modes.
After, I proceeded to ideate and brainstorm on a document what the proposed systems for this etheral design for a GAM 200 fighting game might be. Usually, my process involves just writing a whole list of ideas/concepts/themes into a large, messy whiteboard/document. The point at this stage of design isn't necessarily to critique design but rather just have a wealth of ideas and concepts to pull from.
Once a larger document was compiled, I'd sit down with Steffen and do a "design shedding". Removing ideas/concepts that wouldn't be technically feasible or involve too much of a commitment. This is where critique comes into play. Through a couple hours, we'd really narrow down and focus what the idea of the game would really be.
Ultimately, we developed 3 really core features of Strike Back's design from our ideation phase that really shaped what the game would become.
1. No Universal Jumps/Dashes
2. No Fireballs/Projectiles
3. No Hit Levels (Highs/Mids/Lows)
To prototype these concepts, I rapidly put together a really simple prototype in Unity. It was more to prove that the game doesn't feel absolutely awful with these systemic ideas we wanted to try out.
Using this prototype, we conducted some rudimentary, casual playtests. We'd place the game in front of people and see if they have any immediate, gut reactions. Overall, it seemed players didn't have any issues - it wasn't much of a game but it didn't seem out the gate our takeaways from ideation were awful.
With our prototype, pitch deck, and playtests in hand, we'd go off and do our pitch!
Our game got approved! - Under one condition: We had to build effectively the whole gameplay loop in Unity in two weeks. This meant UI, damage, rounds, etc.
Thankfully I did it in 1 week - all through Unity C#!
design step - characters
Jumping forward a little - I want to show my design process in making characters. I got to design and touch almost every element of Strike Back so if I actually wrote everything I did and the processes it would basically be a novel. Though I wanted to give a glimpse into how something cool like characters were designed. Picking up - we got a lot of our base systems down. It's a 2D 1v1 fighting game with no universal jumping/dashes, no fireballs/projectiles, and no hit levels. The tech team was starting to develop the engine with a lot of these core-based system assumptions in mind.
Now comes the part everybody dreams about - character design!
Fighting games at their core live and die off their characters. Many flawed fighting game systems in the past has been saved by their unique character designs and gameplay. Characters are king!
Though, given the unique nature of our game and how limited we were a big design question was - "How do you design a character for this game?". Our game proposed unique challenges due to its base systems. Characters in Strike Back don't really and can't really function like any other fighting game character. How do you make a "Ryu" character when your game doesn't explicitly have a fireball - an action so ubiquitous with 2D fighting games?
I didn't really know what it was called at the time but In this process of developing characters - I really was a big proponent and user of Lean UX principles. Funny, since it was primarily done to inform how we design character movelists instead of UX.
So let me talk about designing our first character - Kenjiro and how he came to be!
Kenjiro initially was a test character developed during the prototyping phase to be basically our "dummy".
It was a little doodle from one of our artists and given he was in the prototype and people didn't seem to mind him, it didn't seem to crazy of an idea to add him as our game's first character.
A big part of the initial research and ideation into developing Kenjiro was selling "flavor". I'm a huge proponent that flavor is king in video games. Though I also wanted to inform my design decisions with key testing to ensure my designs are always user-centric. Informed ideation and testing were essential here.
So I actually did research on what other games really have as their first "staple" characters. Characters like Ryu from Street Fighter, Jin from Tekken, and Terry from Fatal Fury. My takeaway from those insights were that a good starting character is a character that effectively fulfills a "control" archetype.
I observed control characters tend to be built around simple, yet effective actions that aren't necessarily used to instantly create pressure in play - but rather develop reactionary gameplans that tests your opponent's reactions to situations.
These weren't characters that gave you +6 on block out of nowhere - they instead just have strong, safe low minus to low plus actions that force you to play around ambiguity.
Transitioning to ideation I wanted to have Kenjiro fit that same archetype in a flavorful way. I wanted his gameplay and presentation/theme to really sync up with this new idea of "control". So I did exploratory research, writing down characters, themes, and archetypes that really lean into selling that idea that Kenjiro was this "controlling" character. A character that is designed to systematically break down and finish his opponents. However I wanted this concept to be digestable and be grounded in things we know in real life. I didn't want Kenjiro to be some random ethereal magical character that controlled opponent using some random martial art. The flavor needed to blend.
I was stumped on this for a while so I went to the gym.
At the time, I was obsessed with kickboxing and Muay Thai - I still am. I had done BJJ for about a year at that point and just recently dipped my toes into striking.
It was during sparring that it kind of dawned on me. At my gym, we had some really technical strikers. Every single jab you threw, every single checked kick, every single little movement you made felt like it was being recorded. All to eventually have you get hit with a perfect counter.
Then a spark of inspiration - "what if Kenjiro was just a really technical kickboxer?" A kickboxer focused on eliciting reactions and punishing with a devastating counter-hit! I felt that was a flavor missing from his kit - so I began prototyping!
By this point, our engine was in a state where we could actually begin editing and developing characters through the engine's proprietary "FighterData" scripts. These were designer-facing scripts usable to completely make whole new characters from scratch.
Taking the time, I developed Kenjiro's initial movelist - a couple of basic strikes founded on principles I understood personally as a competitive fighting game player. This meant solid, long pokes, ambiguous frames, and rewarding counter hits.
The second the movelist was done, I immedately began testing!
By this point, we had actually standardized playtesting - ensuring that our results were grounded in generally good UR practices.
I began arranging and going around doing live gameplay tests. I'd have two players play against each other using Kenjiro's movelist and ask flavor perception questions. Things like what they felt like playing Kenjiro, what they thought Kenjiro's fighting style was, etc.
By the end, the feedback was generally positive. Though some did lament that Kenjiro's damage was too high and that some of his pokes felt too powerful.
Taking the information, I iterated! I adjusted Kenjiro's damage and lowered his poke's tip ranges. An additional value tuned was pushback! Something observed not mentioned but impacted the sentiment of pokes being too powerful was that it had considerably pushback on block. After these adjustments I'd test again in an iterative cycle. It was difficult at times to adjust things like attack ranges because we didn't actually have a live hitbox viewer at the time. We'd have to manually spawn in a separate sprite/entity that vaguely represented the attack's hitbox to see how big or small a hitbox/hurtbox was.
This whole process repeated multiple times. With each iteration smoothening out Kenjiro's kit into its final version. All the while tapping into lean UX design principles by using ample user feedback to create multiple versions of things to perform A/B testing! By the end, Kenjiro transformed from an emporhic idea to a fully realized character!
Reflection
In a lot of ways - Strike Back was the dream game I got the privilege to work on while at DigiPen. In retrospect, it's a game that shouldn't exist within the context of which it was developed. A fighting game made in the GAM 200/250 course was unheard of. It's also a highly discouraged genre at DigiPen. A bunch of scrappy sophomores building an engine from scratch, designing, scripting, iterating, and publishing a functional fighting game? Horror story in the making.
Fortunately, through a mixture of spite and passion, we miraculously saw it through. This project took a once-in-a-lifetime level of effort and luck but its teachings have been profound to me.
what went right?
Combat Feel: A primary goal for Strike Back was to nail the feeling of it being a fighting game. Everything from how the characters control across a range of peripherals to how hitstop scales per individual attack - I was obsessed with getting the combat feel just right. Testing, analyzing, tweaking - repeat. That was the heart and soul of Strike Back's punchy combat feel.
Difficulty: A goal I wanted to focus on that we nailed was game difficulty. Throughout development, I hammered in the unorthodox statement "1 minute, big brain". This embodied the spirit of the game's perspective on difficulty and accessibility. My firm belief was after a minute of play - players should feel like they have enough understanding and control of the game to achieve those sticky "big brain" moments in gameplay. A big pool of our testers were explicitly players who have never played fighting games in the past - we wanted to hone whatever design "fat" needed to be trimmed. This resulted in a smooth FTU (First Time User) onboarding and kept our design decisions lean. All juice no filler.
Minimum Viable Product: A careful tightrope Strike Back had to balance was achieving that minimum viable product. I focused greatly on the core features that made the game engaging. Prototyping for Strike Back was done by the end of the 1st week of production with iteration hitting the ground and running from there. Even from early prototype testing, it was clear - Strike Back's simple yet engaging combat had legs. By sticking to that I delivered on the core combat experience before expanding onto new content.
what could have gone better?
Characterization: While Strike Back does have some minor characterization between its two characters - it's mostly told in little info snippets or their expression in animation. In retrospect, I think a point of improvement was having more ways to give more "character" to our playable characters. Cool voicelines, bios, etc. From a flavor perspective, fighting games live and die based on their characters and I think I could have been more keen on fleshing our characters out in style, narrative, and expression.
what went wrong?
Camera: Creating a good fighting game camera is incredibly challenging. There are so many little touches and careful considerations that go into making a good fighting game camera and I think we missed the mark in Strike Back in that regard. The early prototype I made had simple camera behaviors that fit the needs at the time. It just zoomed in and out based on the player's proximity to each other and for the most part it "worked". Though, it wasn't something I was personally satisfied with. During development, I tried iterating on the camera to be more dynamic: adding action shot zoom-ins, gradual zoom, etc. Despite multiple iterations, we had to settle on a slightly improved basic camera. Deadlines were coming up fast and the team was juggling working with a freshly-crafted custom engine. Between camera or dedicating more time to getting the combat just right - it felt like to me at the time it made more sense to hammer down on combat. I had to ultimately settle on a version of the camera that I felt like wasn't quite up to par.
cool little takeaway
They don't care about the jab, they care about the haymaker!
A design lesson learned from Strike Back was the concept of players latching onto big explosive actions vs smaller, technical actions. Even when the smaller, technical option is optimal. Great example is one of our characters, Sunny. She's Strike Back's boxing representation and our informal mascot!
Given my background in combat sports, there's one thing every striker on Earth understands - the jab is king. It's fast. It's low risk. It's versatile. I wanted to emulate that in my original design with Sunny. Sunny was designed with 4 attacks. A jab, a stationary straight, an uppercut, and a forward advancing straight.
Originally a huge part of Sunny's kit was emphasized on the jab. She's a boxer, a boxer's staple punch is their jab - so I design her entire kit around the power of her jab. However, in actual testing, her jab was one of the least used. Most players instead used almost entirely the forward advancing straight and the uppercut. The answer was simple, both those moves are just flashy and cool.
While an average joe might not know what a straight or jab is, everyone know what an uppercut is. In pop-culture it's the "knockout" punch. While an average joe might not find a straight that interesting, when it goes across the screen and does a chunk of damage like Balrog's Straight Rush from Street Fighter, then you have people turning heads.
Taking my learning from this, I flipped a lot of Sunny's movelist on its head - for the better. I leaned into the "feels-fun" attacks, tapping into key feedback than imposing my Sauron-esque design will of jabs being the best thing the character does. This lesson helped inform my design process on other future movelists and designs. It was an early, yet profound design finding I still think of whenever I design and iterate.