[Koji]

Sorry I just had to post something

So anyway I'm tackling the network component of XNA setting up some network support for a game prototype for my game design course final. And it suddenly hits me, this is the kind of thing that I aways wanted in mzx.

in any case, I strongly reccomend that if anyone is looking into implementing network support in mzx, should at least take a passing look at what XNA has done. Of course XNA's network component is a bit limiting as it's only used to connect two or more instances of a game into a networked "session," and I understand that a networking component in mzx would probably be desired to be a bit more flexible.

blah blah blah, just throwing this out there,

[GetDizzy]

Its our annual netmzx topic!
OMFG.

[Koji]

Someone has to keep this tradition alive.

[Exophase]

It seems like NetMZX that works the way netplay in emulators work wouldn't be too awful. The master (server) appears as the normal keyboard and the slave (client) appears as either some auxiliary state or another part of the keyboard. So the master would appear to be driving the main keys even on the slave's end. Then the two ends are kept in synchronization by updating the keyboard state every N cycles, with both ends keeping a global cycle count. If the state doesn't come within that many cycles it stalls for it. Packets would include a cycle number to ensure synchronization. At speed 5 or so you could possibly update state every cycle for low latency connections - that's 64ms per cycle and the transfers are one way. You'd probably want to use UDP and have eventual timeouts and whatnot.

It'd basically work similarly to how a multiplayer MZX game would work now (ala Brotherhood). It doesn't seem like more complex communication is necessary since pressing a key or moving the mouse is the only thing you can do to affect the state.

There are some caveats, of course:

- Ideally both games would execute all cycles within the cycle window, but even then a momentary burst could cause things to fall out of sync and they'd probably eventually fall out of sync anyway just due to slight variations in tick timing. Since cycle numbered packets are being sent both ways the faster side would have to stall waiting for the slower to catch up.
- The master needs to take care of seeding random numbers on both ends.
- The world file and all assets would have to be identical - you can verify the former easily enough at startup, but I don't think the trouble should be taken to verify any auxiliary files. If they mismatch then things will just silently lose synchronization, but it can't be that hard to ensure that both sides are using the same stuff.

Revvy did some work with something similar, dual world editing over the internet. He said it was too slow to be useful, unfortunately. Maybe the people testing just weren't good candidates.

[LogiCow]

Kind of like how ZSNES and Starcraft work, you send the keys pressed over the network and you add a latency system so that slower connections don't systematically slow everything down.

[ajs]

There's already portable network code in MZX with some UDP stuff if 0'ed out IIRC. Probably wouldn't need much love to get going. Like Koji said I think you'd want a lobby and some kind of file transfer thing which might make it more complicated, but probably not unreasonably so.

Real issues IMO would be making it programmer friendly (not sure about the virtual multiple player thing) and making is fast, which has been discussed already.

--ajs.

[mzxgiant]

We could tack a lobby onto what we're already doing with Gambit, and I could extend out some PHP to interface with the boards for various purposes if we wanted to. It would just mean a bit more work that I will take 6 months to complete

(Hopefully not, I'm trying like hell to play catch-up with what I haven't finished yet...)

edit: Waitasecond. Are we SERIOUSLY, after all these years of people asking, saying "Yes, NetMZX could and may be done."?!? Good lord, what have we become?

[Pyro1588]

how would other player input work? could player 2's arrow keys and space bar possibly be mapped to some other keycode so that they can still control things normally? also, is it safe to assume we don't implement a second player object and instead leave that to the game designer to implement via robotic?

[weasel]

This is probably massively impractical, but in the event that the game DOES fall out of sync, perhaps a "resync" feature could be implemented that would have the host save the game, send the save data to the second player, and have both players load and synchronize from there? There probably wouldn't be a practical way to detect desyncs, so it'd probably have to be set to a keypress somewhere...F7? =P

[Old-Sckool]

Exophase, on May 11 2009, 01:52 AM, said:

Revvy did some work with something similar, dual world editing over the internet. He said it was too slow to be useful, unfortunately. Maybe the people testing just weren't good candidates.

How did that work though? I mean, duel world editing would be sweet for DOZes.

[Koji]

IMHO if you're JUST after multiplayer support and that's all you want in the system, I have an idea.

Every network game starts in the lobby, where players get together and host or join a session, a session is created once a host player selects a .zip or folder of the game they want to play, the game is polled to find out how many network players is supports (more on this later) and up to that many players may join the session, before the game is started, one MAY possibly support a spectator mode(perhaps). Lobby information is compiled and kept in counters available to the game

An mzx programmer should be able to identify somewhere how many players the game supports, and have access to a class like structure similar to sprites that can manage multiple players and their various status counters, as well as a keyboard and mouse state for that player.

By default, when a game is started, the lobby information is used to identify what player that instance is to inhabit. if it is not the HOST the instance will sent a report detailing the players input and state to the server. and assume that everything goes fine unless corrected by the server (a .sav file or something will be sent to all players by the server if there is a possibility that two players would have conflicting results).

if a player leaves the board the server is on, either the player will have to sent update information on the state of the board it is visiting to the server. OR a queue will take care of pending game play events. Whenever a player leaves from one board to another, it's game play event "switching to another board" is added to a queue unless that entry already exists. and it will wait for that board to be drawn from the queue before the player is allowed to continue playing.

This means that given 3 players if you go out through three different exits, a sort of episodic scene will result, in which you take turns playing unless players end up on the same board again, and then the game play resumes with both players playing at the same time.

If you are NOT playing with default players, it is up to the Programmer to handle the player information and decide what actions should be taken. Since the programmer has access to the player constructs which include input states for each, the programmer should be able to cobble together some kind of mechanism for taking the players' inputs and putting it to use on sprites or robots, or whatever the players are controlling.

This post has been edited by Koji: 15 May 2009 - 03:11 AM

[Risu2112]

Why bother supporting multiple players, that sounds like a nightmare.

Just leave all standard inputs as they are, and only usable by the host. Supply new input values for additional players with some sort of prefix to indicate they are coming from a different keyboard (and presumably client).

For example, a basic game where 4 players each control their own robot that can move N/S/E/W using the WASD keys.

To make this work now would look like:

end
: "keyw"
go NORTH for 1
end
: "keya"
go WEST for 1
end
: "keys"
go SOUTH for 1
end
: "keyd"
go EAST for 1
end

Change it to something like:

set "local" to "x"
end
: "&local&keyw"
go NORTH for 1
end
: "&local&keya"
go WEST for 1
end
: "&local&keys"
go SOUTH for 1
end
: "&local&keyd"
go EAST for 1
end

Where x is the player number (determined in sequential order from joining the game) player 0 being the host presumably.
In this case, just copy that robot 4 times on the board and set local on them to 0,1,2, and 3.

:"0keyx" <- triggered by host pressing X (player 0)
:"1keyx" <- triggered by player 1 pressing X
:"2keyx" <- triggered by player 2 pressing X
etc. etc.

Probably a good idea to keep ; :"keyx" ; and just have it do the same thing as :"0keyx"
Under this method, the default player would still be functional in a game, but would only respond to inputs from player 0, the host.
Similar modifications would have to be made to other input scanning methods such as leftpressed/rightpressed and also mouse status.

Back to the original point, actually supporting multiple players seems like it would be a clusterfuck of work just considering the shear volume of scenarios that would have to be anticipated. Seems much more realistic to expect people making multiplayer games to just continue to circumvent using the player via robots as they have been so far.

[ajs]

IMHO Exo's suggestion has been the best so far, where networking is like console emulators. Maybe you add a bit of logic for remapping keys, but fundamentally you don't want too many game customizations to be required, at least not for a first cut. Ideally any game created for multiplayer would work as an N player game even with just a single copy of MZX. There's still some complexity to this, like making sure both copies are using the same random seeds, etc. but it's doable.

Once the mechanism was stable and, importantly, sufficiently fast, you could start to make changes to MZX to make it more multi-player friendly, and maybe eventually you would add network-specific stuff (so for example different players could see different things on screen at once without a split-screen engine). But I wouldn't recommend doing that initially.

Of course things like a lobby and file transfer are just good ideas and could be done right now.

--ajs.

[Risu2112]

ajs, on May 14 2009, 10:59 PM, said:

IMHO Exo's suggestion has been the best so far, where networking is like console emulators. Maybe you add a bit of logic for remapping keys, but fundamentally you don't want too many game customizations to be required, at least not for a first cut. Ideally any game created for multiplayer would work as an N player game even with just a single copy of MZX.

Once the mechanism was stable and, importantly, sufficiently fast, you could start to make changes to MZX to make it more multi-player friendly, and maybe eventually you would add network-specific stuff (so for example different players could see different things on screen at once). But I wouldn't recommend doing that initially.

Of course things like a lobby and file transfer are just good ideas and could be done right now.

--ajs.

Yeah makes sense, but I do feel the logical progression would be to fairly quickly set up some means of determining which client is sending which inputs.

How serious of a problem do you all think desyncing would end up being? Seems like most games played online, say a modern RTS where only inputs are sent to the host never has any significant issues. Is the problem related to the speed robotic is processed? If not, what exactly.

Once inputs are differentiated between clients, actually making a pretty decent and fun multiplayer game would be incredibly easy, even for a very novice mzxer'

This post has been edited by Risu2112: 15 May 2009 - 07:33 AM

[Koji]

The problem I have with the model given by Exo is that it's kind of hackish. I mean there are a couple issues with it.

1) Any given client has control of all players at any given point, since they are all effectively sharing the same keyboard, making it easy for a player to cheat, or cause confusion in the game.

2) Say you have a game where you can move your player up down left and right and shoot and some other action, okay so how would you map that out on a keyboard for 4 players where the controls are still fair? You will end up with players who have the short end of the stick.

3) playing on point 2 you only have so many keys and only so many of those are placed in a way that make sense for controlling an mzx game.

In the end, I think having access to each clients keyboard and mouse state is a much better proposition. Maybe I went a bit overboard with the whole player class thing.

On a completely different train of thought:

Rather than making sure everyone has the same copy of the mzx file, why don't we just cut out all the doubt and just have the server player host a feed of the game. That is, sent out to each of the client players what is effectively an 80x25 mzm screen shot for each frame, and a char or pal when update is necessary, along with a bit of sound buffer data.

So you'd have two programs, probably separate from the full mzx that we use right now
a client and a server.

The Client would be tailored to log onto a lobby session, and accept streamed screen/sound data while sending back keyboard and mouse state.

The Server would be tailored to set up a lobby session, and sent out streamed screen/sound data while accepting keyboard and mouse states from the clients while playing an mzx game. The keyboard and mouse state information could be encoded into counters for the game to interpret. I don't think changing the way the key lables work is a good idea for a first iteration. So basically MzxRun with some additions.

for the server, the fed in keyboard and mouse information would be stored in counters similar to where we get this information for the local keyboard and mouse but prefixed like "Net(Id)_counterInQuestion" or something.

ANOTHER IDEA:

set up a universal server, which would handle all network games, everyone logs on with clients and the server pulls games from some archive. (this would be a great deal more work to set up though)

[ajs]

Sending the video out for each client seems like a good idea initially but it's much, much slower than a simple UDP re-sync every so many cycles. It's more accurate, and easier to understand, but it's much harder to pull off.

Any game with a moderately complex network engine will run the same game on all clients and have the client do as much legwork as possible and let the protocol smooth out the differences. That's why sometimes in a network FPS you can kill somebody, or think you have, but they live on. Arguably that sucks, but it's much faster.

I wouldn't get too bogged down in keyboard stuff. That problem is pretty easy to fix, eventually. My immediate concern is that somebody puts together some hacky network extensions that don't really work well (too slow, unreliable, require counter hacks, etc.) and there's a bunch of games made for this that can't ever be used if the feature is abandoned or re-implemented. Seems to me we could get a much better idea of what works and/or what is needed by prototyping networking in the proposed console style. I think people cheating by overriding somebody else's keys is a minor issue that could be resolved later (hopefully without a bunch of horrible robotic).

I've started playing about with these ideas; at the moment I have it to the point where users will load the same MZX world to the title screen, and then instead of pressing 'P' press F6 and type in either nothing if they are the server or an IP address if they are a client. At that point the client can inject key presses for as long as they remain connected. With probably a couple hours more effort I could have the "resync every N cycles" thing done, or whatever works, and that would be something quite functional in not a massive amount of time.

--ajs.

[Risu2112]

ajs, on May 15 2009, 02:33 AM, said:

I've started playing about with these ideas; at the moment I have it to the point where users will load the same MZX world to the title screen, and then instead of pressing 'P' press F6 and type in either nothing if they are the server or an IP address if they are a client. At that point the client can inject key presses for as long as they remain connected. With probably a couple hours more effort I could have the "resync every N cycles" thing done, or whatever works, and that would be something quite functional in not a massive amount of time.

--ajs.

Oh my god... Has the Futer finally arrived?

ajs: If you continue to get promising results, what do you think would be the best way (easiest to implement, and easiest to code for the user) to ID the players and their inputs? I'm certainly not the authority on the subject, but seems like it shouldn't be too difficult to implement.

This post has been edited by Risu2112: 15 May 2009 - 01:01 PM

[ajs]

Not sure really. I'm kind of hoping that I can release a prototype with just the key-press injection, cycle sync thing, lobby and file synchronisation working and then somebody else will redo it properly (which inevitably means integrating networking more deeply). Hopefully this way it'll stop people from exporting sockets in robotic, as I've seen tried before :-|

So there wouldn't be any changes to robotic, and people could "cheat", and multi-player games work with single and multiple clients alike.

There's other thorny issues that need thinking about:

- Random seed sync (custom Random() should hopefully ensure a consistent pseudo-random sequence)
- Make save games work (not too hard, but the way you start network mode would be different)
- Allow clients to join at random times after a random amount of world state has changed (may be limited to "save game, send save, load game on other side")
- Synchronising assets -> if a game loads an MZM after the fact, we need to make sure it's the same on both sides. Ideally would be done at initialization time, but currently can't be, because file names can be generated programmatically in robotic.
- Stuff I haven't thought about yet

--ajs.

[Koji]

For the time, why don't we have mzx do a check sum on the game folder contents and if it matches across the clients, we just assume all the content is identical.

Also if we just make sure all the random number generators are seeded identically at the start of the gamerun, wouldn't the games random numbers end up being deterministic and identical across the instances? There shouldn't be a need to keep them synchronized through constant seeding.

This post has been edited by Koji: 16 May 2009 - 01:02 AM

[ajs]

Just means there's more work to do in TCP before switching to UDP. You're right though, and I think lancer's custom Random() (which should be used everywhere) is portably deterministic (it's integer only).

As for the folder thing, that was my first idea too, but MZX doesn't require games to be in their own folders, and people would inevitably try a game in their root, and that would end up sending too much..

--ajs.

[Risu2112]

ajs, on May 16 2009, 03:50 AM, said:

Just means there's more work to do in TCP before switching to UDP. You're right though, and I think lancer's custom Random() (which should be used everywhere) is portably deterministic (it's integer only).

As for the folder thing, that was my first idea too, but MZX doesn't require games to be in their own folders, and people would inevitably try a game in their root, and that would end up sending too much..

--ajs.

Might end up being something left to responsible programing. Store any static .MZM's in the .MZX and export them all out each time the game is run. Not an ideal solution, but at least we do have options already to correct any .MZM data issues as the game is launched. (This actually for most generic .MZM usage in standard single player games might not be a bad idea so the user can't misplace or overwrite them by accident.)

This post has been edited by Risu2112: 17 May 2009 - 01:31 AM

[Koji]

if someone is dumb enough to try it, I say let them shoot themselves in the foot, and broadcast their ignorance to anyone who has joined their game. The very humiliation resulting from the behavior should serve to weed it out.

[LogiCow]

Every cycle, everyone sends a packet to every other connected players which contains:

Cycle number + n
Keys pressed during that cycle


n is a number that can depend on configuration, mzx speed, connection speed.


Then, every cycle, MZX considers everyone's controls for the current cycle number to be the actual input controls. If it does not have everyone's controls for that cycle, it will halt and wait for them before it continues.

that way it doesn't lose sync and can still run at full speed on connections with a high latency.


Also I strongly suggest a playerX_name string to add a little personal touch.

[Exophase]

Koji, on May 15 2009, 04:49 AM, said:

The problem I have with the model given by Exo is that it's kind of hackish. I mean there are a couple issues with it.

It's not hackish, it's just simplistic.

Koji, on May 15 2009, 04:49 AM, said:

1) Any given client has control of all players at any given point, since they are all effectively sharing the same keyboard, making it easy for a player to cheat, or cause confusion in the game.

Not true, the way I described it there'd be virtual keyboards and every client only has control of their own keyboard.

Koji, on May 15 2009, 04:49 AM, said:

2) Say you have a game where you can move your player up down left and right and shoot and some other action, okay so how would you map that out on a keyboard for 4 players where the controls are still fair? You will end up with players who have the short end of the stick.

Read the above.

Koji, on May 15 2009, 04:49 AM, said:

3) playing on point 2 you only have so many keys and only so many of those are placed in a way that make sense or controlling an mzx game.

Isn't this the same as 2 with different words? Anyway, it's not applicable...

Koji, on May 15 2009, 04:49 AM, said:

In the end, I think having access to each clients keyboard and mouse state is a much better proposition. Maybe I went a bit overboard with the whole player class thing.

That's how I proposed it...

Koji, on May 15 2009, 04:49 AM, said:

On a completely different train of thought:

Rather than making sure everyone has the same copy of the mzx file, why don't we just cut out all the doubt and just have the server player host a feed of the game. That is, sent out to each of the client players what is effectively an 80x25 mzm screen shot for each frame, and a char or pal when update is necessary, along with a bit of sound buffer data.

That's crazy, why would you do that when that information can be deterministically derived from the input on each end?

Koji, on May 15 2009, 04:49 AM, said:

So you'd have two programs, probably separate from the full mzx that we use right now
a client and a server.

Why would you have two different executables instead of giving MZX the functionality of both?

All of the other stuff is just unnecessary complication that doesn't gain you anything.

If anyone's so concerned about sync mismatch then make the clients send out a checksum of all files loaded in that cycle and make sure they all agree. Of course this should be optionally since it really isn't necessary if people take care to actually play the same game.

[Sai'ke]

Woah, this might actually get me back into mzx for a little while :D

[Koji]

Exo, I must have misunderstood your prior post.

however on the game server streaming the game to others idea, that was more like the clients don't have a copy of the game, and like we're just sending them enough information to display the picture of the screen, and it's just sending back enough information to get it's keyboard and mouse state. The server would be doing all the real game work.

But yeah this is kind of a bad idea especially since with other models the client can do most of the work that the server doesn't really need to do.

[Revvy]

Old-Sckool, on May 11 2009, 02:01 PM, said:

How did that work though? I mean, duel world editing would be sweet for DOZes.

That was the use case I was aiming for. Basically one person would run the server, and any clients who connected would receive the whole world currently being edited. Then all client commands would be routed to the server, which would broadcast them out to all clients, at which point they would actually execute. In my prototype implementation, there was quite a bit of latency, which was frustrating. However, I'm quite certain that my implementation was not optimal, so the issue was certainly surmountable.

[computergeek6]

For shared world editing, why not have clients send hashes of the local world file to the server, and have the server synchronize the two versions if the hashes don't match? Sort of like real time SVN for MZX

[ajs]

The plan is to leverage the updater code for sync'ing worlds. The server would be a simplified HTTP daemon and the client would request the world like it would an update. This technique compares the size and SHA256 of the file to establish identity. Transfer is done using HTTP chunked transfer encoding with zlib compression. All of this code is already written.

--ajs.