This site has been archived and made available for preservation purposes. No edits can be made.

Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Syncronisation design

  1. #1
    Member
    Join Date
    Jul 2011
    Location
    South East United States
    Posts
    69

    Syncronisation design

    Let's look at Quake 3. It's spawned hundreds(maybe thousands) of great games, with properly syncronised multiplayer. How? It uses events. Let's make up an example of what some events might be:

    ENTITY_EVENT_SHOOT
    ENTITY_EVENT_DIE
    ENTITY_EVENT_MOVE <- unsure about this, they might of synced what buttons were being pressed/held every update
    ENTITY_EVENT_LOOK <- unsure about this too, viewangles might be sync'd every update
    ENTITY_EVENT_RELOAD

    and so on... The outcome is a nice and efficient level of syncronisation which is not too bandwidth intensive. I believe that if we can implement something like this for Vault-MP, we can have a fully functional multiplayer that doesn't lag.

    There would ofcourse have to be some "adaptions". For example, only sending events if the event would be meaningful for the client. Let's say Malcolm is on the bottom of the map, and Sally kills a mole rat at the top of the map. This event shouldn't be sent to Malcolm because he wouldn't know it ever happened, or would it affect him.

    As for NPC's, they'll have to be executed server side. . .

  2. #2
    Administrator
    Join Date
    Jun 2011
    Location
    Germany
    Posts
    1,057
    Blog Entries
    5

    Re: Syncronisation design

    The next revision will use the API I wrote, which features very fast query of the game data. While not true events, this should work out pretty well too; compared to the 'old' system in the current revision 134, it's up to 28 times faster (~700 function calls per second when no CPU limit set, old was around 40)

    Events are triggered when the received game data differs from the cached values (e.g. the player position changed). Network packet will be immediately constructed and send to the server. The old system was similar, but suffered from the fact that it received so few game updates per second that lag was inevitable. Unfortunately I will have to write some real game event hooks, such as "Drop Item", "Pickup Item", "Use Item", because there is no way to know whether the player dropped or used an item (the only info we currently have is "it's gone", "it's there&quot

  3. #3
    Member
    Join Date
    Jul 2011
    Location
    South East United States
    Posts
    69

    Re: Syncronisation design

    Not using events for shooting and moving is what has made infinite ammo, teleportation, and godmode possible in samp. I believe that cheating may become a serious issue once the project has grown.

  4. #4

    Re: Syncronisation design

    [quote author=Houstin link=topic=151.msg1269#msg1269 date=1314397956]
    Not using events for shooting and moving is what has made infinite ammo, teleportation, and godmode possible in samp. I believe that cheating may become a serious issue once the project has grown.
    [/quote]
    the community will help with anticheats system.
    Game Developer, Modder & Webmaster.

  5. #5

    Re: Syncronisation design

    [quote author=Houstin link=topic=151.msg1269#msg1269 date=1314397956]
    Not using events for shooting and moving is what has made infinite ammo, teleportation, and godmode possible in samp. I believe that cheating may become a serious issue once the project has grown.
    [/quote]
    We have some pawn experts to develop such plugins, and the way they get their ammo, etc.
    Checking their rounds VIA a script might work, and for teleporation, noticing a big change in numerals of the chords will make it obviously to the admins, a warning but certainly not a ban.
    -Aleks


    I just come here to view whether there has been any progress or not, and review the wonderful progress that Recycler and the development team has made.
    My sincere thanks goes to them and to others who value my contributions the community, not to mention the ones that solely contribute.

  6. #6
    Member
    Join Date
    Jul 2011
    Location
    South East United States
    Posts
    69

    Re: Syncronisation design

    Anticheats make cheating harder. They simply limit how much you can cheat. On the other hand, prevention makes cheating impossible.

    Anticheats have false positives, while prevention does not.

    Also, there will be no reliable method to check for godmode, without having ridiculous amounts of false positives.

    Last time I played SA:MP, in Crazybob's CnR, all you had to do is rob a store to get enough money to buy a gun. Then once you had a gun, you could simply enable infinite ammo and godmode and cheat until an admin notices and bans. I wouldn't doubt it that infinite ammo is becoming easier to detect, but godmode and teleportation will never be completely detectable.

  7. #7

    Re: Syncronisation design

    [quote author=Houstin link=topic=151.msg1277#msg1277 date=1314408659]
    Anticheats make cheating harder. They simply limit how much you can cheat. On the other hand, prevention makes cheating impossible.

    Anticheats have false positives, while prevention does not.

    Also, there will be no reliable method to check for godmode, without having ridiculous amounts of false positives.

    Last time I played SA:MP, in Crazybob's CnR, all you had to do is rob a store to get enough money to buy a gun. Then once you had a gun, you could simply enable infinite ammo and godmode and cheat until an admin notices and bans. I wouldn't doubt it that infinite ammo is becoming easier to detect, but godmode and teleportation will never be completely detectable.
    [/quote]
    What about checking if the player has been shot at and if he has, and hes not loosing any health, banzor.


    I just come here to view whether there has been any progress or not, and review the wonderful progress that Recycler and the development team has made.
    My sincere thanks goes to them and to others who value my contributions the community, not to mention the ones that solely contribute.

  8. #8
    Member
    Join Date
    Jul 2011
    Location
    South East United States
    Posts
    69

    Re: Syncronisation design

    Actually performing the check is the difficult part. You have to trace a line's, cylinder's, or box's position all the way where it starts to where it ends, and check for any collisions in between. Even if this was managed to be done, it would suffer from desyncronisation inaccuracies, and would still cause false positives. However, if each client is sent something that says a client fired a weapon and where he was aiming, they can do the collision detection and damage calculation on each client. The actual concept for this is complex, and I am not able to explain it at this time .

    I should also note that Quake 3 sends multiple updates each packet. For example, consider the following code from Quake 3's source:

    typedef struct usercmd_s {
    int serverTime;
    int angles[3];
    int buttons;
    byte weapon; // weapon
    signed char forwardmove, rightmove, upmove;
    } usercmd_t;

    These are in an array and are populated and sent each packet. Oh, Call of Duty 4 compresses each packet with huffman. Punkbuster compresses it's packets with zlib, a compression library that guarantees it never makes the data bigger than it originally was. I'm not sure what if any compression RakNet uses, but I'd suggest zlib if it doesn't have any.

  9. #9

    Re: Syncronisation design

    [quote author=Houstin link=topic=151.msg1411#msg1411 date=1314610732]
    Actually performing the check is the difficult part. You have to trace a line's, cylinder's, or box's position all the way where it starts to where it ends, and check for any collisions in between. Even if this was managed to be done, it would suffer from desyncronisation inaccuracies, and would still cause false positives. However, if each client is sent something that says a client fired a weapon and where he was aiming, they can do the collision detection and damage calculation on each client. The actual concept for this is complex, and I am not able to explain it at this time .

    I should also note that Quake 3 sends multiple updates each packet. For example, consider the following code from Quake 3's source:

    typedef struct usercmd_s {
    int serverTime;
    int angles[3];
    int buttons;
    byte weapon; // weapon
    signed char forwardmove, rightmove, upmove;
    } usercmd_t;

    These are in an array and are populated and sent each packet. Oh, Call of Duty 4 compresses each packet with huffman. Punkbuster compresses it's packets with zlib, a compression library that guarantees it never makes the data bigger than it originally was. I'm not sure what if any compression RakNet uses, but I'd suggest zlib if it doesn't have any.
    [/quote]
    I totally understand the concept given, and I understand the part where I was wrong .


    I just come here to view whether there has been any progress or not, and review the wonderful progress that Recycler and the development team has made.
    My sincere thanks goes to them and to others who value my contributions the community, not to mention the ones that solely contribute.

  10. #10
    Member
    Join Date
    Jul 2011
    Location
    South East United States
    Posts
    69

    Re: Syncronisation design

    The concept that I mentioned but did not explain was how the server handled the data. I decided to ask one of my friends, Google. He seemed to know a lot about this and gave me the following useful links.

    https://warriors.eecs.umich.edu/games...quakefinal.pdf
    https://www.bluesnews.com/abrash/chap70.shtml
    https://www.gameproducer.net/2006/12/...-network-code/

    The last one is exceptionally great, because it references efficient RakNet programming, along with some other network models.

Similar Threads

  1. New Forum Design
    By Dantiko in forum Discussion
    Replies: 6
    Last Post: 10-20-2011, 11:34 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •