1
\$\begingroup\$

I've been working on project for quite a while, and I've returned to dilemma about level loading. The problem is i trust the client with it's local level loading, when it's done loading it tells the server to join it to server room data stream and server start to send data.

My current setup

  1. Client logs in, on login server sends the characters.
  2. Client chooses the character and start to load level locally.
  3. When client scene done loading, it request to add to room.
  4. Client receives the data he needs.

I fear that user could hack the client and actually load other scene, that would result in players and characters going through props and models, it could also be an exploit to see hidden data and items.

Instead, after server sends the chosen character it could "wait" for user to send response that level has finished loading. After that, server joins the character to room and send data to the user. That way client doesn't know anything about rooms or it's names.

Any suggestions?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ You're heading in the right direction. Servers should never trust clients, ever. Because somebody, somewhere, somewhen, is going to try to take advantage of whatever they can. You will need public names for levels and stuff, though, or your client won't know what to load (or communicate a choice the player made). Why was the client choosing the character location in the first place? \$\endgroup\$ – Clockwork-Muse Mar 7 '15 at 15:01
  • \$\begingroup\$ The server tells the room name and the vector point, when level has loaded and character placed in that position, client asks the server to join that room with that particular name. \$\endgroup\$ – Scavs Mar 7 '15 at 15:14
  • 1
    \$\begingroup\$ First, there's no way to avoid giving the client the room name (it has to ask for the room somehow), and for optimization reasons usually all static room data is distributed to clients too (ie, the last boss fight is usually included, along with all the story lines, etc.). Don't bother stopping people reading this data (other than basic countermeasures) - after all, if your server doesn't trust the client, it'll reject all nonsense commands ("loot chest in room I'm not in..."), and nothing they do will affect the character stored on the server. \$\endgroup\$ – Clockwork-Muse Mar 7 '15 at 15:21
  • \$\begingroup\$ Indeed, but the room name isn't the local level name, it's the servers "room" name to join, i doubt that i should sending it. Maybe i could simply get the scene loaded event from the client and then join him the "room" stream. \$\endgroup\$ – Scavs Mar 7 '15 at 15:34
  • \$\begingroup\$ @clockwork-muse I think you should elaborate on that further and make that an answer. \$\endgroup\$ – akaltar Mar 7 '15 at 18:14
1
\$\begingroup\$

What you have described is roughly how we did it in Reclamation (Underlight sequel). The client sent a room change request and started loading the level, but before the client was allowed to move around after loading finished there was an acknowledgment required from the server.

The game had a major PvP element to it, so this syn/ack system was as much to prevent cheating as it was to make sure other players in the vicinity were informed about the new player entering the area before they were allowed to be attacked. Players in the room that had not yet acknowledged the new player's entry were invulnerable (invisible, actually) so as not to give the entering player an unfair advantage.

The server also had a graph of connectivity between all rooms in the game. It knew trivially if a compromised client tried to jump to an invalid room. A system that combines both of these things should take care of the problems you have described.

|improve this answer
\$\endgroup\$

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.