9

I've recently switched my game engine over from steering behaviours to impulse based movement with proper time based collision resolution. This has solved so many problems (no more tunnelling, yay) and made the simulation a great deal more stable. However, with the stability has come a new problem.

Doorway collision problem.

The three balls started their journey near the bottom of the image, their target was where the pink ball has stopped. On the way the red and green balls have become stuck at the choke-point in the wall.

Before, I could rely on floating point errors and the general instability of steering behaviours to make the green and red balls jostle each other until they managed to get through the choke point. Now with proper collision resolution, the forces acting upon the balls cancel each other out which results in the balls remaining perfectly still.

What methods are commonly used to resolve such situations? Perhaps some sort of priority queueing system would work, though I can see it becoming complex once I need to decide priority between more than 2 objects.

Fibbs
  • 514
  • 2
  • 11
  • I'm also disappointed with steering crowd management. Could you please add some links about "impulse based movement" into the question? – Kromster May 11 '16 at 19:11
  • An impulse is just force * time. What I was trying to say was that I'd moved to a physically based model using continuous rather than discrete collision detection. Steering behaviours don't really respect things like Newton's laws of motion, they were designed to mimic flocks of birds rather than be a physics simulation.

    I don't really have any gamedev links for movement, it's really just highschool physics. However, Christer Ericson's book Real Time Collision Detection is pretty much the game dev bible for continuous collision detection.

     – Fibbs May 11 '16 at 20:11

3 Answers3

3

Assign each movable object a unique index & prohibit an object with a higher index from moving an agent with a lower index. This will allow 'older' objects to nudge 'newer' ones, but not vice versa & is less overhead than queuing. Essentially, the index acts as a movement priority.

Pikalek
  • 12,372
  • 5
  • 43
  • 51
  • 1
    I've implemented this and it works in that units no longer get stuck, though I have to say it isn't always pretty. Some caveats: only use the index to determine priority for moving objects of the same mass, large objects should push small objects out of the way naturally. Only use the index to determine priority for objects on the same team. An enemy object shouldn't be able to act as an immovable wall to a player object simply because it was spawned first and therefore has greater priority. – Fibbs May 21 '16 at 13:36
  • I hadn't considered mass or team; your tweaks seem like the logical way to patch my answer. – Pikalek May 21 '16 at 20:46
2

add time to path finding

here is a paper that talks about that time cube: http://www0.cs.ucl.ac.uk/staff/D.Silver/web/Applications_files/coop-path-AIWisdom.pdf

enter image description here

and here is an Objective-C implementation: http://allseeing-i.com/ASIPathFinder

enter image description here

Rakka Rage
  • 401
  • 3
  • 12
  • 1
    I've read about and implemented this before. Even with multiple threads it isn't much use in my situation. In an RTS game there can be hundreds of moving units and map-grids that are greater than 500 squares to a side. The overhead for calculating time based paths for each unit is just too high.

    Just to add, I'm not saying rakkarage's answer is wrong, it is a very neat algorithm. I'm just saying that the situations in which it is useful are limited by its complexity.

     – Fibbs May 21 '16 at 13:48
  • ya i just re-run my whole path finding algorithm each turn instead of fully comprehending and implementing this but i figure i might have to eventually – Rakka Rage May 21 '16 at 16:29
0

Actually, i don't think you should fix it. If (i may guess) the arrows indicate force vectors applied to any sphere, at any position in the grid (probably interpolated "bi-linearly" or likewise, or somehow more "analog" than just being 0/1), well then the behaviour is physically correct and you should congratulate yourself for having a well behaving solution.

The 2 spheres are in a good balance, as they sit there and hate each other. Apparently, if they move a bit to right, the "force arrow" to right affects the right side sphere a bit more (and vice versa on the left side sphere; a bit less), and so they move back to balance. This is how it should be.

Imho, what should be fixed is the wall, or the sphere sizes, or something else among the buildstones themselves. You have created an impossibility and the correct behaviour in that situation is accordingly a deadlock (sorry for misabusing words, i hope you get them anyway :-)).

Perhaps instead disable the nearest left/right force arrows, or arrange them in some other way that is not symmetrical and does not encourage to balance?

I think it would be a bad fix to artificially fix it... would get hairy too early.

Stormwind
  • 1,063
  • 5
  • 5
  • This doesn't answer the question. I understand your motivation, but ultimately the question is how to deal with the situation. We don't know the gameplay intentions, so judgement wether this is a problem or not is up to Fibbles. Changing the wall may change the purpose of the chokepoint. The question is a valid problem that can be solved. – Felsir May 19 '16 at 18:53
  • My answer is bascally: (re)arrange the forces or re-arrange something else in the scenario but do not scramble the physics solver ("Imho, what should be fixed is the wall, or the sphere sizes, or something else among the buildstones themselves."). The question is "What methods are commonly used to resolve such situations?" I think my A is very much a "commonly used method" and very much a solution to the problem. For example online minigolf games (which the Q reminds of do very much) do choke the balls, if the environment is calling for that to happen. Erratic physics is a bad way, imo. – Stormwind May 19 '16 at 20:33
  • I agree that the physics solver should remain in tact. The question states the spheres should seek the target, basically how to change the behaviors of the agents (thus not the physics or the level layout). Altering the level layout may solve this occurence- but it mey crop up in a different layout. So the question is different than the minigolf example you provide since in this instance the question is to specificly avoid a deadlock. – Felsir May 20 '16 at 08:31
  • As you see, i also propose re-arranging the forces in the answer. Seems to be little left after that :-). – Stormwind May 20 '16 at 09:47
  • Rearranging the walls or altering the sphere sizes is not viable in my case, though it may be in others. The screenshot is from the debug mode of an RTS engine. There are many different unit sizes and the walls can be placed at will by the player.

    The arrows you see are generated by my Fast Flow Fields algorithm. They are normalized vectors which are used to influence the direction of travel of the movable units. It is not possible to alter the length of the vectors because all movable units in the group share the same Flow Field.

     – Fibbs May 21 '16 at 13:46
  • Hm, not too many options left. How about resolving (predicting) a "pass through right/order", ie. as a ball (or unit) enters for example a 5 block radius from any choke point, give it a place in a que. Then alter it's physics behaviour so that it can enforce itself through (win the other, or multiple others, or slow down others accordingly). After that, the next in que can do the same, and so on. A choke point is a choke point, so something must be made irregular to create an unbalance in a balanced system. The queing would be like a fake full-forward-simulation for time scheduling. – Stormwind May 21 '16 at 20:11