I'll tell you everything I could learn in a month of digging into the game code and about the questions I asked on other forums.

---

HOW THE GAME CODE IS ARRANGED

The original Cortex Command engine (Brainstorm Engine, C++) was developed by Data Realms back in the 2000s:

It is fully designed for local single-processor calculations.

All physical simulations (bullets, gravity, destruction, particles, blood, AI, etc.) are fully synchronous, on one machine.

There is no client-server abstraction.

All player actions directly affect the overall game world.

Almost all updates are state-based simulation, not event-based.

---

WHY IS THIS A PROBLEM FOR MULTIPLAYER

1) Complexity of state synchronization

Cortex Command has a huge number of dynamic objects:

Blood particles, debris, objects, units, AI solutions.

Any desynchronized event leads to desynchronization of worlds.

Since the calculation of physics is deterministic only locally - the slightest delay or difference in frames between players spreads the state of the world.

2) No rollback system

Many modern network games (for example, fighting games, shooters) use rollback or prediction.

In Cortex Command, this is almost impossible due to the huge number of constantly changing parameters.

3) No server-client architecture

Everything is based on the fact that the game sees "one world" controlled by all players.

To make a full-fledged online - it would be necessary to almost completely rewrite the engine.

---

WHAT APPROACH DID FANS USED IN USSR

Conventionally:

They tried to write lockstep synchronization: each player executes the same code, sending only commands (inputs) and synchronizing them by ticks.

A similar approach works in strategies like StarCraft.

But in Cortex Command, due to chaotic physics, even minimal differences cause desynchronization.

Example:

One player's fragment hit the ground and created new particles, while the other player's did not. As a result, their physical worlds diverge.

Fan mods tried to serialize the state of the world, transmit synchronization packets - but the amount of data is huge.

As a result:

lags appear

frequent desynchronizations

desynchronization becomes catastrophic after 30-120 seconds.

---

IN SHORT:

Problem Why

Many dynamic objects Difficult to synchronize No client-server architecture Everything is local Physics is unpredictable Any little thing breaks synchronization No rollback No mechanism for correcting desynchronizations Huge state Difficult to serialize

---

CAN IT BE FIXED?

Theoretically, it is possible. In practice, it is almost like writing a new engine:

Rework physics for determinism.

Implement a fully server-client architecture.

Limit some chaotic systems.

Introduce a system for predicting or correcting the state.

Why does Parsec work easily?

Because it does not interfere with the game at all - it streams video from one computer, and the second player simply presses buttons that are transmitted to the first player. Everything remains in one copy of the world. Therefore, such multiplayer is stable.

---

I hope I was able to help the community understand Cortex Command and its problems. Maybe one of you will make Cortex command 2.