I'm wondering why there aren't any tools to automate the generation of an authoritative game server? It appears to be a simple task. However I've only worked in simple 2d games so I'm not understanding the complexity of other games that would make this impossible.
For example, if one built a client game, it seems it would be quite simple to extract
And then simulate 1 with 2 on a server.
Bjarne Stroustrup once said:
"If you think it's simple, then you have misunderstood the problem".
In the real world, creating an authoritative server is more complex than "just" moving all the logic to the server and all the input and rendering to the client.
A completely authoritative server is usually not feasible. If you move everything to the server, then your server-costs will go through the roof and your will generate so much network traffic that players with bad internet connections will have an awful game experience.
You have to decide what's really worth handling authoritively and what can stay on the client. For example, does it really matter if the smoke particles of a fire are controlled by the server? Isn't it just cosmetic? Or maybe it's not because players can use those smoke clouds to hide in? This is a decision you have to make consciously for every system in the game.
It's usually not "quite simple to extract" the logic and the input handling. The decoupling between the systems you want to move to the server and the systems you want to keep on the client will not always be as clean as you would imagine it. In a real-world codebase, you will always have dependencies creeping in. So moving a system (or part of a system) from client to server will usually imply some serious refactoring.
When a system moves to the server, then you now have a couple ms of latency. This is something you need to design for. Function calls that were simple getter-functions now suddenly require an asynchronous request with callback. You might need to build some prediction and/or interpolation to keep the illusion of a fluent game experience. Which will usually require custom algorithms depending on what data you are dealing with and how you expect the server to answer to requests.
A client-server application requires a netcode protocol. What data needs to be synced each frame? What data needs to be synced only when it changes? What data should be synced through a request-response model? What data doesn't change, so it only needs to be synced on startup? What data is irrelevant so it doesn't need to be synced at all?
Oh, and what happens when there is packet loss? Is the information so important that you need automatic confirmation and resending on fail? Or will the next update take care of this?
These are usually not decisions you can make automatically. And the decisions you make here usually have wide-reaching consequences on the architecture of both the client and the server.
So bottom-line is: No, you can not solve this with a tool. You will have to do a lot of manual software engineering to turn a non-trivial single-player game into a game with an authoritative server.
the physics world and related elements, player inputs
You forgot the third vitally important part of a game, taking the game state and presenting it to the user.
Looking something up in a local data structure takes microseconds at worst (and less if it's in CPU cache), looking something up over an internet connection likely takes milliseconds at best and more likely tens or hundreds of miliseconds, on a bad day I've seen latencys get up into the seconds. A frame is of the order of 20 milliseconds, so on a good day you might get tens to round trips per frame and on a bad day you might be waiting numerous frames for a round trip.
So you can't have a client render a frame by making a bunch of synchronous requests for information from the server. Even a single request may receive a response several frames after it was sent. So generally whatever you choose to send must be sent in a largely asynchronous manner.
At one extreme you could use a "remote play" approach, the client sends requests to the server and gets a video stream back. All the chatty code sits on the server. You could also do a variant of this where, instead of sending a video stream you sent a series of drawing commands.
This is very secure and potentially allows a lightweight client, but it needs both a powerful server and a fast, stable low-latency network. It's usually ruled impractical for these reasons.
At the other extreme is the fully synchronised game state approach. Player (and sometimes AI) inputs are distributed to all the clients, which then maintain their own copies of the complete game state. This keeps network traffic to a minimum and means the server can skip UI code and handle only game state. Sometimes you can do this without even having a "server" at all.
But it creates a few problems.
So many games end up with a hybrid approach, the server has a complete copy of the game state, clients have partial copies, for which the server sends updates in an asynchronous manner. The client then uses this partial copy of the game state to render the game.
Most of the simulation happens on the server, but some parts may be pushed to the client. In particular in first/third person 3D games the player character's movement is often simulated on the client and only later sent to the server. The server must then try to reconcile what happened on the client with what is happening on the server. Doing this in a way that minimises the scope for cheating and minimises noticeable artificts, while also hiding as much of the latency as possible from users is probably one of the biggest challenges in competitive shooters.
It's easy if the game is designed in a way that makes it easy. In particular:
Latency is an issue, but it can be solved by having the client run its own copy of the rule logic. If the repeatability condition holds and the client is not cheating, the server will get the same result.
However, many games have rule logic that is heavily interconnected with the visual rendering. Usually the same game engine handles visual display and e.g. collision detection, and may not support separating them. Getting repeatable results while minimizing latency from control inputs to rendering has its own problems, but there are solutions for this such as running the physics simulation on its own thread with timestep independent of the frame interval.
If the need for an authoritative game server is taken into account early in the project, there is no particular need for a tool - rather, the need is for a game engine and libraries designed to be used in this way. And if the game has already been made, the task can be close to impossible without also refactoring the client game to well separated portions - a task that is currently beyond automatic tooling.
Like you allude to in the comments, a basic authoritative server does not really solve all cheating. As long as the rendering is done on the client side, it is possible to make walls transparent or highlight enemy players.
To take the concept to extreme, you can use technology similar to cloud gaming services, where the client just streams video and sends control inputs. These have unavoidable tradeoffs in bandwidth and server resources needed and the input latency. But as evidenced by the available services, it is straightforward to run existing games in the cloud and stream video to clients, and this would be the "ultimate" authoritative server.
It is indeed trivially easy*
As Valheim and Satisfactory prove, extracting an authoritative server from your game is indeed trivially easy,
Then it's not that much more than creating a build without the graphical frontend, inputs or own player-related things and there you go, the server is done. [It is of course a bit more complicated in reality, but not immensely more so]
Where this conflicts with your approach though is that the extraction that you want a tool to magically do was done at the very start when the architecture, structure and so on was planned by experienced human software engineers.
