Unity & WebGL Game Development

Multiplayer Unity games that ship to the browser — authoritative netcode, WebGL delivery, and on-chain ownership.

I build Unity games that run in a browser tab and hold up with other players in them. That combination is where most Unity work gets difficult: WebGL removes threading and imposes a hard budget on build size and load time, while authoritative multiplayer demands that the server — not the client — decides what happened. I have shipped a catalogue of browser-playable titles on my own arcade platform and built a zone-sharded MMORPG architecture on headless Unity servers, so this is production experience rather than tutorial experience.

What I build

Multiplayer netcode

Authoritative networking with Mirror or Photon Fusion, depending on what the game actually needs — Fusion's tick-based model for tight competitive play, Mirror where you want direct control over the transport and headless server processes. Either way the server owns the simulation, because a client-authoritative multiplayer game is a cheating exploit with a release date.

WebGL delivery

Getting a Unity build to load fast enough that players stay. That is build-size discipline, asset and compression strategy, memory-ceiling work, and a WebSocket-based transport since WebGL cannot use UDP. It is unglamorous, measurable work, and it is the difference between a game people play and a loading bar they abandon.

Scalable server architecture

For persistent worlds, zone sharding: each region simulated by its own headless Unity process, scaled independently, with a backend owning identity, sessions, storage, and matchmaking so the simulators stay reschedulable. This is what I built for Gotchi World on Nakama with Postgres and Redis, containerised for Kubernetes.

Web3 and on-chain ownership

Wallet connection, NFT-gated content, and on-chain saves and progression, with ownership resolved server-side at session start rather than trusted from the client. I built an on-chain cartridge system in Solidity so games get persistent saves and leaderboards without operating an account system at all.

Game platform engineering

The layer around the game: a web platform that hosts multiple WebGL builds under one session, leaderboards, badges, player profiles, and a consistent integration path so a new title plugs into all of it instead of reimplementing it.

How I work

I want to see the game running before anything else. For multiplayer, the earliest useful milestone is two clients connected to an authoritative server doing something trivial — because every hard problem in the project is visible at that point, and none of them are visible in a design document.

Netcode and the WebGL budget get addressed early rather than at the end. Both are architectural: retrofitting authoritative networking onto a client-authoritative prototype, or cutting a 200MB build down after content is locked, costs several times what doing it in the right order does.

Work is delivered as playable builds on a regular cadence. You should be clicking a link and playing the current state of the game, not reading a status update about it.

Handover includes the project configured to build and deploy from a clean checkout, with the deployment path documented and verified — not just the Unity project folder.

Proof

Case studies from work I have built and run, not client logos.

Stack

  • Unity
  • Mirror
  • Fusion
  • Nakama
  • Colyseus
  • Phaser
  • Next.js
  • Solidity
  • Docker
  • Base

Questions

Mirror or Photon Fusion — which do you recommend?

It depends on the game. Fusion's tick-based prediction suits fast competitive play and takes a lot of hard problems off your plate, at the cost of a hosted dependency and its pricing model. Mirror gives you direct control over transport and lets you run headless Unity servers on your own infrastructure, which matters for zone-sharded worlds. I have shipped both and will recommend based on your game, not on preference.

Can a Unity game realistically run well in a browser?

Yes, with discipline. WebGL has no threads, a memory ceiling, and no UDP, so the transport must be WebSocket-based and the build size has to be actively managed. Those are constraints to design within, not blockers. Every title in my arcade catalogue is a browser-playable Unity build.

Do you only work on Web3 games?

No. Most of my published work happens to be in a Web3 ecosystem, but the transferable skills are Unity, authoritative multiplayer, WebGL delivery, and backend architecture. If your game has no chain component that removes work rather than adding it.

Can you take over an existing Unity project?

Yes. The first deliverable in that case is an honest assessment: what the project does, where the architecture will fight you, and what it costs to fix versus work around. I would rather tell you a netcode layer needs replacing than quietly build on top of one that cannot scale.

What makes a Unity game harder to build for the browser than for desktop?

Three constraints. WebGL builds have no threading to spare, so anything expensive has to fit the main loop. There is a memory ceiling, and exceeding it crashes the tab rather than degrading. And there is no UDP, so multiplayer must run over WebSockets, which changes how you handle latency and packet loss. On top of that, download size directly costs you players — every megabyte is people who close the tab before the game loads. None of these are blockers, but they are architectural decisions rather than things you optimise at the end.

Where are you based, and do you work remotely?

Julius Wong is based in Long Beach, California, in the Los Angeles area, and works remotely with clients worldwide. Most engagements are fully remote.

Last updated .