2.3.5_rc1 and beyond

[Buginator]

This release (2.3.5_rc1) implements phase 1 of net code changes.

We know all about the cheating that is going on, and in a open source project, with very limited manpower, and making no money on this, we just don't have the time to do a complete rewrite* in order to stop all cheating. In fact, it is pretty much impossible to stop all cheating. Just ask the WOW guys, which isn't open source, and they have tons of man power, and make millions, but cheaters still manage to do it.

Now that that is out of the way, I also wish to clarify some things.
Warzone's engine was never meant to have tons of units online, Pumpkin set it at 100 for very good reasons, we have it at 150, which is still too much for Warzone's sub-systems to handle. IMO.
What's that ? You have a Core i7 980X EE with quad Fermi 480 SLI, with a nice dedicated OC3 connect, so your system can handle millions of units ? Ha! Warzone is terribly inefficient at almost everything it does, and even if you could handle far more units than most everyone else, it will do you no good, not unless you want to give the same system to everyone who joins your game. ( If that is the case, then leave me a PM, I will send you my shipping address. )

The sync issues are two fold, one, everything in Warzone is FPS tied, and the actual sync code itself is still based on the original Pumpkin code, which never worked very well in the first place. I did some LAN tests to verify this, and it also got out of sync very regularly.
We tried to minimize the first with locking everyone to 45 FPS for MP games, but it is painfully obvious that isn't helping much when people play against people who have low end machines. What does that mean ? It means, if the host has a good system, and is chugging away at 45 fps, and the he has some clients running with 45, 38, and 10 FPS, what do you think is going to happen ? The 10 FPS client is going to get buried in messages, with no chance at recovery, the 38 FPS client is also backlogged, but not by that much, and the other client is OK. Since the game is in a different state on pretty much all machines, then you got some serious sync issues going on. I could go on about the other issues that this causes, but let's just say, it isn't pretty.

Warzone's network model is of the hub design. That means, all messages are relayed to the host, and it is the host's job to relay the messages to everyone else.
When client A sends a ping to client B, it goes A->H->B->H->A. The current pings are throttled to prevent congestion, that is why I state they are for rough estimates, nothing more. If you ever played on a LAN, you will see that your normal sub 2ms ping times jump to 5x-30x or more, so it would show 33ms or whatever. Ping has the last priority, and we rather update units / structures / whatever else first before we get to ping.
NOTE, most of the above information is out of date.

*Now where does this leave us ?
Glad you asked!
Cyp has been working on a branch called "newnet" which has since been merged to svn/trunk.
The way the newer net code works is... better left for Cyp to describe fully, but, in theory, playing trunk net games should be magnitudes better in the sync department, and is in dire need of full scale testing. Please test the latest trunk snapshot as can be found here, and again, report all issues you have!

What, you want to know about 2.3's net code future ?
Good question.
The next phase will make it so the host won't "freeze", and maybe some other enhancements.
Then, it is possible we might go to a full client/server model, but that depends on many things I rather not get into at this time.

That is all for now.

[Cyp]

How 2.3 works, when you tell a tank to go somewhere, your client makes the tank move immediately, and tells the other clients to move the tank. The other clients then move the tank, but a bit later. So each client thinks the tanks are in slightly different places. Thanks to the butterfly effect, a bit later, each client thinks the tanks are in completely different places. Occasionally the tanks are synchronised, by teleporting the tanks to the same place on each client, to keep the game from diverging completely. There are lots of problems with this. For example, each client may think the tanks are shooting at different targets, so if there are 8 clients, and each client thinks a different tank was destroyed (and tells the other clients), then 8 tanks are destroyed instead of just one tank. So how fast the tanks do damage depends not only on framerates, but on how many clients are connected, and on whether you tell the tanks to attack a specific target, or let all clients decide which tank is being attacked. If you tell your lancer hovers to attack, and then retreat before any are destroyed, there is often some client that thinks the lancers were in a different place, and that client thinks the lancers didn't retreat in time or that they got stuck behind a wall or something and couldn't retreat, so your safely retreated lancers then suddenly explode a while later. So in 1v1, telling lancer hovers to attack and then retreat is much more likely to work than in 4v4.

Newnet, now in trunk, handles synchronisation by queuing all orders, and executing all orders at the same logical time on all clients, with a logical framerate of (currently) 10 FPS. The graphics is displayed at as many FPS as the machine can handle, by interpolating tank motion between different logical frames. If you tell a tank to go somewhere, there's a short delay before it actually does, but all clients agree on when it started going there. With all clients agreeing on exactly where each tank is, and exactly what each tank is doing, there are no differences at all between the state of different clients, so the butterfly effect doesn't apply. Everything must be calculated in the same way on clients, they use the same random number generator, so that if one client rolls a die and gets a 6, the other clients also roll a 6. If one client decided a tank was destroyed, then all other clients also happened to decide that the tank was destroyed (because all clients are calculating the same thing), so there's no need for the clients to tell each other that the tank was destroyed, since they already know. If you tell your lancer hovers to attack, and get them to retreat in time, there's no risk of them suddenly exploding after they retreated to safety (as long as they aren't on fire, that is).

[Buginator]

*reserved for another dev's POV*

[n2large0shirt]

( If that is the case, then leave me a PM, I will send you my shipping address. )

lol, I will take two!

Optimization is a pain, a poorly optimized game will bring down the mightiest of systems and many new games coming out are very poorly optimized... I think however that Warzone does well, it even runs smoothly on my cheep little net book...

[KukY]

Please test the latest trunk snapshot as can be found here, and again, report all issues you have!

So, you are telling us to test MP games with a Trunk snapshot, which is several months old and still has tons of annoying bugs which make the game unplayable?

[macuser]

I will for sure. thnx bug

[KenAlcock]

Hey Buggy,
Thanks for taking the time to spell all this out for us. Your first post here would actually make a very good FAQ for people to get some understanding of MP sync issues, and why some hosts insist on only hosting 6 players rather than the full 8.

[NoQ]

So far, i've had a couple of hangs in 2.3.5_rc* when i was a guest, but the symptoms were very close to those host hangs (i mean, the screen and sound freezes, and the game responds only to SIGKILL). Both were at the very beginning of the game (several minutes after the start).