Strider Toll

Technical Game Designer

Hi! Thanks for stopping by. I’m Strider, a game designer and developer with over 3 years of professional experience, specializing in combat systems and player abilities.I focus on making kinetic, visceral, and artistic games.

• LinkedIn
• Email
• Document

The beating heart of Bewitched is the possession system, which allows players to leave the body of Elith, and take control of any enemy in a given scene. As the project’s signature mechanic, we knew that it needed to feel great to use, and it took a lot of work to reach the version we shipped with.Initially, possession was a manually aimed raycast, which was frustrating to use and pulled away from the fast-paced combat we wanted for the game. Players would generally possess one enemy, and stay in that form as long as possible.

Throughout development, we found that aiming possession had to become more and more forgiving. It was moved to a cone, and eventually a circular field that interpreted player intent through the left stick, ensuring that the player would capture an enemy even if their aim was imprecise. When paired with a mechanic that had the player dodge backward when leaving an enemy, players began capturing and leaving enemies multiple times over the course of combat.Over the course of many iterations, possession went from an awkward ability to a key part of combat that the player could rely on, and feel clever for using.

Reina was the first completely original character that was created for Rushdown Revolt. An early challenge we faced was how to make her combo game interesting while in her chain whip stance. When faced with this issue during initial design discussions, I pitched a solution where close hitboxes along the length of the chain knock opponents outward, whereas tipper chain hits send in. This design resulted in a character that reinforces movement even when at range, as players try to position themselves into an ideal spacing for each move in a combo.As I implemented the VFX for Reina, I made sure that these ranges and hitboxes were clearly communicated to the players. By using a combination of dynamic weapon trails and bespoke effects from our artists, I was able to clearly separate the base hitboxes from the tipper hits.

The ledge system was one of many pieces of design the game inherited from existing platform fighters. Initially, if a player recovering to the stage reached the edge while another player was hanging there, the recovering player would not be able grab it, and would often fall to their death. This micro-interaction played an enormous role in edgeguarding, often serving as a life-ending checkmate move.From a balance perspective, this worked fairly well, as it favored the offensive player. However, this led to anticlimactic situations where the offensive player would stop trying to attack, and would just grab the ledge, which was antithetical to the electric spirit of the game.

To address this, I pitched a solution where the recovering player would simply flip onto the stage in an inactionable state, giving the offensive player an opportunity to land an attack.This maintains the advantage state of the offensive player, but only if they continue to follow-up after the ledge flip, reinforcing the core appeal of moving and attacking. Additionally, this change gives the recovering player another chance at life, depending on their opponent’s follow-up.While ledge-flipping is a fairly small interaction, it has a huge influence in the outcome of offstage play. Because of this change, we were able to have every stock go out with a bang instead of a whimper.

A key aspect of the game was the ability for the players to move between the ship and asteroid fields, each of which needed its own field of gravity that pulled in its own direction.To achieve this, gravity direction information is stored within a trigger collider attached to each asteroid or platforming surface that needs gravity. Both rectangular and circular gravity fields exist within the game, pulling the player towards the bottom and center of respectively. If the player is inside of multiple gravity fields, they use the gravity and orientation of whichever one they’re closest to the ground of. This way, forces do not stack, and players only need to keep track of one field at a time, which reduces the mental load for a casual game that already gives players a lot to keep track of.Additionally, if a player touches the ground surface connected to a different gravity field, their character snaps to the new surface. This allows players to move smoothly between asteroids without hiccups.Initially, the player needed to hold their movement input in the same direction the character would move in world space. This required players to constantly adjust their input to keep the character moving, which was very unintuitive, especially on keyboard. To address this problem, the game stores an initial movement direction relative to the player controller, and keeps the player moving in that direction as long as any movement input is held. The final result is a character that players can understand immediately on their first playthrough.Traversing around asteroids was able to become one of the most fun and interesting aspects of the game. In the end, the system allowed players to smoothly and intuitively move between different surfaces and gravity fields.

The inspiration for the game initially came from Balatro. There, I really appreciated the way that Jokers acted as tangible objects that took up space within the game world. Their activation order is a meaningful decision for the player, and old upgrades must be discarded to make room for new ones.I started looking for ways to apply these points of interaction and decision to a new genre and set of supporting mechanics.The idea that excited me the most was slotting upgrades inside of a revolver. In the same way that Jokers ping off each other in order during scoring, a player could cycle bullets in a cylinder. Bullet choice and execution order could open up new and interesting strategies that I hadn’t seen in shooters up to this point, while providing plenty of room for build creation and roguelike power scaling.

I quickly built out the concept as a top-down prototype a few weeks before the start of the project to prove out the idea in a playable and readable form. To demonstrate the mechanic, I created a rotating UI component with a simple set of colored bullets with very visually distinct custom behaviors.The initial prototype for Revolunar essentially served as a playable previs for the revolver system, but with code that was scalable enough to remain into the final release. The prototype demonstrated the core mechanic clearly enough to get rest of the team excited about the idea as the project began development.

We had an abundance of bullet ideas, many of which were prototyped to find what was fun, and build out our toolbox of behavior scripts. However, we could not afford to spend time implementing, balancing, and creating art for bullets that did not fit within the larger whole and support distinct play patterns. We needed a filter to decide what belonged in the game.To solve this, I visually mapped out the gameplay scenarios facing the player, and connected every Bullet we had written with a situation they addressed, or another Bullet they paired well with. Any bullet that could not justify its place in this ecosystem was cut. This, along with aggressive tuning to push the differences between Bullets, resulted in a rich, cohesive set of tools that created a unique experience with each run.

One problem that we needed to solve was a lack of understanding around what each bullet did. In early versions of the game, players started with an array of several completely random bullets, which overloaded them with information.We employed several techniques to get players comfortable with their ever-changing arsenal. First, we slowed the rate at which players gain new bullets. Players now started out with 3 basic hitscan attacks, and one random Bullet from the larger pool. This allowed them to learn how one new tool worked with the support of a reliable baseline. We also implemented a bullet select screen, which gave players active control over their build direction, as well as a calm moment to read the Bullet descriptions.

COMMON Bullets were meant to be a reliable set of tools that players familiar with the 90s shooters would already be familiar with, allowing them to focus on our new and unfamiliar systems. These required very little custom tooling, so we could focus on making them distinct and fun to use.

UNCOMMON Bullets were primarily designed as pieces to pair with other Bullets, creating combos and suggesting new Bullets to take. In-chamber effects, or Bullets that applied modifiers to later Bullets, were an especially successful design pattern that we utilized here with Mother Flame and Blank.

RARE Bullets were reserved for out most powerful and experimental effects. These tended to require the most mental consideration from players, interacting with exterior systems like health. Hiker is a particular favorite here, flipping loadout strategy on its head by stacking damage at the end of the chamber.