[Spectere]

Elig, on Jan 12 2007, 09:37 AM, said:

First of all, I think it's apparent you understand very little about modern networking code, so I am surprised you so readily offer judgments. Do your research before commenting.

I'm not even an expert on networking code and Cube's design sounds like a very bad idea and extremely open to exploitation.

Also, the fact remains that there are enough blatant security vulnerabilities in Cube for the Gentoo team to mask the package on all architectures. ajs isn't the only one who thinks that it's broken.

[ajs]

The point I was really trying to make before Elig got so defensive about Cube was that MegaZeux _shouldn't_ be like Cube. It probably shouldn't even USE datagrams.

People go on and on about how marvellous datagrams are for latency, but it's really overblown. Most 3D game engines spend 10s of thousands of lines providing lag and packet loss compensation for the sake of a 10ms overhead. Pointless, for MegaZeux, I'd say.

Indeed, how MegaZeux would have to be modified for this to work correctly (and securely) is that it would have to find everything that a game used, and check it had the same checksum. In a "MegaZeux 3" some sort of packed format would simplify this, but even in the current generation of MZX it should be possible. Another thing that would be doable was automatic transfer of the game if you didn't have it.

Secondly, some support for two players would really be required. I've thought long and hard about this and I really don't think a single robot that swaps with a player would cut it. It leaves too many holes for the original game programmer, who probably doesn't _want_ to know how everything works. Remember the two player bug MZX had a couple years back? Somebody needs to make that work, even if it was just with a static viewport, then maybe we could think about modifying the _many_ assumptions MZX makes about boards and viewports.

Then finally, there'd be some sort of GUI overhaul. It wouldn't just be "press p to play", but there'd have to be some sort of multiplayer menu. We could make it simple by setting up a master server of sorts, possibly even supporting socket relaying for getting through those pesky NAT firewalls. Each game would have a player limit and some form of identification, probably just a nick with a client hash. This would allow people to reconnect to games if their connection was physically dropped.

Plus, you've got to factor in things like "what happens if somebody disconnects". MZX would have to be paused, with some means of leaving the scenario, "Waiting for playerx..."..

It's basically a lot of small modifications that would have to be robust for this to really be usable. It also fundamentally alters MZX's game play. I know some people have implemented secondary players using robots and custom keys, but it's just not the same.

--ajs.

[ajs]

Another thing to note is that MZX is very heavily dependent on monotonic synchronization between robots, input, video updates. Imagine running two copies of MZX on vastly different machines with the speed set differently, and then simply connecting them with sockets. It would not work.

A lot of people that design networking systems do so from the ground up. MZX hasn't been designed with this in mind, it expects determinism.

I think if you were to network MegaZeux, concepts like Lamport Timestamps (see Wikipedia) which are borrowed from distributed processing would conceptually solve this problem. The question is how often, and to what extent would you apply this form of synchronization? Would it scale to many clients?

A lot of software with "bolt on" networking just doesn't work very well because these synchronization issues haven't been considered, or the game depends on synchronization too often, which has a significant performance cost.

--ajs.