MESH Interactive

Recognising the opportunity

The idea behind MESH came directly from problems we had encountered in real Unreal Engine development.

Game developers had access to increasingly sophisticated Marketplace technologies.

A locomotion system could be excellent.

An interaction framework could be excellent.

The same might be true of inventory, combat, vehicles, AI or weapons.

The problem was what happened when somebody tried to build a game from several of them.

Each product had been designed around its own assumptions.

Different systems might want ownership of the same character state.

Input logic could conflict.

Animation behaviour could conflict.

Networking expectations could differ.

One framework might have no concept of multiplayer at all.

The result was that developers could own all the pieces they needed and still face months of integration work before those pieces behaved like one product.

MESH was intended to operate in that gap.

A reusable foundation rather than another one-off integration

Raed and I began thinking about a cleaner, component-based architecture in which locomotion and interaction could form part of a reusable multiplayer foundation.

Our discussions covered reusable components, clearer separation between networking and gameplay behaviour, camera systems, network traffic and packaged combinations of marketplace technologies.

The goal was not to claim that every system had to be created from scratch.

The proposition was deliberately pragmatic.

Where strong marketplace technology already existed, we could integrate, adapt and replicate it.

Where a project needed something specific, we could architect bespoke functionality around it.

The value was in making everything work together coherently.

Contemporaneous records describe MESH as a 50/50 working venture rather than a separately incorporated company. We deliberately planned to formalise the company structure once there was a paying contract requiring it.

Building the proposition

Once we had agreed to create the venture, I concentrated on turning the technical capability into something clients could understand and buy.

I created the MESH name and visual identity.

I registered the domain.

I built the website and email infrastructure.

I created the commercial positioning and licensing material.

I established the Discord environment.

I worked on how the framework should be presented to studios, investors and potential partners.

At the same time, Raed continued developing demonstrations and technical systems.

By January 2019 we were discussing clean integration projects, packaged examples and reusable demonstrations designed specifically to show prospective clients what the framework could do.

This was one of the roles I naturally tend to occupy around technical specialists.

I do not simply ask, "What have we built?"

I ask, "What problem does this solve repeatedly, who has that problem, and how do we turn the capability into something they can understand and buy?"

Demonstrating the breadth of the framework

The public MESH material eventually demonstrated a broad range of interconnected gameplay areas.

These included locomotion, smart jumping, foot IK, dynamic cameras, pickups, save/load functionality, talent trees, character classes, inventory and equipment, levels and skills, vehicles, interaction systems, weapons, scopes and ballistics, combat, AI, looting and both cooperative and competitive multiplayer.

This did not mean that Raed and I had independently authored every underlying feature.

MESH combined, integrated, adapted and replicated both marketplace and bespoke systems.

The proposition was the integration layer and technical foundation that allowed those systems to function together as part of a multiplayer game architecture.

On 21 February 2019, we launched the MESH Interactive teaser publicly.

A collaboration that had begun around one difficult multiplayer conversion had become a recognisable studio proposition within little more than two months.

Taking the proposition to market

The next step was finding out whether studios would pay for it.

A small integration enquiry arrived shortly after launch. We produced a formal estimate, but the prospect declined.

A more significant opportunity followed in March.

The prospective studio wanted to combine several major Unreal Engine technologies, including Advanced Locomotion System, Survival Game Kit and Character Interaction, within a multiplayer game.

This was almost exactly the problem MESH had been designed around.

An NDA was signed and we entered a detailed discovery and scoping process.

Requirements covered cameras, character behaviour, inventory, vehicles, weapons, locomotion, interaction, melee, archery, lobby systems and multiplayer architecture.

I handled much of the commercial side: discussions with the client, requirement gathering, scoping, exclusions, pricing approaches and translating the technical work into a structured engagement.

Raed concentrated primarily on the specialist technical questions.

The client understandably wanted proof that difficult elements could be solved before committing to the project.

That included demonstrating a working true-first-person camera approach.

We carried out prototype work around the requirement, but the boundary between proving capability and beginning unpaid implementation became increasingly unclear.

By 19 March, expectations around scope, price, proof and deliverables had diverged sufficiently that the engagement ended before any evidenced payment or paid production work began.

Learning where technical discovery should stop

That unsuccessful engagement became one of the most useful commercial lessons from MESH.

Good technical teams naturally want to prove that they can solve the problem.

Prospective clients naturally want confidence before committing money.

Without firm boundaries, both instincts can create a trap.

Every additional prototype reduces uncertainty for the client but increases the supplier's unpaid investment.

Every extra technical answer can expose another requirement that needs further investigation.

Eventually, "show us that you can do this" becomes indistinguishable from beginning the project.

Today I would structure that type of engagement differently.

Initial conversations would qualify the opportunity.

Anything requiring meaningful architecture, experimentation or prototype work would move into paid discovery.

That discovery would have explicit outputs and acceptance criteria.

Only then would full production begin.

The lesson was not that the MESH proposition was wrong.

It was that specialist technical capability needs an equally strong commercial process around it.

My role in MESH

My role covered the space between the engineering and the market.

I helped shape the framework concept and product direction.

I maintained the collaboration infrastructure around the technical work.

I created the brand, identity, website and commercial proposition.

I worked out how to explain the capability to people who did not live inside Unreal Engine Blueprints every day.

I identified opportunities and engaged prospective clients.

I led discovery and helped translate game requirements into technical scope.

I worked on estimates, delivery approaches and commercial structures.

And throughout the technical collaboration, I continued using the same methodology that had worked during Character Interaction: establish what is known, challenge assumptions, preserve intermediate progress and give specialist contributors enough structure and space to solve the hardest problems.

Raed brought deeper specialist expertise in networking and replication.

I brought the systems, product and commercial layer around it.

That complementarity was the basis of MESH.

Outcome

MESH remained a relatively short-lived venture.

The main active build and market-development phase ran through 2019. Collaboration reduced later in the year, the domain was cancelled in December, and by January 2020 I was referring to MESH in the past tense as our "working together" brand.

But MESH achieved what makes it useful as a case study.

We recognised that expertise developed solving one difficult client problem could become a reusable capability.

We turned that capability into a framework proposition.

I converted it into a brand and commercial offer.

We publicly demonstrated it.

We tested it against genuine studio requirements.

And the experience exposed both the strengths of the technical model and weaknesses in the way we initially approached commercial discovery.

Most importantly, MESH helped clarify a role I have continued to perform in later technical work.

I am often most valuable at the point where specialist engineering, product thinking and commercial opportunity meet.

I can help create the environment in which difficult technical work succeeds, understand enough of the underlying problem to challenge assumptions and coordinate specialists, then translate the resulting capability into something customers, partners or investors can understand.

MESH Interactive was an early example of me doing all three at once.