Web Play

[Thomas Jentzsch]

We discussed this previously and then thought one would have to transfer the whole RAM to stay in sync. While watching the ZPH stream, I got a different idea.

 

Instead of sending the whole RAM, we should develop (or find) a low lag protocol, which makes sure that no input gets lost and all clients (could be more than two) stay in sync. There were network games like NetWars (using IPX) in the past which worked very well and without a server. IIRC.

 

So we would be sending only input changes (or status) for console switches and controller and not the whole RAM. This would then even work the same for games with a lot of RAM.

 

This could (very coarse) look e.g. like this:

- A sends command, id and checksum

- B checks received data and reports result back to A.

- If checksum is OK, the B executes command.

- A receives result from B.

- If B reports an error (or nothing within a given time), the previous command is send again

- If B reports ok, the command is executed

 

I am pretty sure something like this has been well defined and documented in the web. 

Edited September 9, 2020 by Thomas Jentzsch

[Thomas Jentzsch]

Found this source, which provides a good start about problems and common approaches (peer-to-peer, client/server, client-side prediction). 

 

It looks like peer-to-peer, while being simple (as described above) wouldn't work well. Especially for typical Atari 2600 games, where loo much lag would kill the game experience. Client/server might work better, but what would be the server? A separate instance (e.g. running the game in an emulator) or one of the consoles? While a dedicated server instance would offer much more possibilities, it also adds another layer of complexity.

 

Maybe the ARM chip inside the PlusCarts could play a role here and act as something like a server? This would mean that 6507 and ARM code would run in parallel. This might minimize the required changes of the original game code. The game would only hand over once to ARM (e.g. at VSYNC), continue its work and e.g. before the usual INTIM loop at the end of a frame wait for the ARM to return. Meanwhile the ARM could do the network stuff.

Edited September 9, 2020 by Thomas Jentzsch

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

Found this source, which provides a good start about problems and common approaches (peer-to-peer, client/server, client-side prediction).

TY for the link, a very interesting overview about the different approaches.

1 hour ago, Thomas Jentzsch said:

It looks like peer-to-peer, while being simple (as described above) wouldn't work well. Especially for typical Atari 2600 games, where loo much lag would kill the game experience. Client/server might work better, but what would be the server? A separate instance (e.g. running the game in an emulator) or one of the consoles? While a dedicated server instance would offer much more possibilities, it also adds another layer of complexity.

peer-to-peer is not an option with PlusROM functions. PlusROMs always and only talk to their (in the ROM defined) backends. So this is a Client/server setup already. What we could do is client-side prediction.

 

1 hour ago, Thomas Jentzsch said:

Meanwhile the ARM could do the network stuff.

With the PlusROM functions exactly this happens. As a VCS ROM developer you only write to the write buffer, send the buffer, check the ReceiveBufferSize and read from the receive buffer. The rest you have to implement at your server (the PlusROM backend you have defined in your ROM).

Client-side prediction could be implemented with this setup but must be done by the 6507.

 

1 hour ago, Thomas Jentzsch said:

Maybe the ARM chip inside the PlusCarts could play a role here and act as something like a server? This would mean that 6507 and ARM code would run in parallel. This might minimize the required changes of the original game code. The game would only hand over once to ARM (e.g. at VSYNC), continue its work and e.g. before the usual INTIM loop at the end of a frame wait for the ARM to return.

This would be a DPC+, CDFJ or ACE setup, but these setups are not (and never could be) implemented with the ARM and the 6507 in parallel. When the ARM is executing his code he can not serve the 6507 and therefor he sets the Data bus to "NOP". This also doesn't work for a long time, because the 6507 PC is running in the mirrored TIA and RIOT addresses..

 

 

[Thomas Jentzsch]

Thanks for clearing up things for me.

 

If we already have a dedicated server, couldn't we use it to sync both clients? Client-side prediction could be as simple as keeping the current state.

[+Al_Nafuur]

On 9/9/2020 at 10:49 PM, Thomas Jentzsch said:

Thanks for clearing up things for me.

 

If we already have a dedicated server, couldn't we use it to sync both clients? Client-side prediction could be as simple as keeping the current state.

The server only distributes the joystick data to both clients. The rest is something like client-side prediction, but without being ever corrected or synced by the server.

Both clients send their joystick state to the server and move their tanks on the joystick data they get in the response from the server.

 

[Thomas Jentzsch]

I suppose adding (better) syncing to the server shouldn't be that hard? Also console switches should be distributed too.

 

Finally one could (slowly) sync the console states. E.g. by sending the whole RAM in a loop, byte by byte.

Edited September 12, 2020 by Thomas Jentzsch

[+Al_Nafuur]

45 minutes ago, Thomas Jentzsch said:

I suppose adding (better) syncing to the server shouldn't be that hard? Also console switches should be distributed too.

 

Finally one could (slowly) sync the console states. E.g. by sending the whole RAM in a loop, byte by byte.

I've update the combat code in GIT Yesterday.
Clients:
https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/examples/Online Combat.asm

Backend:

https://gitlab.com/firmaplus/atari-2600-pluscart/-/blob/master/examples/combat.php

 

The backend is installed in Germany at:

    .byte "combat.php", #0
    .byte "pluscart.firmaplus.de", #0

The backend in the US is at:

    .byte "c.php", #0
    .byte "relationalframework.com", #0

 

Edited September 12, 2020 by Al_Nafuur

[Thomas Jentzsch]

Before I dig into the code, what did you change? 

[+Al_Nafuur]

7 hours ago, Thomas Jentzsch said:

Before I dig into the code, what did you change? 

Nothing, it is basically the version played at the ZPH show.

 

All RAM variables are disabled, so only 2 bytes Joystick data (SWCHA and INPT4) are send by the clients.

The backend(s) can cope with variable length requests. The first client is the master and the second client is slave, which means the backend responses to both clients the Joystick data (slave is mapped to the right controller and INPT5). If requests are larger than 2 bytes the RAM data of the master is appended to the response. So the slave is somehow "synced" to the masters RAM state..  

[Thomas Jentzsch]

So why were they running out of sync in the ZPH stream so quickly?

[+Al_Nafuur]

1 hour ago, Thomas Jentzsch said:

So why were they running out of sync in the ZPH stream so quickly?

delays and small differences in e.g. the directions of the tanks make a big difference when they move..
 

[Thomas Jentzsch]

Any idea how to avoid or correct that?

[+Andrew Davie]

How about having client send joystick/button to server, and in return the server sends position of all objects in game? That way, each client is merely displaying objects at x/y coordinates, and both clients are always displaying the same thing. In other words, game logic moved to the server, clients are display devices.

[Thomas Jentzsch]

That would mean the server has run the game in an emulator. And it needs to know the relevant variable positions in RAM. Feasible of course, but something which works without having to analyze the code first would be much preferred.

[rhuneke]

Out of curiosity, has there been any progress on Web Play, like on the Combat demo I saw on Zero Page Homebrew? Is it actually possible to play the old Atari VCS over the internet? Last I saw it kept falling out of sync. Any progress on that front? What other games would be candidates for internet play? It would be so cool to be able to play a nearly 44 year old system over the internet. What will they think of next? ?

Edited October 29, 2020 by rhuneke

[+Andrew Davie]

I have plans for a sort of live/ "postal" chess via PlusCart.

 

The concept is you can either connect to another player directly and then trade moves... OR you can have a game where you make a move, and at some point in the future (maybe next time you turn on your 2600), the PlusCart chess checks to see if your opponent has made a reply and if so... then you are presented with it.

 

This isn't exactly real-time, of course, but it is "web play".