Equalize — Summer 2026

What I Owned

I was the Game Designer for the event, and my work covered quite a few different areas:

• Progression and rewards: missions, point values, stage pacing, rewards, and the repeatable loop after the main track.
• Mixed-tier balance: checking new vehicles, reviewing problem matchups, and validating the combat-modifier fixes.
• Player flow: the welcome screen, event lobby, mission information, rewards, queue, and loading screens.
• Economy: making sure the mode worked outside the usual Random Battle economy.
• Playtests: planning the sessions, preparing builds and instructions, hosting them, gathering feedback, and writing the conclusions.
• Release and analysis: staging checks before launch and reviewing how players behaved afterward.

It was a pretty wide scope. Some days I was working in spreadsheets, some days I was writing requirements or checking configs, and on playtest days I was the person getting everyone into the correct build and keeping the session moving.

What Equalize Is

Equalize is a limited-time World of Tanks mode where tanks from every tier can end up in the same battle. Lower-tier tanks get their combat stats boosted so they can actually compete, but their armor is not scaled. It creates some unusual matchups, and the balance can get messy very quickly if the modifiers are not right.

Summer 2026 was a relaunch, but there was still plenty to work on. New vehicles had entered the game since the previous run, especially tanks with autocannons, and we needed to check how they behaved against lower tiers. We also had a fix for an old high-explosive damage problem, a progression that needed a better difficulty curve, and a lot of player-facing setup to move through our shared event platform in the game client.

The event ran over two weekends across all supported regions. Each weekend had a fresh progression, so returning players had a reason to come back and start again.

The Progression Problem

The old progression had one easy mission and one much harder mission. There wasn’t much in between. Players could either make progress almost automatically or miss the harder objective completely.

I added a middle mission that rewarded solid, normal battle participation. The idea was to give players three clearer ways to move forward:

1. A reliable mission that kept every battle useful.
2. A middle objective that most active players could reasonably reach.
3. A harder objective for strong performances.

The obvious problem was that adding another mission also added more points. In the first model, players would finish the whole track much too quickly. I built a spreadsheet that compared early completion, expected completion, wins, losses, and different mission success rates. Then I adjusted the point flow until the new mission helped the experience without making the event dramatically shorter.

We kept the main reward track and the repeatable loop after it. Players had more understandable short-term goals, while the people who finished early still had something to play for.

How I Checked the Pacing

I didn’t treat the spreadsheet as a perfect prediction of how every player would behave. It was there to catch obvious problems before they reached a build.

By changing the assumptions, I could see how the pacing moved for stronger players, average players, and people who completed only the easier missions. That gave us a much better starting point for playtests than simply choosing values that felt right.

It also made the trade-offs easier to explain to the rest of the team. We could see why a reward changed and what we expected that change to do.

The Rest of the Event

Progression was the biggest part of my work, but it wasn’t the only one. I also helped shape:

• The first-time welcome and information screen.
• How Equalize appeared in the event lobby.
• Mission, reward, and repeatable-progression states.
• Queue and loading information.
• The event economy and its restrictions.
• Explanations for the unusual mixed-tier rules.

A few of these used shared platform features owned by other designers. My job was to define what Equalize needed, work with the system-design and UX owners, and check that everything made sense inside the event. I didn’t build every shared component myself, and I think that distinction is important.

Leading Six Playtests

One part of this project that I am especially happy with is the playtest process. I took over organizing the sessions and created the main playtest page together with the notes and conclusions for all six tests.

Each test moved us a little closer to the real release:

1. We checked that our new process worked and found autocannon vehicles as the biggest balance risk.
2. We moved to the packaged client build and tested the priority vehicles together with the high-explosive damage fix.
3. We invited people from outside the immediate team, continued the combat checks, and tested platoons.
4. We tested again after related vehicle balance changes to see whether the previous outliers were still a problem.
5. We did a wider balance pass and separated future improvements from issues that actually needed to block the release.
6. We filled a full 30-player lobby with release matchmaking and ran the complete event flow.

The final test worked properly and did not uncover a release blocker. By that point, we had already covered the main technical, balance, and matchmaking risks several times instead of leaving everything for one big test at the end.

How the Launch Went

Both weekends launched without technical problems, which was a great result after all the preparation.

The first weekend was smaller than the previous Equalize launch, so I don’t want to present it as a bigger success in every possible way. What looked much better was how well players stayed with the event and came back:

• A much larger share of first-weekend players returned for weekend two than during the previous run.
• Returning players made up most of the second-weekend audience.
• Far fewer players finished the event with no meaningful progression.
• More players completed the main track and reached the repeatable loop.
• During the second weekend, players completed more battles on average, fewer left after one battle, and the highly engaged group grew.
• The event was especially popular with players who already enjoy limited-time modes.

I also don’t want to pretend that my progression changes alone caused all of this. It was a live event, not an A/B test, and things like timing, rewards, marketing, and other game content all matter. What I can say is that the complete relaunch performed better in the areas we wanted to improve.

What I Learned

A relaunch can sound simple from the outside because the basic mode already exists. In reality, the game keeps changing around it. New vehicles appear, old bugs need different fixes, shared platform features evolve, and something that worked last time still needs to be checked again.

The biggest lesson for me was how much work around the game design affects the final result. The progression model mattered, but so did clear requirements, good playtests, correct configs, communication between teams, and taking the time to look honestly at the data afterward.

Equalize also feels important to me because it is close to the kind of role I want to keep growing into. My system-design background helped me understand the technical side, but I was also making design decisions, balancing the experience, leading tests, and following the project all the way through launch.