Max world size without using physics (for a multiplayer game)?


I am curious about how big the world (map) can be if you wouldn’t be using physics at all? I am testing out some 4x spacegame idea I have and I’m curious about this.
With physics the max map-size for multiplayer is 10km in each direction, this I know, but how large can the world be without using physics at all?

Looking forward to hear your thoughts on this. :slight_smile:


It’s not just physics, at a certain point the intervals between position values is too high and you can’t have smooth movement

Hmm for a 4x spacegame that wouldn’t be such a problem, because the units would be so small and I would fake the movement with a repeated position update.

You can simply see losing float precision with std::nextafter function.

1'000 => 1'001 : 16384 values
10'000 => 10'001: 1024
50'000 => 50'001: 256
100'000 => 100'001: 128
500'000 => 500'001: 32
1'000'000 => 1'000'001: 16

Could you explain this, I don’t really understand the concept of losing float precision.

Why not just shift world origin to the area of interest - the user can’t see what’s moving in a galaxy far, far away… May be quite applicable depending on how your 4x is supposed to work.

A floating point number loses accuracy as a number increase in size. The simplest way to think of it is imagine you only had 4 digits to write a number, but you could add a decimal anywhere. You could write from .0001 to 1000, but each time you move the decimal point back, you lose that level of precision.

Single point precision goes up to 2,147,483,647 and the data is stored in 32 bits.

With 3D, models, movement, physics, pretty much everything, gets weird once you lose too much accuracy.


Experimenting is probably the fastest way to find out what works in practice. But thousands of kilometers are possible without resetting the origin, as long as you can live with some limitations. Namely, spaceships may need to be merged into a single mesh beforehand (ships built as blueprint hierarchies at runtime / design-time may not perform well when far from the origin - jitter etc).

Third person camera view is also probably best. Especially if higher Near-Clip-Plane settings are used to avoid z-fighting from overlapped mega meshes, such as planets etc. Plus, for smooth movement, its probably best if ships are a multiple of the default UE4 mannequin in size etc.

But the biggest issue of all arguably comes from avoiding physics movement altogether. For instance, while you can move ships along enormous distances using the BP interpolated movement nodes (which do built-in collision checks etc), BP rotation nodes don’t work reliably imo. For example, its all too easy to rotate a flagship though nearby ships or obstacles, killing the effect! This isn’t a limitation of large worlds, just lack of bound checking using non-physics rotation nodes etc.


True, but what’s the cost of using this repeatedly / constantly? The docs confirm its not a free op (nearby scene has thousands of unique / non-instanced actors etc).

Oh it’s costly, very much so. I only use it during zone transition with a static screen - masked as a *you’ve arrived safely menu. *It’s for a galaxy map and the origin shifts when you reach a cluster of stars which you can then explore freely with tracing not suffering from jittery floating point errors.

Cheers for sharing your approach @Everynone… Its good to know, as there’s so few docs on this.
Does your game support Multiplayer right now too? (Server side origin-rebasing / reconciliation).
Nkey’s PR brought client-side rebasing, but it seems you still have to resolve things server-side etc.

Never used it in MP, can’t comment on that, sorry. Chipped in because of float errors.