I want the dead players to be able to watch environmental changes for a few seconds (or a fix amount of time) before they are cut off from the server. How can I achieve this?

I am thinking of using a timestamp. So when the player is dead I record the time for that player and a few seconds later I loop through the player list and disconnect the players that have been dead for certain amount of time. The problem is I loop through the player list at a fix interval which is about 10 seconds. Some players may get disconnected early and some may get disconnected after a longer period because if they miss current loop they need to wait for another 10 seconds to be disconnected.

Another problem is that on client side I don't see any environmental changes after the player gets killed. It just stops there and looks like connection is lost. (I don't have any client data controlling the updates, all the data comes from the server).

Most game engines will have a priority queue of timed events.

Thus, you won't check all the things that could happen, "have you happened yet?"

Instead, you'd insert a record in the event queue saying "call this object function at this game time."

The game loop will then, in each simulation tick, advance time, then run all the event records that have a time less than or equal to the new game time.

That way, when the player dies, you simply insert a record saying "disconnect this player after 7.3 seconds" and it will happen at the right time.

This mechanism is often used for other things, too, such as the expiration time of buff spells, expiration of invites, and so forth.

@hplus0603 Thank you. I am not using a game engine. I just build everything from scratch, for a simple game of course. I am not sure if a simulation tick means a update tick. But if I have such an event queue as you described, do I have to check the events in the queue in each update tick? I wonder whether it will put more burden on server or not if I put all the events in the update tick? In my game the update tick is 60 ticks /s and I do a network update at an interval of 10 times/s. Currently I am checking those status changes and events in the network update at various interval (100ms, 300ms, 500ms, etc.). And it is working nicely. But I always wonder if there is some subtle problem later on if I keep doing it this way. 

Construct a new "muscle-less" state, where player is alive, yet unable to move. Instead of dying, you switch to that state, and you have full control in the player when it switches to dead state.

4 hours ago, caymanbruce said:

do I have to check the events in the queue in each update tick? I wonder whether it will put more burden on server or not if I put all the events in the update tick?

You're worrying about nothing. The suggestion here is just to have a single list of events, ordered by time, so that on average you will only examine a single event every tick! There's no point having a 1/60 second tick if you're not willing to actually do anything with it.

do I have to check the events in the queue in each update tick

You should look up the "priority queue" data structure, which is generally implemented as a heap.

This means that insertion is O(log N) and extraction of the next event to run is O(1)

Even if the queue is just a big ol' vector, insertion will be O(log N) for searching (binary search) and O(N) for the memcopy to make space for the event in the vector; turns out memcopy is very very fast compared to chasing pointers so that O(N) is unlikely to dominate.

Compared to scanning all players and other entities for all possible events every simulation tick, this will be a lot more efficient.