Case study

Multiplayer conversion & technical operations

Character Interaction Multiplayer Framework

Helping turn a tightly coupled single-player Unreal system into a multiplayer-ready framework

Technical operations, collaborative diagnosis, research, testing & systems coordination

Years of involvement

Back to Unreal profile
Multiplayer framework synchronising interactions across four players

In 2018, I joined a distributed Unreal Engine collaboration attempting to convert Character Interaction 3, an established single-player Marketplace product, into a fully replicated multiplayer system integrated with Advanced Locomotion.

The brief covered player behaviour, interactives, bots, weapons, vehicles and first-person to third-person camera transitions. The technical difficulty was not simply adding networking. Character Interaction had been built around single-player assumptions, which meant its interaction, weapon and player logic were already tightly interconnected before replication was introduced.

That made the project a useful lesson in how complex technical work succeeds, and how it fails.

The challenge was architectural, not cosmetic

I had already been exploring Character Interaction and its integration with more advanced locomotion systems before joining the multiplayer effort in August 2018.

The stated objective was to refactor the framework into a fully multiplayer-ready version. Replication responsibilities had to be addressed across players, interactive objects, bots, weapons and vehicles, while maintaining integration with Advanced Locomotion and camera transitions.

The difficulty was that multiplayer changes the meaning of almost every gameplay assumption.

An interaction that works perfectly for one local player may fail for another client.

A weapon may appear correctly equipped on one machine but remain attached or incorrectly represented elsewhere.

A perfectly reasonable Blueprint flow in a single-player context can become unreliable when authority, ownership and replication enter the picture.

The visible bug is often not where the underlying mistake lives.

Joining the collaboration

I initially became actively involved in August 2018, then briefly stepped away in September when it appeared that the remaining work was close to completion.

By late November it was clear that difficult issues remained, and I returned with the intention of helping get the project over the line.

I then brought Raed Abbas into the active collaboration when the team was dealing with a persistent melee and held-weapon problem. Raed quickly demonstrated strong Unreal networking and replication skills, and our working relationship developed rapidly.

Raed's specialist technical knowledge was deeper than mine in networking and replication.

My contribution was different.

I concentrated on creating an environment in which difficult technical work could be carried out safely and methodically.

Making the environment reliable

I configured shared source control and helped maintain the working environments around the project.

That included versioning, backup, access, security and the everyday operational work needed to stop a distributed technical collaboration becoming fragile.

This was not separate from the engineering problem.

When several people are modifying intertwined Unreal systems, the ability to preserve known-good states matters.

If an experimental fix introduces another problem, you need to know exactly what changed.

If two contributors disagree about the source of a bug, you need a reproducible baseline from which both can test their assumptions.

If three useful discoveries lead to a fourth unsuccessful experiment, those three discoveries should not disappear with it.

I became increasingly focused on leaving breadcrumbs: recording intermediate states, separating established facts from assumptions and preserving enough context that we could continue forward rather than repeatedly rediscovering the same information.

Debugging by stepping backwards

When we became stuck, my instinct was often to stop looking for a more complicated solution.

Instead, I would ask:

What do we actually know?

What have we observed rather than inferred?

Which steps have we taken for granted?

At exactly what point does the actual behaviour stop matching the behaviour we expect?

I would then work through the flow step by step with whoever owned that part of the implementation.

This became a useful complement to specialist engineering expertise.

Someone who has spent hours inside a technical system naturally develops shortcuts in how they think about it. Certain steps become so familiar that they stop being questioned.

I was comfortable asking the apparently basic question again.

Sometimes explaining one of those supposedly obvious steps aloud was enough to expose an assumption or contradiction that had previously remained invisible.

The objective was not to take technical ownership away from the specialist.

It was to help them interrogate their own reasoning from another angle.

That worked particularly well with Raed. He could focus heavily on the networking implementation while I helped research problems, test assumptions, preserve progress and keep larger problems broken down into smaller, testable questions.

From difficult project to trusted partnership

Through December, the collaboration covered areas including Perforce, weapon replication, melee behaviour, multiplayer testing and network jitter.

At the same time, Raed and I began discussing whether the lessons from the project could be applied more systematically.

On 8 December, I proposed a cleaner reusable framework centred on locomotion and interaction rather than repeatedly treating each integration problem as a one-off fix.

That discussion would eventually become MESH Interactive.

The Character Interaction work itself continued alongside those ideas.

By 21 February 2019, I publicly described the work as "finally finished", coinciding with the release of the MESH teaser that demonstrated the broader capability that had grown from the collaboration.

What I contributed

My role in the project was not that of the strongest Unreal networking programmer.

Raed and other contributors deserve the technical credit for specialist implementation work.

My value came from making the collaboration more reliable.

I established and maintained shared working systems.

I introduced source control and protected intermediate progress.

I researched unfamiliar problems when the team became blocked.

I challenged assumptions rather than accepting them because they sounded technically plausible.

I helped specialists trace difficult flows one stage at a time.

I documented what had already been learned.

And I deliberately created enough space for people with deeper specialist expertise to do their best work without competing with them for status or ownership.

That combination of technical operations, structured reasoning and collaborative problem-solving became an important part of how I work.

Outcome

The immediate outcome was helping move a difficult multiplayer conversion through to a working public milestone.

The longer-term outcome was more important.

The project introduced me to Raed, proved that our working styles were highly complementary and gave us confidence that we could tackle difficult Unreal Engine integration and multiplayer problems together.

Within days we had begun defining a reusable framework of our own.

Within weeks, that collaboration became a 50/50 venture.

That next chapter became MESH Interactive.

Open to opportunities

Let’s talk about your next challenge

Discuss an opportunity