Real-Time Collaborative Web Level Editor for 2D Game Teams

The problem: level design is still single-player

A small game team often has two or three people working on levels. With desktop editors, a level is a file: one person edits it, commits it and hopes nobody else touched it. Merging two versions of a tilemap in Git is miserable because the file format is not designed for it, so teams lock files, pass them around on chat, or overwrite each other's work. Remote teams and game jam teams feel this most.

Design tools solved this years ago. Figma made multiplayer editing normal for interface design, and its engineering blog describes how it syncs edits to a shared document. Game level editors mostly have not caught up.

What already exists and the gap

• Tiled is the widely used open source map editor with many engine integrations, working on local files.
• LDtk, by the director of Dead Cells, is a modern open source 2D level editor with a strong focus on usability, also file based.
• Ogmo Editor is a lightweight open source level editor for 2D games.
• Engine editors in Godot, Unity and Unreal edit levels locally and rely on version control for sharing.

None of these offer real-time multi-user editing in the browser. The gap is a collaborative editor with the essentials of Tiled or LDtk and the sync model of a modern design tool, producing files the existing engines already read.

What you build

Designers open a project link in the browser, pick a level, and see who else is there. They paint tiles, place entities (spawn points, enemies, pickups) with properties, and see others' cursors and edits live. Leads save named versions, compare them visually and restore. Programmers export levels in Tiled or Godot format, or pull them from an API in CI.

The server relays updates, stores documents and snapshots, and handles authentication and project permissions.

The technically interesting part

The core problem is modelling a level as a CRDT so that concurrent edits always converge. A naive design, one big array of tiles, makes every change conflict with every other and bloats history. You need to choose the right structure (tiles keyed by layer and chunk, entities as maps with properties), decide what "concurrent" means for a flood fill that overlaps another user's painting, and make undo work per user, which is harder than global undo. You also need to control document growth, since CRDTs keep history, by compacting and snapshotting.

Show evaluators two browsers editing the same area while offline, reconnecting, and converging to the same state, backed by an automated test suite that does this thousands of times with random edits.

How to evaluate it

• Convergence: randomised tests with 2 to 10 simulated clients, random edits and random disconnections; all replicas must end identical.
• Latency: time from an edit in one client to render in another, at the median and 95th percentile, locally and across a cloud region.
• Scalability: sync latency and server memory with 5, 10 and 25 simultaneous editors on one level.
• Document size: growth per thousand edits before and after compaction.
• Usability: a small study where pairs of students design a level together and compare the experience with emailing Tiled files.

Suggested plan

1. Weeks 1 to 4: study CRDTs, Yjs or Automerge, and the Figma multiplayer write-up; design the level data model.
2. Weeks 5 to 9: single-user editor with tile layers, tilesets and entities.
3. Weeks 10 to 14: CRDT sync, live cursors, server relay; convergence test harness.
4. Semester 2, weeks 1 to 5: per-user undo, offline editing and reconnection.
5. Weeks 6 to 9: version history, visual diff, exporters.
6. Weeks 10 to 14: load tests, user study, report and demo.

Path to a product

Release the editor as open source to earn trust with indie developers and game jam teams, and sell hosted team workspaces with private projects, history and storage limits by seat. The first customers are small remote studios and university game development courses where students work in teams. Game jams are a good channel for early users.

Scope warning

Do not attempt 3D levels, scripting, an asset store or a built-in game engine. Do not write your own CRDT library from scratch unless that is the whole project; use Yjs or Automerge and spend your effort on the data model and tests. A solid tile and entity editor with proven convergence is the goal.

Learn what you need on Sefism

• System design roadmap : realtime sync, consistency and scaling collaborative apps.
• Frontend roadmap : TypeScript, canvas rendering and state management for a large editor.
• System design cheat sheet : quick reference for websockets, persistence and fan-out.
• Red Blob Games : grids, coordinates and tile maps explained properly.
• Godot Engine Documentation : the TileMap format your exporter must produce.

Get help with this idea

CRDT projects look impressive in a demo and fall apart in edge cases, so plan your conflict tests before your features. Bring your proposal and we can agree the scope, pick a stack your team can finish with, and design an evaluation your panel will respect. You build it; we help you make the calls.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session

New here? Create a free account first.