MultiWorld

Running several complete UWorlds in parallel is something most Unreal projects never attempt, because a single world already carries so much state through its actors, components, physics, audio, and UI. MultiWorld removes that “one world per session” assumption at runtime. It builds a project where each environment is a separate UWorld instance, and each instance stays completely isolated from the others. Graphics, audio, physics, collisions, and UI all belong to their own world, so a change in one map does not reach the others. At the same time, the plugin preserves a way to move the local player and other actors across worlds, which turns parallel execution into a travel system rather than a set of sealed-off simulation containers.

The isolation between worlds is not a visual trick or a rendering-layer overlay. Each Secondary World owns its actors and components outright. If one world stops its physics simulation or hides its UI, the other worlds continue with their own independent settings. That split is the foundation for game structures where a player can leave a space and yet still feel that space is alive, waiting backstage with its own timing, collisions, and audio.

Stock UE5 Levels as Mirrored Worlds

MultiWorld uses any standard UE5 Level or UMAP as-is. This is the launch point for production because there is no map-conversion workflow. A level already crafted in the Unreal Editor, with all its lighting, Blueprint actors, and gameplay logic, can be loaded as a Secondary World inside the active runtime. The level does not need to be prefixed, renamed, exported, or restructured into a special side format.

The plugin also removes practical caps for smaller productions: the number of independent Secondary Worlds is stated as unlimited. That means the bottleneck is the engine and hardware budget, not a plugin-side cap. A project that wants dozens of lobby rooms, mission spaces, or alternate dimensions can load as many maps as it can manage while they continue to tick in parallel, each with no shared actor or component state leaking into the others.

Because the maps are ordinary UE5 levels, worlds can be authored by the same team and with the same tools used for the main world. There is no separate pipeline for the “extra” worlds, no additional map type to maintain, and no conversion step that might strip out a feature that works in the editor but breaks at runtime. The level that a designer opens, sets, and saves is exactly the level that can be lifted into a Secondary World later.

Player Travel and Actor Transfer Between Worlds

The presence of multiple simultaneous worlds can shape gameplay at the player-controller level, since the plugin can transfer the local player between those worlds. If a game contains doors that lead to pocket dimensions or a passageway that carries the camera into a new environment while the previous one remains live, that transition needs the player object to remain part of the game while being accepted into the destination UWorld. MultiWorld handles that move directly.

Actor transfer is part of the same toolkit. The player is not the only entity that can cross the boundary; other actors can be moved between worlds as well. That supports mechanics where an object gained in one area needs to appear with the player in another, or where a companion, a vehicle, or a moving prop should follow the player into a different world rather than being recreated at the destination. Transferring the actor keeps its state, so a gameplay object does not need to be serialized out and rebuilt in the next map.

These crossings can also use customizable visual transition effects. Instead of relying on a bare render swap or a hard camera cut, the plugin gives the project room to define how the world change looks. The effect might be matched to a loading-screen style, a portal flash, or any other motion the team wants to build. The transition effect is a visual wrapper around a mechanic that already preserves the player’s presence through the switch.

Replication Boundaries: Main World Only

Multiplayer projects have to decide which world is authoritative for UE5’s networked replication. MultiWorld keeps replication on the Main World. Secondary Worlds are not replicated, which means any gameplay running on them is not broadcast across the network session. This split creates a clear architectural rule: bring synchronized multiplayer content to the Main World, and place per-user or non-shared content in Secondary Worlds.

For an online game, this keeps the standard UE5 network model intact. The Main World can hold characters, teams, game state, and everything that every client needs to see with replicated authority. Secondary Worlds can then be used for separate, localized executions that should not burden the network or that need to remain isolated per player. A player entering a private challenge map, an instanced puzzle, or a local-only staging zone can do so inside a Secondary World without changing the replicated state of the Main World.

This is also a practical constraint worth respecting during design. Because Secondary Worlds operate outside the replication flow, they are best used for gameplay that does not depend on cross-client synchronization. Planning the division early means the network system and the parallel-world system are not fighting each other.

Worlds That Tick Offscreen and Load Without Blocking

MultiWorld allows worlds to tick independently, even when they are not shown in the viewport. A hidden world can keep running its timers, physics, animations, and logic while the player looks elsewhere. That makes it possible to keep a far-away environment warm and ready for the moment the player arrives, rather than freezing it into a static state until it is brought on screen.

Independent ticking is useful for background simulations or for level states that must advance even while the player is not there to see them. A world could continue a timed event, move its AI through a patrol pattern, or let a physics scene settle before the player enters. Because the tick rate and execution belong to the Secondary World itself, the rest of the session is not forced to keep pace.

The plugin also provides asynchronous loading of Level/UMAP files. World files can be read off disk in the background, so the runtime is not blocked while a new environment is prepared. That makes it possible to stage large maps while the player is still interacting with the current one. When the transfer finally happens, the destination world is already loaded and waiting, and the customizable transition effect can cover the actual moment of swap.

Blueprint and C++ Access, With Platform Reach

Every major feature in MultiWorld is available from both Blueprints and C++. A designer can set up a world transfer in a Blueprint graph during iterative work, while a C++ programmer can build the same logic into compiled gameplay classes. This dual access means the plugin does not force the team to put world-management code in one place. It can sit next to the controller logic, inside a custom actor, or behind a Blueprint event as the project demands.

The plugin is also compatible with all the major platforms, so the target-device list does not need to be shrunk before the parallel-world feature is tested. It is worth testing early against a specific project and its own architectural constraints, because MultiWorld does come with some technical limitations. With that caveat in mind, the set of capabilities maps well to projects that need multiple live environments at once: games with portals or multiverse travel, levels that keep running after the player leaves, networked matches that want non-replicated instanced areas, and any production that wants to load its next map asynchronously while the current world stays fully interactive.

Explore Similar Assets

• Modular Snap System
• Combo Graph
• Gravity Scatter Tool
• Rooibos Save System
• Ultimate Difficulty Scaling (UDS)