I'm a doctor, not a mechanic
Map network optimization
Most of the level optimization techniques are aimed towards improvements of rendering performance, but there are also optimizations affecting network games, particularly bandwidth requirements.
The server does not automatically send data about an actor to all clients, but checks whether the actor is "relevant" for the target client. First the actor's own properties and its relation to the client is evaluated (ownership, attachments, etc.) and often these things will decide about relevance already. But if the actor's properties don't decide whether the client needs to know about it, the server checks the actor's environment with respect to where the target client is viewing from. This part can (and should) be optimized by the mapper, because every actor that the client needs to know about takes up a little bit of bandwidth and many actors obviously take up much bandwidth.
Unreal Engine 1[edit]
There's not much you need to consider here. If an actor is hidden behind colliding BSP surfaces (usually only the actor's center, but for players also the head), the actor isn't relevant. Note that non-solids don't count, but invisible or semi-translucent (semi-)solids do.
Unreal Engine 2[edit]
The cheapest way to exclude actors here is the use of zone-based distance fog. The network code only checks zone fog, not volume fog. For some weird reason the actor's zone fog is used, not the viewer's, so if your zones have different distance fog end values, actors might not be considered relevant in certain cases although they would really be visible.
The next thing, like in UE1, is BSP. (Semi-)solids hiding the actor's center and player's head, regardless of transparency, make the actor non-relevant. The actor's CullDistance and terrain near the viewer might also be used to exclude actors, but it seems that only happens when the client's net speed can't handle the amount of data.
It should be noted that anti portal actors are not used for relevance checks at all.
Unreal Engine 3[edit]
This short section needs to be expanded. |