Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Idea! a more efficient netcode architecture

Discussion in 'Suggestions and Feedback' started by puttyEngineer, Feb 10, 2018.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. puttyEngineer Trainee Engineer

    Messages:
    35
    I'm pretty sure everyone wonder how SE's Multiplayer can be better, I wonder this as well, but yesterday I got a brilliant idea that I'm soo excited to share! I wanted to do a proper presentation but I just couldn't wait!

    Here's the basic idea in a sentence: "Client-based-physic-authority managed by dedicated server with flexibility".

    Everyone at Keen probably already know about this idea; you can't do Client based physic authority because Client might cheat! but if you back up just a bit and trust the client then you will see huge opportunity to reduce server's load and improve user experience as well.

    The problem with SE is this; Server simulate every aspect of the world Physic/logic and due to this omnipresence is the reason it always be the first to restart due to performance issue, in addition to that; client-server-then-client back-&-forth messaging mean that every user action is taxed by network delay and user's action also effect the sim-speed of another user hundred of Km away.

    A proposed alternative will solve all this problem by using player's computer as a cooperative solver for physic/logic of the entire game world.

    How you can attempt to do this is very simple;
    1st) the Server, as expected, contain all the list of Physic object in the world,
    2nd) the Client, as usual, will query all of the important Physic object for the user, such as all the blocks within 'visible range' of user, and the Server will reply such query with a data containing the relevant Physic object, which the Client will then read & replicate inside a local SE program to display a smooth Physical object for which the user can interact with, which is unknown to user is 'corrected' or updated using the objects from the Server every second.
    3rd) the Server, now with an improved architecture, will flag several objects in game world with an information that instruct the Client to update these objects with its own Physic & logic information on behalf of the Server. The Client continues querying objects from Server but it also update the Physic/logic of the object into Server. The Server now stop replicating Physic of the object, thus saving CPU power. Of course, the Server select which object to be updated by Client, such as Client's ship or a bubble around the User, and resume Physic simulation if the Client cease to do it.
    4th) the Client, now having 'Server' authority of objects around the user, will experience zero latency & zero desync when it is isolated from other Client, but when 2 Client is within some interaction distance; in order to avoid complication; the Server regain authority of all objects and assume a dedicated server role.

    In summary, the best case scenario of this Multiplayer architecture is when all Physic/logic load is handled by all connected Client whom is playing on isolated bubble in the game world, and in worse case scenario is when the Server handles all Physic/logic load because all Client is sharing the same space.
     
  2. Rovex Trainee Engineer

    Messages:
    8
    I dont pretend that I understand all of this but is this like a sort of botnet for servers, using the power of the clients computers to run the server? Great idea. but I think you could get some sort of desync when a clients computer is a bit to slow to send the updated information back to the server, this could result in another user not being able to see an updated block at this point the server doesnt know what to do since a user does have a block, the server doesnt and another client doesnt.

    Just my quick thoughts and I could be totaly wrong about this.
     
  3. puttyEngineer Trainee Engineer

    Messages:
    35
    Hi! My idea is that Client do nothing different if other Client is around, they only act different if other Client is very far away; at this point the Client will upload Physics & Logic status onto Server (updating it) in addition to Character status, but if they have friends then things will have to return to normal where Client only update Character status while Server update Physics & Logic and send it to Client. The intention is to simply point-out this very specific case where the Server could save some CPU use; saves Physic & Logic calculation when Client is alone.

    About Desync & update lag, I think this should be solved at very low level & not at netcode architecture; it should be default that all Client have a code that check for data error and automatically re-request & re-resend data until it gets thru; the upper level (the architecture) should not have to deal with missing packet & Desync. Also, by default the engine must make sure that each data that arrives from any Client/Server is compatible with the current time-frame (not for the future or for the past!); so if a Server is ahead then the Server will detect a mismatch and slow down itself to allow Client to catch up, and if Client is ahead then Client will slow down instead and allow Server to catch up; everything at low level should continue until the time matches; this is what we are used to as SimSpeed matching.
     
    • Informative Informative x 1
  4. sioxernic Senior Engineer

    Messages:
    2,535
    @puttyEngineer The server still has to verify what the client does is fair game and not cheating. Games that offload stuff to clients and has client trust is games that is pretty darn easy to cheat. Planetside has the clients do the hit detection and runs the physics on vehicles they are in, making it very easy for people to cheat. They don't even have to use an aimbot, since their computer can literally just send out "I hit you in the head!" to the other players (Peer2Peer network).

    And if you make the server slow down for the client to catch up, you will see even more severe serverwide sim issues if someone logs in with a sub optimal computer.
     
    • Agree Agree x 1
  5. Syncaidius Junior Engineer

    Messages:
    824
    If SE wants to keep it's PVP aspect, this won't work at all. Giving clients any kind of control/authority over physics simulation would be open (widely) to cheating. During the period where the server hands over physics simulation of an object to a client, that client could try to teleport that object 500,000km away without a jump drive simply by telling the server it moved 500,00km. That opens another can of worms, because as @sioxernic menioned, the only way to prevent that is if the server validates such things and corrects them, which means it would still have to run anti-cheat tests before accepting a 500,000km teleport. That would likely involve running physics simulation on the server to figure out it's velocity, orientation, collision, etc. That's not even considering the fact it would still have to check if the object is even equipped to jump to begin with.

    So, it's cheaper in terms of CPU resources to simulate it on the server and let the server decide where objects should be, while the clients predict how they should/can move between server packets. This way, you avoid wasting extra CPU validating how and where things should be after clients simulate them in order to reduce cheating. It also avoids unnecessary complication of the networking system.

    The only area you can really give way with this idea is the player/character object. Even then you'd still need to check how far and how fast they're moving within a period of time to detect whether they're trying to cheat by moving faster than the maximum character speed (i.e. teleporting or warping).
     
    Last edited: Feb 23, 2018
  6. puttyEngineer Trainee Engineer

    Messages:
    35
    No, cheating should not be a problem, casual cheater should be blocked with dedicated anti-cheating software like VAC (Valve-Anti-Cheat) or BattleEye (which is used by PlanetSide2), and pro-cheaters (hackers) can be blacklisted directly within the server and kicked by Admin. Slow client shouldn't be a problem as well; they can be kicked if the Admin choose to. So, I don't see cheating as an obstacle to Client trusting architecture. I've played PlanetSide2 and I almost never meet any cheater, yet my experience of PlanetSide2 is very good; the game is very responsive and I rarely encounter network issues and I've never seen any Physic glitches.
     
    Last edited: Feb 24, 2018
  7. sioxernic Senior Engineer

    Messages:
    2,535
    @puttyEngineer
    Fun fact, VAC gives an excessive amount of false positives. Planetside 2's anti-cheating is so insanely bad that it barely works and quite a few cheaters are found because their character or vehicle is doing impossible things and only discovered because of Youtube videos of the offender. VAC didn't catch prominent high level competitive Counter-Strike players.

    Cheating is not just a "Look Anti-Cheating system! Boom we catch all of them". You might think you never met a cheater, but believe me, no matter what multiplayer game you have played, you have experienced multiple cheaters... Cheaters just don't run around with aimbot on and headshots every time you come on a screen, because that is dumb. Cheaters generally attempt not to get caught.
     
  8. puttyEngineer Trainee Engineer

    Messages:
    35
    @sioxernic , we wouldn't be able to stop professional cheaters in SE either, early this year an Admin of a server I'm playing told me a hacker teleported my stuff while I'm idle in game, and this cheating happened in the current Server-authority system; we haven't gone to Client-trusting yet but cheating is already possible.
     
  9. sioxernic Senior Engineer

    Messages:
    2,535
    @puttyEngineer If that is true, there is a certain level of client trust already build into the game.
     
    • Agree Agree x 1
Thread Status:
This last post in this thread was made more than 31 days old.