POLYGON 2: Dev Diary #1.1 (Updated)

It’s been almost two years since I announced the new installment of Polygon. Since then, I’ve maintained radio silence.

Not because the project was frozen. And not because I had nothing to show.

The reason is simpler: I didn’t want to present the game in a “raw” state.

Polygon // is being built entirely from scratch.

A new foundation. New systems. A new architecture.

In the early stages, it didn’t look like a step forward, It looked like a step backward.

And I didn’t want it to feel like a downgrade compared to the first game.

My goal has always been to move toward a larger-scale experience, but the original Polygon had limitations that made that impossible.

So I made the difficult decision to start over. No shortcuts. No legacy solutions.

It was important for me to reach the point where the project no longer looks like a rough prototype, but begins to show its true direction.

And I feel that moment has finally come.

This is the first entry in a new development diary series, where I’ll be talking in detail about the core mechanics of Polygon //.

And today, we’re starting with destruction:

Destruction in Polygon // is part of the gameplay.

During combat, the environment gradually changes. Familiar cover disappears. Buildings lose their shape and reveal new sightlines.

This makes every situation less predictable.

You don’t just move through the map. You reshape it.

I wanted the environment to stop being a static backdrop.

Every instance of destruction is generated procedurally. There are no pre-recorded animations and no predefined patterns.

The shape of a breach depends on the impact point, force, and conditions at the moment of the explosion. Because of this, each match unfolds differently.

You can create new paths where none existed before. Or deny your opponent their usual route.

Destruction becomes a tactical tool — one that directly influences the battlefield. In most shooters, moving objects and physics calculations are processed on the client side, meaning on your PC. The server mainly handles state synchronization between players to ensure proper interaction in multiplayer.

However, with this approach there is always a risk of desynchronization: the server and the client may interpret the same event slightly differently. As a result, you can end up in a situation where, from the player’s perspective, the aim was perfect, but the hit was not registered on the server.

In Polygon //, server-side physics became the foundation of the destruction system. To ensure determinism and absolute synchronization of destructibility, all critical logic was moved to the server. This guarantees that two different clients always receive an identical simulation result, regardless of their performance or local conditions.

Existing off-the-shelf solutions did not meet the needs of Polygon //.

Most of them are either too performance-heavy or, more importantly, not designed for proper network synchronization.

A significant amount of work went into developing a custom solution focused on high performance and stable multiplayer behavior.

As a reference for quality and scale, I relied on the approach implemented in The Finals, which represents one of the most advanced destruction systems in the modern gaming industry.

I am sincerely grateful to the developers of The Finals for publishing their development diaries. The publicly available technical insights and breakdowns of their solutions significantly helped me in designing and refining the destruction system architecture for Polygon //.

The following video showcases very early development footage of The Finals that is publicly available.

Each detached fragment has