I've been thinking about the problem and making another experiment, which seems more successful.
The basic idea is that games send multiplayer data at a generally steady rate and the timings are predictable. When the host sends a CMD frame, generally there won't be anything else being sent (other than replies and ack) until the end of the CMD_COUNT window, unless some clients failed to reply. The only exception to this is when the host sends a beacon frame, but since these are sent at a fixed interval, it's not hard to take them into account.
I had to do a few tweaks to get it reliable in certain situations, but so far it gives quite a substantial speed boost and doesn't seem to impact reliability. We still have to see how this goes -- we might have to make it optional if it causes problems somewhere.
I'm also trying to fix some other problems, namely how in some games you can't connect more than two players. I have a bit of an idea what's going on, but I'll need to work on it more.
We're also thinking of bringing back LAN, but as a proper LAN mode instead of just tossing packets around the network. It may even possible to build something robust around enet. I'll have to give this a try.
|
|
16 comments have been posted.
|
