Multiplayer stuff

[jda]

Yes, being able to re-load and re-start multiplayer games would've been nice to have back too, and probably could have been re-enabled and fixed up without significant stress. However, I have a much better idea in mind for that now, which will make the whole process 'seamless', but it will require being able to quickly save the game, and the current system saves/loads XML, which is not at all fast.

Cheers.

Well, if you say XML is not fast enough, I'm sure you're right!

BTW, how's the multiplatform part of multiplayer coming? Are you still working on the floating to fixed point conversions and server/client task-attribution you talked about on this topic: Multi-player Multi-platform?
Is that in any way related to your aproach of saving multiplayer games? 

Also, Titi is working (has plans for) Masterserver support too: Megaglest multiplayer discussion, you probably noticed already. 

[silnarm]

BTW, how's the multiplatform part of multiplayer coming? Are you still working on the floating to fixed point conversions and server/client task-attribution you talked about on this topic: Multi-player Multi-platform?

On hold until I have more frequent access to a Linux box that can run the game... no point testing multi-platform net games on windows only

Is that in any way related to your aproach of saving multiplayer games? 

Not related, no.  Resuming net games in my 'vision' will involve the user doing nothing more than clicking a 'yes' button, the game will be periodically (every second or so) saved by all participants, and they will keep the last few saves at all times, overwriting older ones when it can be safely assumed they wont be needed.  Then resuming a network game will involve reconnecting, some net chatter to determine the most recent save everyone has, reload and resume.

This will require some work though, as well as binary serialisation, there will need be lots of additions to the (Glest) network 'protocol', so it's not 'just around he corner' unfortunately.

Also, Titi is working (has plans for) Masterserver support too: Megaglest multiplayer discussion, you probably noticed already. 

I noticed, and when the discussion gets suitably technical, I'll jump in

[jda]

BTW, how's the multiplatform part of multiplayer coming? Are you still working on the floating to fixed point conversions and server/client task-attribution you talked about on this topic: Multi-player Multi-platform?

On hold until I have more frequent access to a Linux box that can run the game... no point testing multi-platform net games on windows only

I guess... I have a Linux box myself. Yeah, you'd probably like to get your hands physically on it, I understand. Still, if you want to, we can try and schedule some sessions and you can even make me your "dumb terminal" - I'll just mindlessly follow orders.

Is that in any way related to your aproach of saving multiplayer games? 

Not related, no.  Resuming net games in my 'vision' will involve the user doing nothing more than clicking a 'yes' button, the game will be periodically (every second or so) saved by all participants, and they will keep the last few saves at all times, overwriting older ones when it can be safely assumed they wont be needed.  Then resuming a network game will involve reconnecting, some net chatter to determine the most recent save everyone has, reload and resume.

I see. Is there really an advantage in saving games periodically instead of on-demand? I mean I can surelly understand that if you make it fast and smooth enough for periodic saves, it will run like silk on a on-demand basis. But I don't take that's really the point... 

This will require some work though, as well as binary serialisation, there will need be lots of additions to the (Glest) network 'protocol', so it's not 'just around he corner' unfortunately.

We'll wait.

Also, Titi is working (has plans for) Masterserver support too: Megaglest multiplayer discussion, you probably noticed already. 

I noticed, and when the discussion gets suitably technical, I'll jump in

LOL

[silnarm]

I guess... I have a Linux box myself. Yeah, you'd probably like to get your hands physically on it, I understand. Still, if you want to, we can try and schedule some sessions and you can even make me your "dumb terminal" - I'll just mindlessly follow orders.

The offer is certainly appreciated But yes, especially early on, I'm going to want/need both in front of me,  once any initial problems are sorted, plenty of testing will need to be done, and logfiles from broken games will be very much appreciated.

I see. Is there really an advantage in saving games periodically instead of on-demand? I mean I can surelly understand that if you make it fast and smooth enough for periodic saves, it will run like silk on a on-demand basis. But I don't take that's really the point... 

The problem with 'on-demand' is, when do you demand them?  Even with mandatory Acknowledges from clients, by the time the server realises it's lost a client the game will be well advanced on the server. Only saving on the server then sending the save file back to the clients was the old solution, this has some drawbacks, amongst them the loss of selection groups and camera position for all clients, and well as the loss of some 'play time' for the clients.

The proposed solution is that all participants save the game themselves, thus keeping selection groups and camera position, and the game can be 'rewound' to the last incremental save that everyone has, so the server gets no potentially unfair advantage.  It also eliminates the need to send files, and while this is no a big deal, sending a couple a frame numbers from each client and then the server sending just one back is a bit nicer.

[jda]

I guess... I have a Linux box myself. Yeah, you'd probably like to get your hands physically on it, I understand. Still, if you want to, we can try and schedule some sessions and you can even make me your "dumb terminal" - I'll just mindlessly follow orders.

The offer is certainly appreciated But yes, especially early on, I'm going to want/need both in front of me,  once any initial problems are sorted, plenty of testing will need to be done, and logfiles from broken games will be very much appreciated.

Ok.

The problem with 'on-demand' is, when do you demand them?  Even with mandatory Acknowledges from clients, by the time the server realises it's lost a client the game will be well advanced on the server. Only saving on the server then sending the save file back to the clients was the old solution, this has some drawbacks, amongst them the loss of selection groups and camera position for all clients, and well as the loss of some 'play time' for the clients.

Right, makes perfect sense.

The proposed solution is that all participants save the game themselves, thus keeping selection groups and camera position, and the game can be 'rewound' to the last incremental save that everyone has, so the server gets no potentially unfair advantage.  It also eliminates the need to send files, and while this is no a big deal, sending a couple a frame numbers from each client and then the server sending just one back is a bit nicer.