🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Awkward collision avoidance situations..
Author
If you''re travelling close to the wall and there''s an obstacle too close to pass between it and the wall, what do you do? Or with two rocks and you can''t get between them. Naive avoidance code will end up leaving you stuck between them. What''s a nice way to do this - prioritise the closest rock as the one to avoid?
quote: Original post by d000hg
Naive avoidance code will end up leaving you stuck between them. What''s a nice way to do this - prioritise the closest rock as the one to avoid?
Don''t use naive avoidance. You must take in count for the size of the bot.
[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]
Author
Well currently I just try to avoid what''s in front of me. Thinking ''I''ll nip through this gap'' is a whole level of complexity above this. I guess you could look to see if where you want to go there is a free path wide enough, using simple geometry, but if you''re moving parallel to a wall you can''t see it to make these checks.
I have a variable called DistanceTraveled and every frame that I move forward, it gets increased. However, if I make a turn, I reset it to 0. If DistanceTraveled gets to a somewhat large number, I can deduce that I am stuck on something. I can then reverse a few units, and change my direction.
I also have a function called FindClosestObject() that returns the index of the closest object. I don''t know how you''re doing your avoidance code, but I use that function to find out what I should be avoiding.
I also have a function called FindClosestObject() that returns the index of the closest object. I don''t know how you''re doing your avoidance code, but I use that function to find out what I should be avoiding.
Well, this is quite odd and somewhat stupid, but I make my bot to turn left fast, ie, 180 degrees, every 6 seconds when it hasn''t seen the enemy. It helps my bot to get out of places where it''s stuck; and it works 95% of the time.
"We know you''re in here, poppet!" - Pirates of the Carribean
InitGames Software
http://www.initgames.breezeland.com/
"We know you''re in here, poppet!" - Pirates of the Carribean
InitGames Software
http://www.initgames.breezeland.com/
Every six seconds? It seems like you''d just end up pacing back and forth if you did that. The method I use above is pretty similar, except that I check for a lack of an object every few seconds; not an enemy.
Then again, your (earlier revision) bot pwns my bot, so I shouldn''t talk
Then again, your (earlier revision) bot pwns my bot, so I shouldn''t talk
oh wait, if you mean when two models overlap, just test the distance between the two objects.
the radii for the objects is in the readme file.
the radii for the objects is in the readme file.
i would change the way you calculate your distance travelled var. Only increment it by the distance between your current (new) position and your position from the previous frame. If this value doesn't increase between frames by some reasonable amount, then you're stuck. It would avoid the obvious problems of "if my distance travelled gets too big then i'm stuck".
[edited by - MelvinElvin on August 13, 2003 8:40:58 PM]
[edited by - MelvinElvin on August 13, 2003 8:40:58 PM]
Author
An obvious choice would be to make some kind of map in memory. However how do you keep this correct when you could easily get stuck when reversing/strafing in a dog-fight situation? I guess you could make a very basic pattern matcher to recognise ''constellations'' amongst objects and thus correct your map, or use the walls somehow. If you can find a corner you can locate yourself well, but finding it is tricky!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
