Hey all, Ever since Total Annihilation I have been waiting for the next TA, TA 2 ... Now Supreme Commander got close. It was the same idea lots of units, realtime 3D etc ... However SC had a gamekilling bug, most of the time you played an direct ip battle and you had more then 1000 units , the game went into desync and basicly your game was over. The game could never sync again. So that kind of killed the game for me. They never released a patch for this , so I believe it was technically impossible to resync the states of the two clients. If Planetary Annihilation will have the same or even more amount of units then SC , there is a huge danger this will happen in PA as well. Therefor I like to raise this post, so the developers take note and keep this in mind for when they start stress testing their multiplayer. I really don't want to be dissapointed again after a 6 hour game that the network desyncs and there is no way to recover. sincerly celludriel
Won't happen in PA. All the titles you mentioned used a homogeneous network model where every instance had a full copy of the game and simulated it independently from the other instances. So if you had some package loss due to an insufficient network connection, you would loose synchronization. PA uses a different approach, there is only a single server which simulates the world and every player just runs a client which performs no simulation at all but replays the simulation from the server. This means, that there is only a single gamestate in existence, so it can't get out of sync. A desync can therefore never happen, and even if it it did, you can just reconnect to a running server. PS: The server/client model also means, that only the performance of the server will limit the game speed, unlike SC where the slowest PC among all players would have slowed down simulation speed.
weird, I never experienced a lot of desyncs in SupCom at all. do you mean 1000 units per player or 1000 units per game?
Happens when you are on an unstable Wifi connection or alike. The reason for the desync is unexpected package loss due to an insufficient network connection. Probably also happened with less units, but wasn't so obvious because errors didn't propagate via pathfinding (blocked passages) yet.
1000 per player so taking in account 4 ai's and me and my buddy we had a whole bunch of units in our games. But it makes sence if PA is going to use a single server that is going to serve clients desync won't be much of an issue, I sincerly hope that single server is a huge distributed cluster then if it is going to server thousands of players all playing at the same time though.
It won't be a single server for all games, but each individual game will run on a server. Think of the way multiplayer FPS games work.
Looks like the OP needs to do more research on what's been said about PA. Uber knows well of the desync problem and is designing the engine so that it isn't synchronous in the first place. If there is networking problems, they shouldn't exist in the same way as they did in SupCom. Nothing more needs to be said.
Desyncs are literally impossible in PA. Yay for client/server. Not only that but you can look into the entire game history at any point in the game.
I can only salute this. I'm a big advocate from server only calculations, it is a huge help to avoid cheating if there is a server that does all the work. But thats going of topic from what I started. Long story short thnx for the answers, you got my preorder
I donĀ“t know which system Magicka use. I was thinking of the princip of Synchronisation in games, because Magicka is absolutly unplayable. So dont mind.
Magicka is yet another example for an homogeneous, synchronized network model. However, even a single lost UDP package causes desync.
I haven't played magica multiplayer, but no game should ever use UDP if data is that critical. (And nothing is being done to prevent desyncs on the client/server end)
It actually is possible to build a reliable package system on top of UDP which achieving a performance gain over TCP. There are several libraries which implement such behavior. But resending lost packages is not always desirable in multiplayer scenarios as the whole simulation had to be stopped on every single node in the network until client state has been replicated again. You would therefore have many small yet noticeable lags every time a package is lost somewhere in the network. Thats why you usually choose to ignore lost packages and you hope that it doesn't have to many consequences. Besides: Many game manufactures simply forget to stress test their netcode. They only test in perfect LAN scenarios, if you are lucky they will also test connections with slightly longer delays and limited bandwith, but most forget to simulate package loss to see how robust their netcode actually is. And package loss isn't exactly uncommon, your Wifi, your Internet connection, limited resources at any ISP in the path, all that can lead to package loss.
I never had problems with magicka. But yeah desync on a single lost UDP packet isnt a good idea at all.