Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Programmed Server Delay: solution to RTS, but also more #2427

Open
Corbeau-1 opened this issue Oct 28, 2024 · 0 comments
Open

Programmed Server Delay: solution to RTS, but also more #2427

Corbeau-1 opened this issue Oct 28, 2024 · 0 comments
Labels
enhancement New feature or request Untriaged This issue or PR needs triaging

Comments

@Corbeau-1
Copy link
Contributor

What:
In short: delay transfer of information on unit movement from the server to some of the players (clients) for X minutes/seconds.

Why:
Firstly, this may be a solution to RTSing.

How to prevent reacting in real time to your opponent's moves: you can't react in real time if you don't get the information in real time. A major problem with RTS is a player picking off enemy units as they move, which requires being online at the right moment and then clicking quickly enough, which is a complete opposite from what Civ is supposed to be. Also, reinforcing cities that are under attack, or interfering with the invading force in any way that would be impossible if you are offline during the attack.

With server delay, you can't react because you don't know what's going on until later.

Secondly, this adds a massive dose of realism to the game. In real warfare, generals in the HQ usually don't really have direct info about what's happening on the frontline. They rely on reports that are delayed most of the time. There would either be guesswork and blind moves or sitting and waiting for everything to unroll, knowing things have already happened.

How:
When a player moves a unit, information is passed to the server. The server immediately returns the result to the player's client and also to his allies and players he is sharing vision with. The others, however, receive this information after X seconds have passed.

If a non-ally moves his units into the area, he gets a pop-up saying:
"Enemy movement detected, information pending. Proceed? (Y/N)"
"Area" here can be defined either by:

  • narrow variant - tiles that saw enemy activity (movement or attack)
    or
  • wider variant - tiles that have belonged to the enemy's ZoC at any moment during previous X

This would probably require attaching a time counter to every tile.

If the player waits and tries again later, when the fog has cleared, server is no longer delayed and game continues in a normal fashion.

However, if the player proceeds with movement/action in spite of not having exact information, the server resolves any possible conflict in real time, but only sends the report (Messages window) after the required time has passed.

There may be an issue with responsivity of units that have been destroyed and cities that have been captured during sever delay.

1st option is that, if a unit is destroyed, the player can see it, but can't move it anymore. Similarly, if his city has been captured or destroyed, it is still visible, but slicking on it yields no result. The problem with this option is that this would tell the player immediately what has happened - not full detail, but to some extent - and he would be able to respond much more quickly (although he doesn't know what killed his unit, how many forces are there, what is their next target etc.).

2nd option is to keep a separate version reality on the server for each player entering a busy area. This would mean that the player is still sending move orders to a unit that perished 20 seconds ago and is operating a city that isn't his anymore. All would become known and reality adjusted once delay time expires. (Funny extreme possible event: it may happen that a player is sending orders to a unit to attack a visible enemy unit where both units are already dead. War is hell.) This would be much more in line with the whole idea, but probably much more complex to program.

@Corbeau-1 Corbeau-1 added enhancement New feature or request Untriaged This issue or PR needs triaging labels Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Untriaged This issue or PR needs triaging
Projects
None yet
Development

No branches or pull requests

1 participant