MDK2 Multiplayer: Where the Research Begins

MDK2 was released in 2000 as a single-player action game built around three very different playable characters: Kurt, Max and Doctor Hawkins.

More than two decades later, the game remains an interesting technical subject—not only because of its design, but because of how much of its behavior is exposed through scripts, debug functionality and engine systems that can still be explored today.

At Colosseum Bytes, we have started an experimental research project around a simple question:

Could MDK2 support some form of multiplayer experience?

This is not an announcement of a multiplayer mod or a finished implementation. At this stage, the project is about understanding what the engine can already do, what would need to be extended, and where the practical limits are.

Starting with the scripting layer

One of the first useful discoveries has been the amount of game behavior exposed through Lua scripts.

After extracting and reviewing the original script files, we began testing several runtime functions directly inside the game. These functions allow us to manipulate entities, position characters and observe how the engine reacts when objects normally controlled by the game are created or moved in unusual ways.

For example, our tests have involved positioning characters such as Kurt and Max at specific waypoints and observing their behavior while another character remains under player control.

These experiments are simple, but they reveal important information about how MDK2 manages active entities.

What we are observing

Several behaviors are already becoming relevant to the multiplayer question.

Characters can exist outside their normal scripted sequence, but their behavior is still tied closely to the assumptions of the original single-player engine.

During testing we have observed behaviors such as:

• characters switching between idle and active states;
• movement continuing toward unexpected geometry;
• entities disappearing when sufficiently far from the player and appearing again later;
• different culling behavior depending on the type of entity;
• instability when some initialization or creation operations are repeated.

Those observations are useful because a multiplayer implementation would need multiple player-like entities to remain active and synchronized independently of the normal single-player camera and scripting flow.

Why this matters for multiplayer

Adding multiplayer to an old game is not simply a matter of connecting two copies of the executable.

A multiplayer system needs answers to questions such as:

Who owns each entity?

Which state must be synchronized?

How are position, animation, damage and actions replicated?

Does the engine assume there can only be one real player?

Can additional player entities remain fully active when they are far from the local camera?

The experiments we are performing now are intended to answer these lower-level questions before attempting to design any networking layer.

Debugging the game while it runs

Another area we want to explore further is runtime logging.

MDK2 already exposes useful debug and scripting functionality. Being able to record Lua calls, entity creation, state transitions or other engine activity while the game is running could dramatically accelerate the research.

Instead of testing a command and only observing what happens visually, a useful logging layer could give us a timeline of what the engine is actually doing internally.

This will likely become one of the next major areas of investigation.

What comes next

The immediate goal is not to build a network protocol.

First we want to better understand:

entity lifecycle,
player and AI initialization,
culling and activation,
script execution,
and the boundary between Lua-controlled behavior and native engine behavior.

Once those pieces are better understood, we can evaluate whether MDK2 multiplayer would be better approached through engine modification, external synchronization, new runtime components, or another technique entirely.

For now, the project remains what it should be: early research.

And that is exactly where the interesting part begins.