Search Unity

How much game code should run on my server?

Discussion in 'Multiplayer' started by dev1vrtron, Oct 11, 2019.

  1. dev1vrtron

    dev1vrtron

    Joined:
    Feb 11, 2019
    Posts:
    2
    Hello!

    I'm using GameSparks for all my server-related stuff.

    Until now, I've been mostly coding everything in Unity and just sending GameSparks updates on data or state changes. For example, if a character levels up, I calculate its stat upgrade chances locally, new abilities, perks ,etc... and then send an event to GameSparks with my new updated player data.
    (local) player levels up, do calculations, send new values to server -> (server) updates database, returns successful operation message

    Now, should I be doing all those calculations on my server and just receiving the result? Something like:
    (local) request player level up -> (server) do all level up calculations -> (server) return new values, update database -> (local) update current loaded player state and game UI.

    Are both approaches valid? I know that the second one is more secure (although gamesparks supposedly encrypts all your info so the first one should also be safe as long as he local game doesn't get hacked), but would it be more expensive?

    I'm trying to find information on this and can't seem to get my way around it.
     
  2. MrsPiggy

    MrsPiggy

    Joined:
    Jun 13, 2018
    Posts:
    154
    If you trust the client you're asking for trouble. That's pretty much a basic mantra for mp games. And for good reasons, imho.
    Exactly. Encryption only protects you against eavesdroppers, but cheaters will decompile your game code and figure out how to send custom data.
    Expensive in the sense that your service fee (game sparks) will be higher?

    Yes indeed
     
    Joe-Censored likes this.
  3. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Verify as much incoming data to the server as you possibly can. So I do all the calculations locally for local display of information and determining if a message should be sent to the server in the first place, then on the server verify the input is valid. This reduces the available avenues to cheat in your game.

    Simple example. Lets say your game allows the player to fire their weapon every 0.5 seconds. You'd track this firing rate on the client, not allowing the client to send another "fire" message to the server until at least 0.5 seconds have passed. On the server you track the same thing, not allowing the processing of another "fire" message until the player should be allowed to. You might be a little more forgiving on the server to allow for some inconsistency in travel time of incoming messages from the client, but on the server you don't allow a rather slow firing weapon to be turned into a machine gun when the player uses a cheat program to modify variables tracking the shooting timer on the client.
     
    Last edited: Oct 11, 2019
    MrsPiggy likes this.
  4. LukeDawn

    LukeDawn

    Joined:
    Nov 10, 2016
    Posts:
    404
    Just to complicate matters, there is also a cut off point where you have to say "is this really game-breaking" if the client handles something on it's own, to relieve the server of having to do everything, and likely slow the game down for everyone.

    For example, in a number of games, basic collision detection is done client side. Only if a number of people report a player, is that player monitored.

    Obviously, making the server fully authoritative is the the golden solution, but that's not always possible or even necessary. Remember, you can start small, and if you ever reach thousands of players, you'll have enough cash coming in that you can afford better servers, and load them up a bit more. If you only have a small but happy community (yeah, happy - in an mmo community - ikr), you might let the client do a bit more.

    Get the game out there, then tailor it to suit. Fail Faster. You're not making a WoW killer (It's never aliens!).
     
    Jos-Yule and MrsPiggy like this.