How we built Colonist Rush

In Colonist Rush, why does everyone have to wait while players are discarding? Why are initial placements still sequential? How are decisions like these made?

This is a follow-up post on Rush Announcement, where we'll answer these questions and many more.

How Did We Come Up With the Idea?

For years, we kept asking the same question:

What would Catan look like if it were designed for the internet from day one?

In the summer of 2025, after playtesting early physical real-time variants, we felt we had found the answer.

We had a real-time version that preserved the best parts of 4 player Catan: trading, racing, blocking, and self-balancing player dynamics.

But it removed the biggest problem: waiting.

The result was strange in the best way. Games were faster than 1v1, but still felt like full 4 player Catan.

We immediately knew we wanted to bring that experience online.

Colonist was originally built because we loved Catan and wanted people to play it more easily online.

Colonist Rush comes from the same place.

But this time, we are not just adapting the game for the internet.

We are evolving it into something that could only exist on the internet.

Our Guiding Principle

Throughout development, we followed a simple principle:

Don't stop the game unless absolutely necessary.

We wanted players to stay in flow as much as possible.

That meant players could continue taking actions while others were trading or playing a development card.

The only exceptions were what we called forced actions: situations where a player must resolve something before the game can continue, such as discarding cards after a 7 is rolled.

Discarding is the only blocking event because allowing other actions during it created too much chaos. You could be picking cards to discard when someone plays Monopoly or steals one of those cards. Suddenly it's unclear what should happen.

So we made discarding a forced action that must be resolved before the game continues.

Whenever we encountered a problem, we tried solving it in ways that felt familiar to existing Colonist players. We wanted to minimize learning curve while maximizing speed.

The First Challenge: Colonist Was Built Around Turns

Colonist's codebase was originally designed around a turn-based game. Both the frontend and backend assumed that only one player could act at a time.

The first step was refactoring the game so multiple players could take actions simultaneously. So we generalized it. Instead of one current player, every player now carries their own state at all times. "Whose turn is it" became "what is each player allowed to do right now."

After a month of work, we had a functional version of Colonist Rush. It was sort of playable.

Previously, mechanics were tied to the standard turn structure. We’ve now decoupled them so they don’t depend on how turns work. Individual mechanics can now be customized independently, supporting formats like 2v2, or everyone playing at once.

Along the way, we fixed countless visual bugs, gameplay bugs, synchronization issues, and edge cases.

Once the functionality was stable, we moved on to the fun part: gameplay optimization.

Problem #1: Game Was Too Slow

Our starting point was rolling the dice every 30 seconds, but we noticed it felt painfully slow.

We wanted something faster.

As we reduced the timer, a new problem appeared.

Players were getting resources too fast and were being forced to discard constantly. Frequent discards meant frequent interruptions. Frequent interruptions meant players waiting for each other.

This directly violated our goal of keeping the game moving.

Our solution was increasing the discard limit from 7 to 9.

Why 9, and not 10 or 11?

1. 9 wasn't a new idea. It's the same limit our 1v1 Ranked players already use, so it was battle-tested and felt familiar from day one.
2. Discard penalty exists for a reason: it punishes hoarding and keeps the 7 rolls meaningful. 9 was the smallest change that smoothed out the interruptions while keeping that tension intact. Go higher, and discards almost never happen. Hoarding becomes risk-free and the robber loses its bite.

This change dramatically reduced how often players had to stop and discard. The game flowed much more smoothly, so we were able to reduce the dice timer to as low as 5 seconds.

Problem #2: Trade Offer Spam

Once we achieved the pace we wanted, another issue quickly became obvious. Trade offers were everywhere. Players would spam offers constantly. On mobile devices, this became particularly annoying.

Our first attempt was simple: make trade offers hide-able.

That helped, but didn't fully solve the problem. Players still wanted to see useful trades. They just didn't want to see every trade.

Eventually we realized something important:

• In the base game, a rejected offer is worth keeping around. Turns are slow, and trading is a negotiation. How an opponent responds can change your own answer, so "no" often means "not yet." You might reconsider before the turn ends.
• In Colonist Rush, none of that holds. Everyone is trading at once, offers arrive by the second, and once you've rejected one, you're not coming back to it. The offer has done its job.

So we made rejected offers disappear immediately.

That was a major improvement, but we took it one step further. If you don't own the resources required to accept an offer, we simply don't show it.

These changes dramatically reduced the amount of distracting trade noise without reducing meaningful trading.

Problem #3: Hotkeys

One of the first suggestions everyone had during testing was hotkeys. Rush creates more demand for hotkeys than any other Colonist game mode. So why didn't we add them?

Because hotkeys would create a significant advantage for web players over mobile players. Maintaining competitive fairness across platforms was more important than maximizing speed for one platform.

As tempting as hotkeys were, we ultimately decided against them.

Problem #4: Initial Placements

Initial placements presented another challenge. How could we make them feel more aligned with the spirit of Rush?

During our yearly Guild Retreat at Istanbul, we experimented with multiple approaches, including having everyone place at the same time.

Some of these versions were chaotic. Some were fun. But they all had one problem: They significantly reduced the strategic depth of initial placement. In the end, we decided to keep placements sequential. We made initial placements short enough that you always need to pay attention, but still long enough for real strategic thinking.

Finding the Right Speed

One of the most interesting discoveries from testing was that different player groups preferred different speeds. Casual players generally found 8s turns easier to follow. Competitive players preferred 5s turns because it delivered the "Rush" feeling we were aiming for.

When we were first testing Colonist Rush in rooms, we chose 8s as the default. Over time, something interesting happened. Among the optional settings, 5s became by far the most popular speed. That led to another question: Should 5s become the default?

We worried that new players might bounce off the mode if their first experience felt too intense. So we looked at the data.

Players whose first Rush game used 5s timer were actually more likely to play another Rush game than players who started at 8 seconds.

That gave us the confidence to make 5s default. And yes, we tested 3s and 4s timers too. They were nearly unplayable.

The Results

When we released alpha Rush in Custom Rooms in January, Colonist Rush immediately became one of our highest-retention game mode.

Later, we ran separate experiments for bot players and ranked players. Rush proved popular across every cohort we tested.

That said, some of the most enthusiastic feedback came from 1v1 Ranked players.

The reactions we received on Discord and Reddit were incredibly encouraging and motivated us to continue improving the mode.

What Colonist Rush Taught Us

One unexpected benefit of Rush was that it exposed UX inefficiencies throughout the game. When every second matters, friction becomes obvious.

For example, we would like to provide more information when choosing whom to rob. We would like trade offers to communicate more context. We would like opponent panels to make it easier to identify who's winning at a glance.

Colonist Rush highlighted many opportunities to improve the overall Colonist experience, not just Rush itself.

What's Next?

The optimizations never stop. Every improvement that removes friction makes larger and faster real-time games more feasible.

Once we've solved enough of those problems, maybe 50-player Colonist games won't sound so crazy.

Oops.

That might have been a spoiler.

The Future of Colonist Rush

Colonist Rush started as a simple question: What would Catan look like if it were designed for the internet from day one?

Now that Rush is live, we see it as the beginning of a much larger direction for Colonist.

• Faster games.
• Less waiting.
• More simultaneous decisions.

And this is only the first version.

Play Colonist Rush. Break it. Tell us what to fix. Help us build the future of Colonist.

and if you want to build cool stuff like this, apply here