you're recomputing it every turn, so you can treat actors as obstacles; simply make tiles that are taken non-traversable (same as you'd make a boundary wall). When moving each actor, by flowing downwards, if they collide then undo the move and select the next best downward tile. In the case he's surrounded at the start of the turn, the flowfield will simply not allow him to move (he'll be surrounded by obstacles). If he's surrounded by newly moved actors, he'll bump into people in all directions, and not move.
Assuming the crowd keeps moving, the problem will naturally resolve itself eventually (and the results are the same as if you'd done direct pathfinding -- a traffic jam is a traffic jam).
There's also the possibility an actor gets stuck holding the door: He's the last to move, so by the time he takes his turn, he's surrounded again; The gamey solution would be to cheat and let him phase through or temporarily merge with an actor.. alternatively increase his iteration priority if he doesn't get to move, so he gets the first move next turn.
But in the case of this simulation, such extreme crowding is an unnecessary edge-case to care about, since the goal really is to simulate to the point when crowding just starts to occur, so just "bump and undo" collision logic is probably more than sufficient.
If you want to go way too far, you end up with potential fields like [0] or [1] but I don't think a buffet line really necessitates that level of intelligent behavior
Assuming the crowd keeps moving, the problem will naturally resolve itself eventually (and the results are the same as if you'd done direct pathfinding -- a traffic jam is a traffic jam).
There's also the possibility an actor gets stuck holding the door: He's the last to move, so by the time he takes his turn, he's surrounded again; The gamey solution would be to cheat and let him phase through or temporarily merge with an actor.. alternatively increase his iteration priority if he doesn't get to move, so he gets the first move next turn.
But in the case of this simulation, such extreme crowding is an unnecessary edge-case to care about, since the goal really is to simulate to the point when crowding just starts to occur, so just "bump and undo" collision logic is probably more than sufficient.
If you want to go way too far, you end up with potential fields like [0] or [1] but I don't think a buffet line really necessitates that level of intelligent behavior
[0] http://grail.cs.washington.edu/projects/crowd-flows/continuu... [1] http://www2.cs.uregina.ca/~anima/408/Notes/Crowds/HybridVect...