The Castle Doctrine Forums

Yeah I was thinking the server would include metadata with the request about whether they're go for asynchronous mode, but the client doesn't need to know why it's in asynchronous mode. So for your light example, let's say there's a small room with the light in it... After they move into the room and have it explored, the server can detect that there are no more changes occurring and tell the client they're ok to move freely. Once they go near an unexplored section or hit a button to trigger a circuit change for a circuit which isn't fully represented in the room then the client would detect that it needs more information from the server to see what happens next (since it doesn't have all the required data) so it drops back into synchronous mode.

My assumption here is that changes to the house can only be initiated from things within view (or things out of view which were initially triggered by something in-view) the server pseudocode for determining asynchronous eligibility before sending a move reply back to the client may look something like:

if there may be a reaction to the player in the tick after this one (animals/family in movement [only mechanisms that have any delay/continuation right?], on-screen or off):
  suggest sync
else:
  suggest async

Then client pseudocode for what to do with a new move request from the player:

if async was last suggested, no circuits potentially leading off-screen have been triggered, and no new tiles may have been revealed:
  simulate change client-side and queue the movement to send to the server later
else:
  send the movement, along with any queued movements, to the server and await reply synchronously

It seems like that fully prevents the client from getting out of sync from the server because of how the circuits seem to execute and finish immediately and how it seems that your family/pets only react to the player in view (which means if there are no family/pets in view and no new tiles revealed there can be no off-screen reaction). The exception is if you scare the family and they start moving off-screen (do cats move off-screen too? same thing applies if so) they will continue to move even when off-screen, correct? In that case while the server knows the family is moving it just tells the client to behave synchronously.

I suppose if the family was the only thing that could move off-screen (aside from player-triggered circuits which seem trivial to detect by the client) then the client would already know it needs to be synchronous the first time the family pops on the screen. Once the family leaves the exit the server could then notify the client to return to async mode, barring any active mobs.

Seems like it works, but I may be overlooking mechanism edge cases, and perhaps the occasional benefit it awards is exceeded by the complexity.

Edit: Also, if you move from one room to another without changing anything, the client could keep track of the tiles you'd visited since your last change (animals/family/switches) and let you return to those tiles asynchronously even though they'd since been clouded by fog of war. Once you trip a change it can clear your list of previously visited tiles so that you'll have to synchronously re-explore previous, no-longer-visible tiles.

I agree with der that because it's step-based, timing isn't so critical. Personally I take more than a few seconds with each move when raiding, sometimes 10 seconds per move with sweat beading down my forehead But I'm pretty new to the game still so take that with a grain of salt.

As far as predictive behavior goes, I'm not sure that applies so well here because it's discrete steps (ok, even FPS games have discrete steps but not cognitively discrete) not a continuous stream like with FPS games.

However, maybe you could do something like signal the client that it can operate in autonomous mode while there's no "hidden activity". ie, when you walk into the house, before any animals or family see you, before you trigger any circuits, etc... It can operate asynchronously and not wait for confirmation from the server unless you've walked somewhere that revealed new data or triggered something. Once one of these triggers happens it cuts off asynchronous at that point and the server won't accept any new asynchronously made instructions after that point. It should be possible to make the client aware of when it's triggered this condition (even if it doesn't know why or what the results are) so it won't be necessary to rewind the player experience.

[edit: to be clear, after mechanisms/animals/family/etc has stopped moving, it could return to async mode]

Hard to say what % of the time it could be asynchronous as described with a hypothetical optimal async-allowed detection heuristic, but if players do a lot of walking back and forth it seems like a lot of that could be async.

Down side, of course, would be that hackers could detect when the client has gone into async mode (heck, a non-hacker could probably even tell by whether it's zippy or not, perhaps that could be alleviated by introducing a short delay always) so they could know if they tripped some mechanism which is still in motion which they perhaps might not have otherwise noticed (since it may not be in view)... But that still seems like a huge improvement over the current state of the issue as you described it.

Other downside is complexity :'(