Opti Games - Gameplay Designer
Job Overview
At Opti Games I work as a contract game designer working on Sparkball, a 4v4 WASD MOBA. Sparkball is a blend of the MOBA genre with ability based characters and Rocket League ball play mechanics. Teams fight to score goals by disabling enemy towers and killing enemy characters.
I started my contract working on their challenge modes, but I've now moved into a gameplay design focused role working on characters and core systems.
Some of my job is to…
Level Design/Game Modes
Designing Levels for New Players
The first thing I was tasked to work on at Opti was game modes. When I joined Opti had two game modes, one called Dodgebomb and one called Target practice. The modes were exactly what they sound like — one a bullet-hell esc experience and the other a way to practice your aim.
My first task was identifying areas of improvement. The Target Practice was somewhat easy to document changes for and figure out next steps. The mode was intentionally simple as it is effectively onboarding. Dodgebomb, however, was more challenging. The mode didn't have a clear identity or goals. Was it a bullet hell or was it something else? Why do players attack at all, what's the current best strategy, etc.
Dodgebomb - Blowing up a Confused Game mode
When I inherited Dodgebomb, it was effectively a bullet-hell game mode. However, my playtests revealed it was too barebones and lacked a clear identity. There were a few obvious problems with one overarching point: Dodgebomb lacked synergy with Sparkball’s core systems.
Survival Focus: The objective was simply to avoid danger, rather than engage with Sparkball fundamentals like ball play and scoring. Staying mounted was more effective than fighting.
Agnostic to Character Choice: Abilities, stats, and unique movement options offered little advantage, reducing the value of player choice.
No Skill Transfer: The mode failed to teach or reinforce mechanics relevant to standard matches—goal barriers, terrain use, power-ups, and ball possession.
With these issues in mind, it became clear that small tweaks wouldn’t be enough. I wrote a design doc (linked here) proposing larger structural changes, but with roughly a month to update and ship the mode—and limited team size and resources—I ultimately recommended we pull the mode rather than force it out. In my view, it’s better to delay a feature until it can meet quality standards than release something that doesn’t support the game’s core systems, especially for a mode intended as an onboarding experience.
Retrospective: This work taught me the importance of recognizing when to step back. Sometimes the most valuable design decision isn’t what to add, but knowing when a mode needs more time and resources to succeed.
Dodgebomb Gameplay Example
Target Practice - Understanding Complexity
Target Practice started from a stronger foundation than Dodgebomb. Its purpose was clear: train players on Sparkball’s core mechanics while offering a minor challenge. But the first iteration didn’t go far enough—it lacked depth and felt more like a tutorial checklist than a true mode.
My director’s feedback was to make the mode more complex and challenging, with the expectation that players should fail their first 3–4 attempts before mastering it. With that in mind, I set out to iterate in three key areas:
1. Improved UX
The original UX often left players confused, skipping objectives or backtracking unnecessarily—unacceptable for an onboarding experience. To fix this:
I added progress barriers that prevented advancement until objectives were completed.
I reworked the UI to better communicate objectives, ensuring clarity at every step.
2. Realistic Challenge
Static targets weren’t representative of actual gameplay. To better mirror Sparkball’s flow, I:
Added moving and path-dependent targets, forcing players to think about positioning and sequencing.
Designed objectives that encouraged passing, giving players a space where they felt “forced” to use this core mechanic.
3. Hazards That Mattered
The original hazards (spikes, pendulums, token enemies) posed almost no threat. Failure was nearly impossible. To raise the stakes:
I integrated terrain challenges like knockback pendulums and water hazards that could actually eliminate players.
I added combat encounters with enemies that fought like real opponents, forcing players to duel rather than ignore them.
Upped damage across the board so it became a more practical threat.
Adapting to Feedback
After implementing my changes, I presented the new version of Target Practice to my director. His reaction: it was too complex.
This was surprising given the original request had been for more complexity. Instead of immediately iterating, I shifted into a UX-style mindset: don’t just take feedback at face value, dig into the what and why behind it. After discussion, the nuance became clear. What he actually wanted was micro-complexity (small, layered skill tests like bouncing the ball off a wall for a speed boost), not the macro-complexity I had introduced (larger sequencing challenges like “shoot target A before B”).
I agreed with his point that the level lacked micro-complexity, but I also felt much of the feedback didn’t account for the nuances of an onboarding mode. To me, it came down to a key distinction:
Micro-complexity targets more experienced players. These mechanics are harder to discover, less impactful at first, and often overlooked by brand-new players.
Macro-complexity is more obvious and easier to grasp, which makes it better suited for onboarding new players.
A loose analogy: macro-complexity is like choosing between a vanilla or chocolate cake—clear, obvious differences that are easy to learn. Micro-complexity is more like choosing between two kinds of chocolate cake, where the difference is subtler and takes more time to appreciate.
Ultimately, I disagreed with parts of the feedback but still adapted the design. The shipped version ended up closer to the original due to time constraints and feedback: macro-complexity dialed back, micro-complexity elevated, resulting in a mode that taught players core mechanics while still providing failure points and mastery moments.
Retrospective
This project taught me as much about communication as it did about design. One of the biggest lessons was the importance of clarifying feedback early. I dove into prototyping without fully aligning on what my director meant by “complexity,” which led to extra iteration time that could have been spent on refinement.
In hindsight, I should have asked more targeted questions up front—even if they felt obvious—to better define expectations. I’ve always been someone who has plenty of questions but doesn’t always voice them immediately. This experience reinforced that it’s better to risk sounding naïve than to risk misalignment. That said, my director often admitted he wouldn’t know exactly what he wanted until he saw it, so some iteration was inevitable. Still, pushing for clarity earlier would have saved valuable time.
Bonus Character Gameplay Updates
While I can’t share most of the gameplay updates I made, I can walk through one adjustment I implemented for Snooker’s dash ability.
Originally, all characters in Sparkball used a nav-mesh–based dash distance. The system would project the character forward and check if a valid path existed. If the projection failed, the dash target ended up very close to the origin point. Because dash duration was fixed, this made the dash feel unintentionally slow and clunky.
To fix this, I edited the global nav projection function to pass both the original requested dash and the adjusted projected dash. Since the function only passed a transform, I “cheated” by encoding the original value into the scale—avoiding larger refactors while still passing optional data. With that information, I could subtract the original and adjusted positions, normalize it against the dash duration, and ensure speed consistency.
Finally, I replaced the root motion task with a physics-based approach, allowing characters to slide smoothly along surfaces rather than abruptly teleport behind them. This not only fixed the speed issue but also made dashing feel more natural and responsive in play.