Has anyone here actually used this method of multiplayer prediction? As in perhaps at some point in the future they''d be willing to share the code?
After reading up a whole bunch if articles on it and giving it some though I was thinking that when you are use this method the prediction can only ''be so good'' and that obviously the more often you update the clients the better.
So I came up with the follow:
-IP Multicasting from the server process or to other client in peer to peer.
-Rather than sending an updated x,y,z and p,y,r to each client you send delta''s with say every 5th update(maybe 1 sec) giving the real location of the player. Reason I though of this is that in most games a player can only move a small distance in a few milliseconds. If we can rely on this (no regular teleportation) then we can used a smaller number for the network copy
I''m really concerned about this as the game I''m planning is multiplayer only and people are used to playing game made by much more experienced developers who have testing experience in knowing when the most efficient means are. Additionally I''ve only been coding in c\c++ for a few months (though in basic for 17 years) and am hoping that I don''t miss any major optimizing techniques.
The nature of the network needs to be consider in your design. Handling loss, latency and out of order packets are the main issues. Sending deltas only would not work if there was high loss or rate of out of order packets. The more time critical your game (ala Quake or other action games) the more important timming synchronization becomes. If your making a turnbase game it''s less critical. From my experiements, using TCP is sufficent for most applicaitons, even action games, if you don''t saturate your bandwidth. Multiplayer prediction comes down to timmer synchronization. The equations of predicting a projectile or players position into the future or past is only as accurate as the the clients timmer synchronization to the servers. Compression of large packets can be achived through the use of freely available libaries (zlib) and is a good idea. However action games have packets in the range of 5 - 50 bytes and are below the domain of tradaitional compression algorithims. For this you might want to build a custom compression libaray. Even a 15% savings per packets will greatly reduce your bandwidth consumption thus lowering network overflow and stalls which results in unpredictable high latency. Good Luck!
Are there any good discussion papers etc around on timing schemes, pro''s \ con''s.
Like maybe: Server heartbeat Client ack''s Server ack-ack''s
That way the client and server can measure the latency. Or should the occational data packet include a time stamp?
If I use TCP do I not have to worry about guaranteed delivery? Originall I was thinking about using both protocols, tcp for critical game state information, and UPD for anciller information that don''t really affect gameplay that much like, scores, player messages, player skins etc.
That way the overwheled client can safely drop score packets, skin changes etc without loosing sync state.
I have found a description of something called the ''lockstep'' method, which seems a little complicated for my skill level(prebuild predicted worlds based 100% on delats since game start with trickle changes for new copies for full game worlds...ick!)
Are the any repositry around that discuss different methods?