Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: The E on February 20, 2020, 05:54:14 am
-
Hi all. I have a small idea I'd like to sell you on.
One thing that we are currently lacking to make Multiplayer A Real Thing is an easy way to get servers up and running. Yes, if you want, you can run the standalone in any configuration you choose and tell people about it, but that is hardly <current year>.
But what if there was a service that does that for you? That runs servers in a known environment with known config options, on demand using whatever modpack you want?
That's the basic idea behind a project I've named "CommNode", in order to keep the naming theme of "Nebula" and "Knossos". The vision would be a web service that is able to spin up servers on demand using container technology.
Now, unfortunately, there is no demo I can give you right now -- I am still in the planning phase, and no code has been written yet. But I would like to gather some feedback nevertheless, and to that end, I have created a project board on the scp github page (https://github.com/orgs/scp-fs2open/projects/1). Please feel free to comment here or on github with questions, concerns and feature requests that I can then transform into tickets so that I can actually do this thing in a structured and solid way.
-
Sounds like a fantastic idea. I have been helping cyborg with multi testing and found that using the current system can be very restrictive and irregular. This 'on demand' service idea sounds like it would fix many of those issues, and also help attract new/old players back into multi. I will definitely be following any development on this front and look forward to any progress!
-
Now, about the name: Why not ETAK? :warp:
-
Do i understand that correctly, you want to create a 'cloud-service', where all i have to do to Play Multi is, press abutton and the 'Cloud-service' creates a Server for me, adds an info on the front page and Maybe even sends out invites to People who follow me as a user or played before with me? (yeah, i added some stuff :P )?
Having only a rudimentary understanding of coding left after a decade of not touching anything Code related, and only vague memories About the FSO net Code, i'm wondering, wouldn't this require a crap-ton of coding work?
Is the 'cloud service' the 'host'?
Who can access the host options one currently has?
Wouldn't it require changes to the game, to access these functions via cloud from within the game?
-
Okay, I'm totally not aware of how this stuff works but I have a couple questions...
Can that be run off of Nebula server(s)?
Could the whole proccess of creating/joining a multiplayer game player-side be handled via Knossos interface (obviously not with its current state, a "Multiplayer" tab would be needed :P )?
What about "integrating" this with some sort of a chat service, for example Discord? I mean, the "automatically invite your specified friends to your game" thing, realised via automatically sent private messages, for example. I'd prefer using some existing service for this as attempting it via Knossos and Nebula accounts would need you to have some additional notification service in the background...
Or maybe, just have a Discord bot track and show currently available games, or at least ping invited people?
-
Having only a rudimentary understanding of coding left after a decade of not touching anything Code related, and only vague memories About the FSO net Code, i'm wondering, wouldn't this require a crap-ton of coding work?
Less than you'd probably imagine. FSO already supports a "headless server" mode, it's just a matter of packaging it up in a way that can be used by cloud services like docker or kubernetes.
There is some work left there to make sure that a server can be started without requiring the full mod pack and retail; most cloud services offer machines that are somewhat space-constrained, and reducing the storage requirements would be good.
Is the 'cloud service' the 'host'?
Yes.
Who can access the host options one currently has?
To be decided. Personally, I tend towards not offering more configurability than "what modpack to use"; but this is something that needs to be explored.
Wouldn't it require changes to the game, to access these functions via cloud from within the game?
Yes, but I see this as a concern for later. Getting a proof of concept up and running that you can connect to by entering connection details manually is acceptable to me as a first attempt.
Can that be run off of Nebula server(s)?
Unknown. That's something we'll find out once we know how ressource-intensive this thing would be.
Could the whole proccess of creating/joining a multiplayer game player-side be handled via Knossos interface (obviously not with its current state, a "Multiplayer" tab would be needed :P )?
What about "integrating" this with some sort of a chat service, for example Discord? I mean, the "automatically invite your specified friends to your game" thing, realised via automatically sent private messages, for example. I'd prefer using some existing service for this as attempting it via Knossos and Nebula accounts would need you to have some additional notification service in the background...
Or maybe, just have a Discord bot track and show currently available games, or at least ping invited people?
Both of those are good suggestions. My priority would be to develop the backend services first; building a discord bot that talks to that backend would probably be easier than trying to build a web frontend.
-
My main thought is will it probably be difficult to set up test builds with this system for other changes besides this project?
-
A frontend for the docker setup as a whole, or just the FSO standalone itself? We already have a WebUI for that.
-
I have built a Docker image for running a standalone server and added some automation for that. We now get new images build with every nightly that can be used for getting a standalone server up and running: https://hub.docker.com/r/scpfs2open/fso-standalone
-
Not sure if anything happened with this in the mean time but I needed an excuse to do something with Go so I implemented a small microservice that can start and manage an FSO standalone server via a gRPC API: https://github.com/asarium/CommnodeWorker
It's not really useful in its current form but it's something :p
I'm currently looking into building an API into Knossos so it could be used for downloading and installing mods automatically.
-
Oh, hey. Now I know where the grpc error messages keep coming from. Can you disable the automatic error reports in your Knossos settings?
Also, if you need another excuse to work with Go :lol:, you can take a look at the new Knossos/Nebula code (https://github.com/ngld/knossos/tree/nu). There's not too much there because I'm trying to finish a bare-bones version of Nebula before I start working on rewriting Knossos. That said, the client-side and server-side code will be written in Go (UI stuff still happens in JavaScript, though) and I'm using Twirp (a simplified version of gRPC that's compatible with HTTP/1.1 and HTTP/2) to talk between the different parts.
If everything goes as planned, I can probably make a headless version of the client and expose the API that the UI code uses over Twirp or gRPC. It'll take a while until I can actually work on that but I'll keep it in mind while I plan the API.
-
Oops, seems like I copy/pasted too much when building the server :D
Anyway, the Python variant is not really working out though since it uses excessive memory. It's up to 2.5 GB at least for me locally which is just too much for this workload.
As long as there is a relatively self-contained Go module which I can pull in to write my API, I will be happy :p
I would like to help at least with this part although I am not sure if that is feasible at this moment with so much still in flux in the implementation.
-
Anyway, the Python variant is not really working out though since it uses excessive memory. It's up to 2.5 GB at least for me locally which is just too much for this workload.
The repo.json is 150 MiB by now and Knossos keeps a decoded copy in memory. That was a bad idea...
As long as there is a relatively self-contained Go module which I can pull in to write my API, I will be happy :p
I would like to help at least with this part although I am not sure if that is feasible at this moment with so much still in flux in the implementation.
The plan right now is to write as much as possible of the client-side code in Go. The only exception is libarchive which I'll use to extract the mod archives (I'll use cgo to link against it). I'm focusing on finishing a barely functional version (Nebula will be read-only for now and Knossos can't upload anything or create local mods). I'll let you know once I'm done with basic mod installation.