Let's discuss networking - #FujiNet brainstorming

[bocianu]

That would be great to add network players. This game is perfect fit for it.

First of all - we do not need N: device to be loaded. I would even say that we do not want it :)
It's pretty convenient to use system Sio routines to comunicate on the level we need.
I don't know if you are already turning system memory off, but I recommend to go this way.

I already prepared nice and tiny handler to provide basic REST API operations via http and https.
It is only 458 bytes long, of course this do not include transmission buffers, but still.

I'm attaching it here: #FujiNet Tiny Http Client

For now my handler allows you to:

• GET data
• GET HEADERS
• POST data with custom headers
• PUT data with custom headers

There are two extra features:

• if GET receives data block starting with $FFFF (atari com file) it reads following addresses and loads remaining data into atari memory at desired location,
• it can RUN and INIT com blocks

I think it could be enough for basic communication with the game server, or even more.
Using RUN/INIT wisely you can even create autoupdating exectable :)

Considering server itself, I can also help in this area.
I have some experience in writing REST API backends in node.js

But for sure we need do some work on communications scheme, data structures, and general principles.

[bocianu]

Some general principles I'd like to propose:

• communication will be based on server state polling - no direct communication FROM server to clients and/or between clients
• one of the players must be the host, and he starts the game choosing how many FN_players can join
• server maintains the game lists available to be fetched by the players
• non-host player(s) can join hosted game and becomes an client/guest/participant
• host player needs to wait for all players to join and then game starts / he can also cancel the game before it starts
• on the start of the each round map is generated on host player machine and then transfered to server
• all clients have to poll map and tank positions and draw it localy
• on each shoot power/angle/weapon is tranferred to the server and can be polled by all the clients
• shoot and explosions are drawn locally on the player's machines (PROBLEMS TO SOLVE HERE - undeterministic weapons like funky bomb, sandhog - random endings) - it's important to keep terrain destruction and tank positions identical on each machine.
• between rounds all purchases are also sent to server
• host computer controls general game flow/progress,
• clients are only polling game status, drawing screens, and sending shot/purchase data to the server on apropriate stages.

For now I'm not planning to use any persistent storage on server for game sessions. It all can be done in server memory.

[pkali]

this seems to be absolutely perfect!
thank you!
i'll have some time over the weekend to ponder these points in more detail, but in general I do agree with all points.

[pkali]

I was planning to write a rest api in python (because I know how to do it), but I'll be more than happy to work with node.js and your help, this is the only way to release it before the next glacial period.

[pkali]

I am sorry for lack of activity here, I was implementing sfx which turned way more complicated than expected.
Also more than half of the free memory taken. Will networking fit in ~4KiB?

[bocianu]

sorry for beeing quiet here, but im focused on fujitalk server/client. Good side of it is, that more then 50% of server code can be reused for scorch-server ;)
Yes, I think 4k for networking should be more than enough if we have OS ROM accessible.

[pkali]

Not a problem at all, we are slowly and steadily progressing towards the end of the single-player version, it would be silly to venture adding networking to a half-baked and oh-so-buggy game. I think we should be able to start working seriously on networking around August.
Bad news - only 2KiB left. But we'll push something under OS ROM and finish this silly Atari 800 compatibility fad :)

[pkali]

OK, so the single player game seems to be "done" (sans bugfixes and optimizations), so we can to think about the implementation.
Bad news - practically NO free mem. But it is lower 48KiB only, so we have full XL/XE OS RAM available and we can move there several game elements, e.g. sound, non-time critical tables, etc. Page zero taken from byte $64.

[mozzwald]

Any update on this? Is there any RAM left for networking?

[pkali]

It got worse, less page zero space, a handful of bytes free in 48K, only XL/XE RAM under ROM is available.