18
\$\begingroup\$

I have an authoritative system, where when the player joins the match, it gets all the already spawned objects - spawned on itself (the client).

It looks like this:

  1. Client sends the access token to the Server
  2. Client receives the acceptance from the Server
  3. Client switches scene to the game scene
  4. Server sends players, crates, objects you can interact with so the client can spawn and display them.

But what about the ground object? For now, I have the exact same scene on the server and the client - with one static plane acting as a floor. Currently I'm adding new stuff, trees, stairs and build things together.

I thought - we're good. But shouldn't the environment be synchronized too? Be networked somehow? Owned by the server?

Let's take League of Legends:

enter image description here

It's a static environment, probably one combined mesh (stairs, grass, walls, shop). But is it really kept on the client or is it sent by the server during the loading screen?

\$\endgroup\$
  • 1
    \$\begingroup\$ You can even think about it from the point that you can add custom skins to league characters and environment. You don't send them to sever, they are displayed locally, so it makes sense to come to conclusion that they are stored and rendered locally. Aslo, they don't affect gameplay, if you are asking about collisions, they are a mix of server and client, so that player can not cheat and go through walls. \$\endgroup\$ – Candid Moon _Max_ Jul 21 '17 at 15:24
41
\$\begingroup\$

For the most part, no, art assets of any kind aren't routinely sent across the network. Generally all clients will have the same content assets locally. There may be code to ensure this is the case via checksumming the content, or similar. If you are worried about users tampering with some of their content client-side, you can implement a similar system.

The server might send directives to the client indicating it should display or hide certain assets, but it won't send the actual data of the asset. This is, in practice, too wasteful and slow, and could cause real problems with people with limited data available.

In certain cases, smaller assets may be streamed across in their entirety if the asset is somehow considered a "spoiler" or whatever. But that's uncommon. Generally what you see is that a game might download new content from a patch, or whatever, but that will only happen once, during the patching process at startup. Not during gameplay.

\$\endgroup\$
  • 21
    \$\begingroup\$ Note that this answer only addresses static assets. Dynamic/player generated assets (e.g. Minecraft world chunks, or MMORPG guild logos that players can upload) will have to be transmitted. But even then one usually tries to minimize the amount of data necessary (to continue the Minecraft example: sending block updates instead of whole chunks, only indicating the block type/state and coordinate that changed) and/or cache the data on the client side. \$\endgroup\$ – hoffmale Jul 19 '17 at 16:35
  • \$\begingroup\$ @hoffmale Yes, good point; the question mentioned the landscape was static at the end, so I didn't think to raise that point, but it's a good one. \$\endgroup\$ – Josh Jul 19 '17 at 17:25
  • 3
    \$\begingroup\$ If an asset is a spoiler, usually the asset is on the client, encrypted, and the decryption key is transmitted from the server to the client when the asset is needed. \$\endgroup\$ – Grant Davis Jul 20 '17 at 3:21
  • 4
    \$\begingroup\$ And for example if you need to randomly place trees on a map, instead of sending the coordinates of the trees to the client, it sends the seed (of the random number generator) to the client. \$\endgroup\$ – Grant Davis Jul 20 '17 at 3:24
5
\$\begingroup\$

Depends on several factors, including the kind of game (I'll assume RTS here, though open world MMO also comes to mind). A base, local-to-player terrain state is either sent on connect, or is part of the client's assets - think of an RTS game where the map is either shipped with the client, or is downloaded prior to a game commencing.

Indeed, the mesh would not usually be sent, as it would already be on the client in most RTS cases. Whether or not the collision map, which is what's really crucial for keeping the two in sync is sent, is another question. But in most RTS, this would again be pre-stored on the client.

So really, it all depends on what your RTS ships with, whether you download maps prior to play time, or at the time when the game commences.

After that, there are a few typical ways to stay synced:

  • Deltas are sent to the client - the most common and efficient way to keep the local / client world up to date with the server;
  • Checksums are occasionally sent either from server to client or client to server to ensure that the world state does indeed match;
  • Occasionally, full state is resent to resync the client - often as a result of technical concerns like floating point drift.
\$\endgroup\$
4
\$\begingroup\$

As to your exact question as asked, I do not know how League of Legends specifically handles it. I have never played that game, so I cannot suggest whether or not it needs to.

But the answer to your question, in general, is fairly simple and straightforward:

If the data is static, and you know for sure that it will never change (short of periodic full-game-updates, but that's separate), then why would you ever want to send that extra data? Usually you try to avoid sending whatever can be avoided. Only send data if that communication is a need.

On the other hand, if the data will change over time, or if you just want to leave that option open, then do you really have any choice in the matter? For this case, you must send the data. Otherwise the client does not have what it needs.

This applies to all network communications, not just terrain data. Everything.

\$\endgroup\$
2
\$\begingroup\$

No.

I have done a fair about of digging about in the source of League of Legends, and everything, including Champion models, Shopkeeper, general map background, and fluff creatures added in after the fact (like the little squirrel on some rocks and a snail in the river) are kept on the client side. The fact that the client has all these models is one of the reasons LoL is many gigabytes large.

Transferring all this data from server to client would be hellish, not to mention chew through bandwidth usage just to do it all again next game.

So how is it solved then? Each player just sends ONLY the data that matters to other players in the game to the server. No one needs to know whether you have 5 seconds left on Q cooldown, or that the Deep Terror Thresh Skin creates bubbles for you. Things that get passed along in-game are things like, Vel'Koz casted Q, Viktor moved to the left, etc...

More explicitly, in relation to loading screen, as you brought that up, things that happen there are things like mid patch patches, which every player needs to talk to riot's servers about before the game starts, secure connection handshakes, and anti cheating protocols.

NOTE:

If you want to look around at what stuff the client has, and therefore, the server doesn't pass you, find the C:\Riot Games\RADS\lol_Game_Client\Projects folder (that might be a little off, pardon me I'm working off memory right now) and find a .RAF file unpacker online. Then you can see all the stuff that's housed locally like loading screen splashes and skin textures, even champion skeletons.

\$\endgroup\$
  • 1
    \$\begingroup\$ It seems like the obvious way to implement this would be to have the client request (from a dedicated asset-server) any assets it doesn't already have stored locally, and when it receives them, it adds them (semi)permanently to its local persistent store on disk. That way assets are only downloaded once, and only when they are actually needed. (Once that's working, an optimization would be to pre-populate the client's local store with assets that are very likely to be needed. This would reduce the game's startup time on first connect, at the cost of making the game's installer package larger) \$\endgroup\$ – Jeremy Friesner Jul 20 '17 at 3:38
  • 1
    \$\begingroup\$ @JeremyFriesner Why would that be the obvious way? That sounds worse than the current implementation outlined in this post, which has you install all of the assets ahead of time so that you have them immediately available when you need them. It might work out okay for a single player game, though I think a lot of people would prefer a longer installation time (and more disk space usage) over having to constantly wait for new assets to be downloaded during play. \$\endgroup\$ – Anthony Grist Jul 20 '17 at 12:22
  • 2
    \$\begingroup\$ For a multiplayer game? Absolute disaster. You don't want to keep every other player waiting to start the game because one person has to download some assets they've never needed until now. \$\endgroup\$ – Anthony Grist Jul 20 '17 at 12:24
  • 1
    \$\begingroup\$ @AnthonyGrist That's why many games like league of legends require a player to have all game assets downloaded before joining the queue to find a match. This works out much better than having the game lag while you wait for a large asset would work. Keep in mind that in this genera of game, players get excited over a 10 ms reduction in ping and often are playing with < 50 ms of ping and can tell if that jumps to the 100 to 150 range. Waiting to fetch an asset during a game would be a disaster in a MOBA or FPS, and if it happened at the wrong time it could even change the outcome of a game. \$\endgroup\$ – JustWannaFly Jul 20 '17 at 14:56
  • \$\begingroup\$ @AnthonyGrist (continued) I guess you could think about it like this. In some multiplayer/competitive games, players trade a longer loading/patching/installation time for a more real time game-play experience by having a client take care of all updating and queue entering. This makes it so only the specific player needing assets has to wait unless (s)he is wanting to join a premade party, then all players in the party would have to wait to enter the queue to find opponents \$\endgroup\$ – JustWannaFly Jul 20 '17 at 15:03
1
\$\begingroup\$

An example of where this was not done was the Elder Scrolls Online, where it trusted the client about the altitude of ground level.

Gold-miners dropped ground level by several feet. They could then walk around "under" the terrain, and mining resources from below without being seen by PCs or attacked by NPCs.

Similar edits allowed them to smooth cliffs so they could walk up them, remove or route under static walls, see through all static objects, etc.

Essentially, the server trusted the client about the location of the player, calculating collision on the server side for every single player against all statics would be quite heavy.

In tile-based games like Furcadia, however, it's different: every square you move into has server-side walkabilty, and the server doesn't need to trust the client for anything: the server knows and validates every movement and user action, and the client only displays the action when the server tells it the result.

\$\endgroup\$
  • 1
    \$\begingroup\$ TL;DR: Always assume that the client is a lying, cheating, bustard. But server validation of everything lowers your capacity. \$\endgroup\$ – Draco18s Jul 20 '17 at 20:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.