[GH-ISSUE #46] Let's discuss networking - #FujiNet brainstorming #41

New Issue

2026-05-20T22:32:14+02:00

Pecus commented

2026-05-20 22:32:14 +02:00

Originally created by @bocianu on GitHub (May 2, 2022).
Original GitHub issue: https://github.com/pkali/scorch_src/issues/46

Originally assigned to: @bocianu, @Pecusx, @pkali on GitHub.

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.

Originally created by @bocianu on GitHub (May 2, 2022). Original GitHub issue: https://github.com/pkali/scorch_src/issues/46 Originally assigned to: @bocianu, @Pecusx, @pkali on GitHub. 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](https://github.com/pkali/scorch_src/files/8605745/ftwc.zip) 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.

Pecus added the enhancement label 2026-05-20 22:32:14 +02:00

Pecus commented

2026-05-20 22:32:15 +02:00

@bocianu commented on GitHub (May 2, 2022):

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.

@bocianu commented on GitHub (May 2, 2022): 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.

Pecus commented

2026-05-20 22:32:15 +02:00

@pkali commented on GitHub (May 3, 2022):

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 commented on GitHub (May 3, 2022): 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.

Pecus commented

2026-05-20 22:32:15 +02:00

@pkali commented on GitHub (May 3, 2022):

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 commented on GitHub (May 3, 2022): 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.

Pecus commented

2026-05-20 22:32:16 +02:00

@pkali commented on GitHub (May 12, 2022):

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?

@pkali commented on GitHub (May 12, 2022): 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?

Pecus commented

2026-05-20 22:32:16 +02:00

@bocianu commented on GitHub (Jun 28, 2022):

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.

@bocianu commented on GitHub (Jun 28, 2022): 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.

Pecus commented

2026-05-20 22:32:16 +02:00

@pkali commented on GitHub (Jun 29, 2022):

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 commented on GitHub (Jun 29, 2022): 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 :)

Pecus commented

2026-05-20 22:32:16 +02:00

@pkali commented on GitHub (Aug 30, 2022):

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.

@pkali commented on GitHub (Aug 30, 2022): 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.

Pecus commented

2026-05-20 22:32:16 +02:00

@mozzwald commented on GitHub (Feb 5, 2026):

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

@mozzwald commented on GitHub (Feb 5, 2026): Any update on this? Is there any RAM left for networking?

Pecus commented

2026-05-20 22:32:16 +02:00

@pkali commented on GitHub (Feb 5, 2026):

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

@pkali commented on GitHub (Feb 5, 2026): It got worse, less page zero space, a handful of bytes free in 48K, only XL/XE RAM under ROM is available.

Pecus referenced this issue

2026-05-20 22:34:43 +02:00

[GH-ISSUE #41] Make Riot Charge and Riot Blast weapons #220

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/scorch_src#41