UDP is often very suitable for networked games, but generally for this case the game engine is built in such a way that data loss is acceptable. The "slave" has their input acknowledged only when the "master" later tells them it happened. Letting the "server/master" run normally with all the lag/unreliability pushed onto the other players can sometimes be much more straightforward to implement than other techniques. You only need a symmetrical experience if the game is competitive in a way that short scale timing makes a difference. I've enjoyed emulators with netplay occasionally, especially over LAN, so I think it's not a bad feature to consider for one. And I have seen people implement things (including in commercial games) so utterly wrong that it's baffling. You're entering a completely different world of completely different pain. My general suggestion to people is: don't bother implementing netplay in emulators. It's going to vary based on several variables, absolutely none of which your emulator/game/whatever has control over. The buffering methodology Tepples describes (re: the emulator working on input 4 frames behind what's active) is commonly used, but the problem is that 4 frames is sometimes too little, or in other cases too much. I have a few, but they're all dedicated to graphics, level design, algorithms, and things of this nature.
Possibly this type of thing is discussed in an actual published game development book.
#KAILLERA PEER TO PEER CLIENT NESTOPIA CODE#
All I've seen are commercial companies writign their own proprietary methodologies (which makes sense to some degree), and open-source nutbags saying "look at some crap I put on github the code is the documentation" (wrong).
I have yet to see anyone publish anything like this. I will not pontificate on all this this past this point my statements (especially about the code aspect) sound anecdotal but honestly I'm really preaching fact.Īll that said: if you find something online somewhere that actually documents the design and architecture of a realtime gameplay protocol (TCP or UDP, I don't care which), I'd love to read it. A common example are packets that arrive out-of-order due to intermediary routers and load balancing on the Internet (and to some degree even NAT routers) there's a common misconception that if machine A sends packets to machine B in the order of 1,2,3 that machine B will receive them in the order of 1,2,3. (The latter is somewhat difficult, which is why using a language like C makes this easier - anything that is abstracted is going to make that task even harder). The biggest problem I find is that the programmers using the underlying syscalls/code for sockets do not actually understand 1) how individual descriptor flags affect what is going across the wire, and 2) have no real familiarity with packet analysis to determine what is going on and correlating that behaviour with actual code in their application. Those reimplementations may be better for your application - it's up to you to decide and do the analysis - but it's time not well-spent, IMO. Use UDP if you want, but you're going to end up reimplementing pieces/parts of TCP like Tepples said. TCP selective acknowledgement (SACK) per RFC 2018 further extends this in the case of packet loss.
The "use UDP because it's fast" mentality is only applicable in one scenario, and that's the handshaking nature of the protocol - which for large payloads isn't even used any more given how the TCP sliding window algorithm works (RFC 1323): you no longer need to send an ACK for every single packet). And for sake of example, WoW and many other modern games use TCP. Tepples wrote:By the time you've implemented reliable delivery of input packets over UDP, with error detection and retransmission and the like, you'll end up having reimplemented most of TCP. If it hasn't arrived emulation freezes until it does On current frame check get own input from buffer and check to make sure input from other player has arrived. Save own input to buffer for local machineĦ. Frame to execute = current frame + delayĥ. Send input every frame with the frame it is to execute on. Ignore first X frames where X = frame delay since you can't possibly have any input from the other player.Ĥ. Synchronize emulator startup/loading of romģ. Determine number of frames to delay input (typically half the ping rounded up to the nearest integer or +1 frame for margin) on local machine by measuring average ping time over a time interval.Ģ. Especially if more than a few frames have gone by.ġ. Typically you want to use UDP as your method for sending packets for these reasons.Īlso most NES games aren't set up to take advantage of prediction since re-emulating the frame really isn't an option in a some games.
0 kommentar(er)
