Multi-User is a room; version control is the record

Do not ask one system to be the other

Multi-User Editing is a client-server session in which connected editor instances collaborate on shared project content. It is valuable for a rehearsal, director review, or coordinated adjustment. It is not, by itself, the durable history of a production. Epic’s setup guidance expects participants to start with the same engine version and exactly the same project content, normally synchronized through version control.

That starting condition explains the division of labour. A session answers “what are we changing together right now?” A revision answers “what known content state did we start from, and what can we restore tomorrow?” Neither label guarantees quality. The session can contain a fast, useful exploration; the revision can preserve a poor choice. What matters is that the team does not confuse immediacy with approval.

Set a session contract before anyone joins

Name the baseline revision, the level or map in scope, the session owner, and the intended output. Make one person responsible for merging or submitting durable changes after review. If an experiment should not become a project change, say so and keep it out of the submission path. The Unreal version-control overview describes revision history and rollback as core benefits; use that history for assets and code even if the live session feels stable.

Use a deliberate end-of-session gate

At the end, stop editing long enough to classify changes. Keep: reviewed changes that belong in the project. Park: useful experiments needing art, technical, or production approval. Discard: temporary choices made only to test an idea. Persisting every improvisation makes later recovery harder, not safer.

Illustrative example: during a lighting review, two artists adjust a sky and one person moves a hero asset to clear a camera. The sky may be a candidate change; the moved asset may be a session-only convenience. The owner writes both outcomes before committing anything. A future operator then knows that the baseline was intentionally changed in one respect and not silently changed in another.

Short checklist

• Sync every participant to the named baseline before joining.
• Limit the session to named levels, assets, and decision owners.
• Record any external control changes that are not project assets.
• Create a fresh session from an updated revision rather than treating an old room as permanent truth.

This proposed process does not prescribe Perforce, Git, or a particular branching model. It gives the live room an explicit entrance and exit so collaboration remains reversible.