If you've read the previous articles, you already know that the engine will support multiplayer and that the game framework architecture will be using the client-server model with an authoritative server. What that means is that the game state will be stored on the server-side while the clients will be simulating some parts of it locally to keep the gameplay responsive. Although, it is currently unclear whether the cell data should also be authoritative. The entities will be stored and processed on the server-side but the level/cell data can either be (partially) controlled by clients or kept fully authoritative (server-side).
There are two possible distinct implementations in mind:
1) Let the clients load cells data from their local game cache (Client-side level streaming);
2) Load the cell data on the server-side and send it to the clients forcing them to use the same cell data as on the server (Server-side level streaming);
For better understanding, some clarifications should be made. In both cases, it will be required for the server to keep track of the current cell each player is in and send cell/chunk loading/unloading commands to them. But, in the first case, we only need to send the command and cell's id to load/unload. Each client will load its local cell data from the file. That reduces the amount of data we need to send through the network but allows the clients to load their own versions of cell data, whether its the same as on the server or not. In other words, the client can have a modified version of a specific cell that the server tells him to load into memory from the file. And, even though that means that only this particular client will have a modified version of the cell without affecting anyone else, that's not the perfect solution, because it can cause some issues between the server and client communication and state synchronization.
In order to avoid that, one of the possible solutions is to make the world cells data authoritative by using the server-side versions of the game assets and sending that data over to clients in some kind of format for reconstruction on the client-side. So there will be some kind of cell cache from the server that clients will be using along with the cell streaming commands mentioned above.
The cell cache will be represented by some sort of collection of textual representation (like XML) of the cell received from the server that the client will reconstruct locally to use it for rendering purposes and for local simulation (including collision detection). This pretty much will work the same way as in, Minecraft, for example. The only difference is that the Minecraft server sends chunk data which holds the chunk's blocks data, while the cell will hold data about objects placed on it.
What are the benefits of server-side cell/level streaming? The main benefit is that it will allow all clients to have the same version of the cell/level and the whole map. It will be the same one as used by the server itself. And that also means that the server could have a modified version of certain cells brought by some mods, for example, that will work for all clients. Yes, this will allow server admins to install mods that modify the game map and those changes will be reflected on all connected clients! This won't be possible if we keep the cell streaming client-side only.
There is also a high probability that the server will have the same (or slightly changed in 1-2 cells) version of the world as the clients. In that case, we can make optimization and skip the server-side version download by caching the local version instead.
