World Defenders TD

World Defenders TD is a co-operative tower defense game for up to 25 players, built by Santoz Studios and live on Roblox since September 2020. It has since passed 303 million visits and 436,000 favourites, and it is still being updated.

Longevity is the part worth paying attention to. Most Roblox games peak in their first month and are abandoned within a year. Staying live and actively updated for six years is a different engineering problem to launching, and it is the problem this project is really a case study in.

The scale problem: 360+ towers

The game ships with over 360 unique towers, each with its own abilities, upgrade paths, and interactions. That number is the central design constraint, and it breaks the obvious implementation immediately.

Hard-coding 360 towers as individual scripts produces an unmaintainable codebase and a load-time problem. Towers have to be data-driven: definitions live in configuration, and a single generic tower system interprets them. Adding tower 361 becomes a data change, not a code change.

This is also what makes six years of content updates economically viable. When new towers are data rather than code, the marginal cost of a content drop stays roughly flat instead of climbing with every addition.

Trading, and why it raises the stakes

The game lets players trade towers with each other using Gems or Robux. Player-to-player trading is the single highest-risk system you can put in a Roblox game, because it converts any duplication bug into an economy-wide event rather than a single player's problem.

A duplication exploit in a game without trading affects one player's save. The same exploit in a game with trading propagates: duplicated items spread across the player base within hours and the item's scarcity, and therefore its value, is permanently destroyed. Recovery usually means a rollback, which costs you the players who did nothing wrong.

That is why every part of a trade has to be server-authoritative and atomic. The server validates both sides own what they claim to own, locks both inventories, performs the exchange as a single operation, and persists the result before releasing the lock. The client's role is limited to expressing intent and rendering the outcome. This is the approach we describe in our Luau scripting services.

25 players, many worlds, one session

The game supports solo play and co-operative teams across multiple worlds and difficulty tiers, with up to 25 players in a session. Tower defense is unusually demanding here: every tower is running targeting logic against every enemy in an active wave, and wave sizes grow across difficulties.

Naive targeting, where each tower scans all enemies every frame, does not survive contact with a late-game wave. Keeping frame time stable means the targeting system has to be structured around the fact that most towers do not need to reconsider their target most frames. The techniques involved are the ones documented in our performance optimisation guide, which remains the most-read article on this site.

Six years of schema migration

The constraint nobody anticipates when launching a Roblox game is that player data outlives every version of the code that wrote it. A player who last logged in during 2021 will eventually return, and their save was written by a data schema that has since changed many times.

You cannot delete their progress, and you cannot ship code that assumes the current shape. Every save needs a version stamp, and every load path needs to migrate forward through the intervening versions before the game logic sees it. Miss this and a returning player either loses everything or crashes the server that loaded them.

Six years of content updates means a long chain of these migrations, each of which has to remain correct indefinitely. This is the least glamorous work on a long-lived game and the most expensive to retrofit, which is why the versioning has to exist before the first content update, not after the first complaint.

Co-operative state across 25 players

Co-operative tower defense has a synchronisation property that competitive genres do not: every player sees the same board, and every player's actions change it for everyone. A tower placed by one player must appear, target, and deal damage identically for all 25 participants.

Replicating every tower's per-frame targeting decision to every client would saturate the network budget quickly. The workable approach is to replicate state changes rather than state: clients are told a tower was placed, upgraded, or destroyed, and they run presentation locally from that. The server remains the only authority on what actually happened.

Wave composition follows the same logic. The server drives wave spawning and enemy health, while clients render movement locally from the spawn instruction. A player on poor connection sees slightly stale positions rather than a desynchronised game.

What the numbers actually say

303 million visits is the headline, but the more informative figure is 436,073 favourites against an 83.6% positive rating across nearly 240,000 votes. Favourites indicate intent to return. A rating that holds above 83% across a vote sample that large, over six years and many content updates, indicates the game kept its quality bar as it grew.

All of these figures are public on the Roblox game page and can be checked directly.

What transfers to other projects

• Data-driven content systems, so adding content does not mean adding code
• Server-authoritative trading and inventory, designed so duplication cannot propagate
• Architecture that stays maintainable across years of live updates rather than months
• Performance work targeted at the systems that actually dominate frame time