54 minutes ago, Androphin said:
9 hours ago, SyncViews said:
I think commands are easier, as you can play them in order, and the command set can limit cheating.
...
When the player loads in they get the relevant partial state sent to them. They can then get updates, either poll or push, but no requirement to be doing it at specific intervals, the server runs the entire simulation, anything the client does is just for prettiness
Sounds good. But without intervals, what would trigger a poll? After a client fires a command? A bunch of commands are collected over time and after a certain amount of commands or time a request to the server is made?
You would under normal conditions expect a realtime and probably fixed interval. Either the server pushes change events, or you push/pull states. But you can allow for it to be OK for an interruption to occur and for it to quickly continue, if the client state is small enough.
I never tried something like this though, and its just a thought. Even MMORPG I have personally played relied on a consistent connection and would drop the player to the login screen if connection was lost.
As I said, more like a webpage/app. An instant messenger for example doesn't care about "intervals" it cares about a "post message" command, the ability to give a client when they load all the previous messages (the state) and a way to inform the currently connected clients of a new message (probably some sort of push event, but if connection is lost it might go back to loading the full state when it connects again). This is a lot less realtime simulation, so it depends on what you are doing exactly, if you want to move an army from one tile to another, and it says it will take minutes, even hours, you probably don't need or want to actually process that at 60Hz or even 1Hz.
I believe for example in EVE Online, features like skill training and industry are a lot more like this. You tell the game to add/cancel/etc. an industry job, change your skill queue, etc. and then there server just schedules an event (probably backed by a database) saying that its complete. It doesn't process every skill, job, etc. every tick.
54 minutes ago, Androphin said:
Server push could be a good way, if one player commits his commands, server pushes updates to the others?
Server push would work with this https://en.wikipedia.org/wiki/HTTP/2_Server_Push, right?
For push events over HTTP I would use a WebSocket which is pretty much like a normal TCP socket with some extra's. HTTP2 push is still part of the request, its more like if there is a "GET /blog-post", the server can respond with the document, but also be like "you probably want this image at the start of the post", to save a second request (for that <img> tag) and speed up loading.
54 minutes ago, Androphin said:
To address your last paragraph first: Do I get this right, that I can't let the client run and calculate its gamespeed by just it's fixed FPS of 60, even though he has sees only a simulation and only sends commands to the server who's holding the actual gamestate, because a farmhouse might produce on a fast device 20 bananas, where on a slow device with varying framedrops only produce 10 bananas, while the server calculates only 15 bananas can be really produced.
The player/client would take either 20 or 10 bananas out of the farm and wondering, why he has 15 bananas after the update.
If your relying on lockstep determistic simulation to keep states in sync, that is just a flat out desync. You can see it in various RTS type games, it normally drops the player or even the entire match. If it can recover at all, its normally by effectively "rejoining" and transferring the entire "save file".
If your relying on the server to tell the client its wrong, you get the "why he has 15 bananas after the update.". I have definitely seen it in say Minecraft (doing something like removing a minecart track just ahead of a fast moving cart, stopping it, the server gets your block change only after its copy of the minecart entity passed. After a few moments when the server syncs the nearby entities, your minecart teleports to the servers location).
54 minutes ago, Androphin said:
Sounds good too! The part with the "ambush" isn't entirely clear to me. If the server reply with "ambush", the client would than need to react to it in form of prettiness, right?
Yes, the "ambush" event would need to tell the client all the information it will need to display to the user. The point is the client had no way of knowing it would happen ahead of time. The client isn't running that part of the simulation and doesn't have that data. Again to use a website example, consider that the server knows every page on the site, but the client only knows the open one. When you "click a link" you have an idea of what you expect to get, but until you actually click it you don't know for sure.
EDIT:
To be clear, I am thinking your overall goal maybe has two parts.
-
A strategic part with a large number of players and the need to let players come and go as they want or as connection issues occur. Actions take a long time (minutes-hours) and there is a lot of things going on in total. But a single player can only see a small amount, and can only directly control a small number of things.
It seems to me for this the server can run the simulation only, and players can just see and interact with their individual "pages".
-
A more traditional RTS "match" for combat, with a small fixed number of players and a lot of moving objects (100's, maybe 1000's if you include projectiles, etc.). Transferring the state for so many objects frequently requires a lot of bandwidth, which is why many such games use a deterministic simulation and keep it fully syncronised.
Probably practically two games code wise.