It's gonna be fast paced shooter (with Mass Efect 3 multiplayer mode as huge inspirrationso tcp is not an option, maybe useful for chat or sth but not for gameplay. I started with sending input because it was a simplest step but as SilverWarrior mentioned it's not gonna do because dropping some packets will break the gameplay. I guess I'll have to pack world state in a packet like that steam article suggests.
Your networking model sounds similar to mine - synchronization of actor properties using thread safe messages by using the network connection as a message relay. I'm currently using both TCP and UDP for communication. Individual properties are marked as either 'critical' or not along with a priority. critical, low priority messages through TCP (game state control, player chat etc) non-critical, high priority messages through UDP (rotation/heading without projectiles) and a blend between them for all other things. You can do packet confirmation on critical messages sent thru UDP for both speed and reliabilty but not bother with confirmation for things that don't really matter or would otherwise quickly get superseded.
For example for the position of a player, you can send one critical update to the position each second and inbetween those as many non-critical updates as the bandwidth allows for. So you could theoretically only get the critical update each second. Then you can use prediction combined with lerping like Quake3 net code etc to make the motion seem smooth for other players.
The nice thing about this is that marking a packet as non-critical / low-priority allows you to dump it or move it down the queue when a new critical/high-priority message comes in for sending. It's a total win to implement as theoretically your stream of messages could suffer such disruption anyway over UDP, all you're doing is juggling to squeeze out the real-time performance factor.
accurate timing sync + timestamps are critical for the setup, I recommend that you make timestamps an inherent part of your message structure. I connect my server messenger to my client messenger internally without networking and introduce artificial delays to the pumping of the queues and random message drops in order to simulate something approaching an unreliable internet connection. If you do this then your net code is no longer important, you can do the hard part of dealing with sync/delay in your own ecosystem and when it's done, just stream your messages through whatever TCP/UDP you fancy and job done.
To put simply, the networking code in this context becomes a message relay with a fast,unreliable path and a slower,reliable path. You could just use UDP and have a system for re-transmitting lost packets, and re-ordering them and while this can be faster than TCP in some scenarios, that is the fundamental difference between the two, TCP is basically UDP with packet re-transmission and re-ordering. There's no performance hit at all to using both TCP/UDP and the TCP path means any UDP packet reliabilty code can be non-existant or just very simple.
Last edited by phibermon; 27-12-2013 at 05:40 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
thanks for some ideasworking on this feels refreshing
You're welcome, I've given a lot of thought to this messaging model of net code, always happy to share ideas.
I actually have nearly every part of my engine as a messenger along with clientID's and routing. you can do bizzare things like run your sound manager on a different computer and have it recieve the sound messages from local or network requestors. My GUI is the same, mousemouve/onclick/hover etc messages. I can actually do something similar to X and have a window/controls on one computer sending all the messages back to the actual app instance on another computer.
The messenger/actor model is very powerful! well worth any performance penalties!
EDIT : Just in case anybody doesn't know, UDP packets don't always arrive in the same order you sent them and sometimes they don't even arrive BUT if they do arrive, it is garunteed that the data they contain is complete and CRC checked.
Last edited by phibermon; 30-12-2013 at 06:32 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
I guess that the best approach for multiplayer games, is to build the game around an IRC server/client architecture. One thing I was wondering about, is to do something around bittorrent as it may grant an option to build a serverless multiplayer game. Also have to be aware that any multiplayer game will suffer from lag (it's not a secret), no matter how well you code your network layer or the protocol/transport you use. Anyway you may timestamp your packets or set some way to tell priorities or number of packets before any action happens. Just my opinion.
"something around bittorent" are you serious? You do know that torrent protocol is just a Per to Peer protocol which alows spliting large files into smaller packets to make data sharing a bit easier.Originally Posted by pitfiend
Using torrent protocol for multiplaye is out of the question as it is optimized for sharing static data between multiple sources. In multiplayer game you have anything but static data.
But yes using of Peer to Peer protocol you can achieve serverless multiplayer. This approach has been used for long time. DirectX was first masievly used framework which alowed that.
But in the end it all depends on your multiplayer inplementation.
Peer to Peer gaming has never been much of a success outside of a LAN, keeping any game state synchronized across such a model in real-time is difficult enough but when it comes to decision points it's nigh on impossible. Say you had 4 players, player one shoots player two. From players 2 state, player 1 didn't have line of sight for the shot, nor did they from player 3's state, but they did from player 4's.
So did player 1 shoot player 2? well without a server you either have to take player 1's word for it (so you're opening the door to cheaters) or you have to take a vote, if the majority say the shot connected, it did etc
But then you have a very quick action (a shot) requiring a quick decision from all or most of the peer to peer clients, which is only going to complete as fast as the slowest clients ergo slowing the game down for everybody.
Yes lag differences between clients can cause similar issues in some FPS games, but the issue would be *greatly* magnified in a peer to peer topology.
Of course you could just take players 1's word for it, but then they could either cheat, or player two is going to uninstall your game because they keep on getting excessivly killed by players with a lower ping who weren't even in the room (from their perspective) as they died.
A server is more than just a physical hub for game clients, it's an essential 'mutex' in the concurrency problem that is network gaming.
Obviously there are slower paced games / mode of play that might be better suited to a peer to peer model but then at the same time, they'd also be even more suited to a client/server model.
Plus you can get away without UPnP for opening up ports on a players router etc in a server model as you're routing out. The moment you rely on UDP / incoming comnnections, you realistically need UPnP code unless you want your forum filled with "can't connect, help!" messages.
Last edited by phibermon; 31-12-2013 at 05:05 PM.
When the moon hits your eye like a big pizza pie - that's an extinction level impact event.
Posting Permissions
Reply With Quote
Bookmarks