Search Unity

Concepts of Cheat Protection in a physics based Network Game

Discussion in 'Multiplayer' started by SGtRumpel, Jan 19, 2015.

  1. SGtRumpel

    SGtRumpel

    Joined:
    Mar 16, 2014
    Posts:
    13
    HI there,

    We are currently working on a kind of arcade multiplayer racing game with physics. In Unity, the physics in Network are a bit of a nightmare because of the lack of prediction possibilities. That means, either you have an input delay (authoritative server) or, as you can't make any physic predictions on client side will have to use another client/server model. Currently we are thinking about doing a kind of client-side physic simulation, which, as many of you may know, has the problem of being cheat-vulnerable.

    So we are currently working on a semi-authoritative server - and would like to have your opinions on our (maybe kind of unusual way) of dealing with physics in network AND having some kind of cheat protection:

    Our racer supports some abilities that affect the enemy racer and we have some kind of "energy" which allows to use these abilities. Our Client-Server model would be like this:

    1. Everything concerning physics is done client-side and the server corrects its own simulation and passes the position to everyone else in the network. The client is right and has a responding experience concerning controls. He competes against enemies, that are slightly in the past. If two players collide, the one with the lower ID wins and the one with the higher ID will be repositioned.

    2. Everything concerning abilities and collecting energy (there are like energy orbs on the track) will be done by the server, only a visual representation will be seen on the client. That means, he may experience slight delays when collectiong items or using an ability, but like that the server has the control => save concerning cheats.

    3. If the server notices any inconsistence in speed or position, the player will get a cheat-flag. If the player accumulates enough cheat-flags, the whole game will be recorded serverside and we (the developer) are able to re-view the entire game and see for ourselves if the player really was cheating. If so, he will get banned.

    4. We will implement a kind of social anticheat-system, which is similar to the ones in MOBAs like League of Legends, where you can honour or report a player. If the server AND players have the same concerns about a player cheating, its probability to get checked by a human team will increase.


    What do you think about this approach? Would this be a viable way? We are an indie-studio with limited resources, we can't program our own deterministic physics engine or license and implement something like bulletphysics, which would us allow to do client-side prediction.

    I would greatly appreciate any thoughts about this,
    Maenny
     
    glitchers, sluice and TH_Unity like this.
  2. Genkidevelopment

    Genkidevelopment

    Joined:
    Jan 2, 2015
    Posts:
    186
    Good luck...

    Although I know nothing of what you are describing... Eradicating 'cheats' is something I feel Game Developers should be doing more of... Most of the games I enjoy, their leader-boards are nothing more than a 'who has the best cheat' model!

    So kudos for tackling the problem nice and early :D

    Hope you find a system that's viable and generates the right results for you...

    Peace
     
  3. Nuvasuper

    Nuvasuper

    Joined:
    Aug 13, 2013
    Posts:
    1
    Is there a particular reason that the collision authority (which client's model is used) is based on ID numbers? Why not have it randomly determined each time there is a player-player collision? It seems like if someone did intend to cheat, they would have a lot of power if they managed to get a low ID number.
     
  4. SGtRumpel

    SGtRumpel

    Joined:
    Mar 16, 2014
    Posts:
    13
    That's just for convenience :) The ID can be set to begin of each game and be chosen randomly. I think for determing it each time, you'd always have to communicate and synchronize the current hierarchy, whereas setting it once to begin of the match would make extra synchro unnecessary.