[Wish list] Dead Reckoning

edited April 2010 in Photon Server
Hello all.

Dead Reckoning on network level

This simple technology, that needs in almost all games, based on free game clients moving.

"Programmers who attempt to develop games for network play quickly discover the problems of dealing with network latency. Latency is, quite simply, the time it takes packets of information to get from one computer to another across the network and is a function of the path traveled by packets passing between the computers. " (С) Gamasutra. Jesse Aronson.

[*] http://www.gamasutra.com/view/feature/3 ... g_for_.php
[*] http://www.gamedev.net/reference/articl ... le1370.asp


  • Perhaps I'm not fully understanding it but why exactly would you need it?
    I'm asking because normally you would simulate the world fully and only on the server and the client is rendering - input handling.
    In that case I don't see any benefit of it as correct client side prediction will result in the same or better quality especially for each of the local players.

    DR is something you would use if you had no dedicated node for simulation as it is in the case of a WC3 custom game where basically 1 is hoster but all others need to be able to take over if he fails.

    Also hard implementing it is not even possible as the DR contract totally depends on your game, the simulation etc. So it would at maximum be implementable to a degree where you send ints/short/byte to declare the DR simulation type to handle it appropriately on client and server. And thats already doable through the use of Properties :)
  • My game has car racing elements. Usually from 4 to 10 cars may compete on one road. All clients send where it is now + vector of velocity, but this now is actually not "now" from server point of view, this "now" always in past.

    If no DR or other similar algorithm on server side, clients will be desynchronised because network latency. When two or more vehicles start to collide, network latency makes that some of them will skipped from collision.

    Also, PhysiX part of the server needs to know exactly the time and the point, which they collide and each other position for cheat check, damage count, and etc.

    I saw, you making the game where tanks rolling on wasteland, and if they can collide (I don't remember this moment), how do you count collision effects when clients have different network latency?

    >And thats already doable through the use of Properties

    Thanks fro the idea, I'll think how can I use Properties. Actually, DR is not such big deal, I'll have to write algorithm for this if no other way found. I only wish to see in server some classical solutions, that may needs in network game projects.
  • KEMBL wrote:
    I saw, you making the game where tanks rolling on wasteland, and if they can collide (I don't remember this moment), how do you count collision effects when clients have different network latency?

    Right, I'm part of the Reign of Steel team :)
    We do it through the ways explained above. For more indepth informations see berniers paper: http://web.cs.wpi.edu/~claypool/courses ... ernier.pdf
    Thats part of the idea thats used as base.

    Also our server is fully authorative, so there is no case where the server is behind the client. The client only sends input requests and does local client side prediction with that input against a server state from the past.
    Position update etc is up to the server and the server only
  • Thanks for the book, dreamora, I found it intresting!

    In my project when you look at cars what you see on the server is a lot of dead-reckoning based logic. Basically, the idea is that the sever doesnt need to know wher you are every second, it only needs to know when significant things happen. At that point in time, it calculates where it believes you to be and checks to make sure that the significant action makes sense. For instance, when two cars collides, it calculates they current position at the time the collide occurs based on the last cars received position and movement vector. It then checks to see that action are within legal range.

    So, what is server side Dead Reckoning on network level?

    This is only possibility for server business logics to know where something occurs every time when it needs. Also, with step down useless client-server traffic.

    As knowledge exchange, may be you will interest on this link:
    http://developer.valvesoftware.com/wiki ... Networking
  • Optimally, but thats my view, you would have "simulation clients". That are basically cut down clients that do nothing but world simulations from external input.

    These then are run on the server along the Photon server and directly connected to it and do the dirty work of simulating the world, cause at least I personally would want to do it in the same environment as the client simulates (unless you fully implement the client yourself and can just transfer it to the server naturally). Not just for consistency but also if one game fails and some error kills it, it does not touch all other running games and the simulation, with some "ignored timeframe for server checks" could be transfered to a new simulation node
  • Your idea is very close to my own plan. It seems very realistic approach to start several trusted Unity back-ends as clients in game world with several changes in its client code.

    This kind of client, which has its zone of visibility for game events in several game cells, can check this events against its own logics for gameworld manage. The first is check for cheat, and the second as stage-manager / director of game events. Several this clients with intersections of managed zones can build failover grid of game managers.

    The price for this game architecture will be present as small bigger network latency. On other hand, the client is Unity3D and the server is Unity3D, so physics engine will be the same which will provide to cut time for its synchronisation in the process of game develop.

    BTW, it seems like, jashan, make the similar work: viewtopic.php?p=9#p9
Sign In or Register to comment.