.
🎉 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!
Why mapping?
Yes, it''s pretty annoying having my FOV lines in a wall, yet my bot can''t see it. If he fixes that issue, I''m pretty much set, as that was the only thing (sliding on a wall) hindering me from building the map properly .
.
quote: Original post by Ready4Dis
I had a map calculating thing, but the screwy wall collision (and wall in view) routines screw the map up completely, so I dropped it. I had it building a map based on the objects I saw oriented to the original start position, and it worked great until I either hit something not in view, or slid along a wall. I don''t think it should all be given to you, but there should be some way of figuring out how far you moved, in real life (paintball example), you KNOW when you stopped, or walked into a tree, etc, so you know you stopped moving. In a FPS, you know when you are sliding because you can see it and react to it, but the bot has no such indications, so you can''t react to it.
i don''t know. maybe i''ve approached things differently but i like things the way they are. and i hope the effort i''ve put into the navigation module of my bots doesn''t go to waste.
if you run headlong into a tree (most of us aren''t that dumb) you might flail around for a bit, but the way a human figures it out is by his surroundings to see exactly where he is.
The bot can do the same thing.
I''ve programmed mine with a standard human-like orientation (or disorrientation) so it''s fine now for the entire map. Knows where everything is, and if it gets lost (walks headlong into a wall and can''t see anything) it can find itself again quite happily.
I also hope that it doesn''t get changed, although I do admit that if we could find out something like if we didn''t move the full length it would make it overly easy, but would save me about 30 lines of code and around 528bytes of extra data.
If it isn''t atleast semi difficult, whats the point of having a contest?
The bot can do the same thing.
I''ve programmed mine with a standard human-like orientation (or disorrientation) so it''s fine now for the entire map. Knows where everything is, and if it gets lost (walks headlong into a wall and can''t see anything) it can find itself again quite happily.
I also hope that it doesn''t get changed, although I do admit that if we could find out something like if we didn''t move the full length it would make it overly easy, but would save me about 30 lines of code and around 528bytes of extra data.
If it isn''t atleast semi difficult, whats the point of having a contest?
quote: Original post by Dredge-Master
if you run headlong into a tree (most of us aren''t that dumb) you might flail around for a bit, but the way a human figures it out is by his surroundings to see exactly where he is.
The bot can do the same thing.
I''ve programmed mine with a standard human-like orientation (or disorrientation) so it''s fine now for the entire map. Knows where everything is, and if it gets lost (walks headlong into a wall and can''t see anything) it can find itself again quite happily.
I also hope that it doesn''t get changed, although I do admit that if we could find out something like if we didn''t move the full length it would make it overly easy, but would save me about 30 lines of code and around 528bytes of extra data.
If it isn''t atleast semi difficult, whats the point of having a contest?
Yes, but how do you handle things like when you walk into an object that you didn''t ever see... or slide across a wall? How I was building my map, it was based on knowing how I was moving, which ultimately failed once I didn''t know how far I had moved (sliding, getting stuck on something out of view, etc). Obviously, I can check if the distance moved against another object in view is correct or not, but if it''s not, I still don''t know which direction I''m off by. Maybe I slid left a bit, but the distance on tells me how far I should be now, doesn''t say which direction I could have moved. I''d be interested to hear how you are mapping the entire world and handling these cases, but if you don''t want to give out your secret, that''s cool too
.
quote: Original post by Ready4Dis
Obviously, I can check if the distance moved against another object in view is correct or not, but if it's not, I still don't know which direction I'm off by. Maybe I slid left a bit, but the distance on tells me how far I should be now, doesn't say which direction I could have moved. I'd be interested to hear how you are mapping the entire world and handling these cases, but if you don't want to give out your secret, that's cool too
That's how my first version worked, and of course the map broke when the bot slid on a wall. But I've just added some code to calculate how far it's actually moved. As long as it can match some objects in view with objects in its map (which is very easy - at least if you're using the simple, brute force approach as I am) you can calculate where you've actually moved, and use that to compensate if you back into a wall and slide.
Right now, I'm thinking about what other information I can use from the walls. My code already matches walls to check for movement as a boolean (so if you back into a tree, and the only thing in view is a wall, it can compensate) but I think it may be possible even to compensate for sliding against a wall - even if the only thing you can see is the wall you're sliding against.
Edit: I'm not actually going to give you my code, for 3 reasons: 1) It's very, very easy to add, if you've already got boolean movement checking. 2) This is a contest. 3) I want to see how other people handle it, and the more people that write code completely on their own, the more ways it will be handled.
John B
[edited by - JohnBSmall on August 13, 2003 9:44:17 PM]
'Tis a simple matter Ready4Dis
x=|F|Sinß
y=|F|Cosß
F being the distance, ß being the angle
I use
double Theta,Cos,Sin;
_fm_sincos(Theta,&Sin,&Cos); (same speed as a single _fm_sin or _fm_cos)
nb; I use the fastmath.h version. I use the _fm_ calls incase I also link in math.h.
nb; I don't know if MSVC has fastmath. The server I use is written in BCB5
That way you can get your x and y position.
Whenever you turn, there is NOTHING stopping you from turning. only moving backwards and forwards.
So the direction will always be aligned correctly.
After that, fish out the relative x and y (or you can use the direction if you wish, I find the x and y method faster for data handling though when you save the objects - even though there is only 26 in gdarena, still faster with the amount of parses) and use that for comparison.
Everytime you see something, compare it to a reference copy (one from the previous fram). if the offsets (x and y) are different, just bump the player offset so it is correct. The direction doesn't matter after this
Hope that gives you a hint as to what I did. I don't want to give it all away as I plan on going into the competitive side of GDArena, not the fun one, but at the same time I don't mind helping everynow and then
edit for typos and an addition
About fast math if you haven't used it.
its the math.h library and header without any error checking. bascially faster
sincos in the normal math.h is for sincos with error checking
if you include fastmath.h but not math.h, both _fm_sincos and sincos will use the fastmath version
if you include BOTH math and fast math, you can create a define (check fastmath.h or its header for the define) and it will automatically use fastmath.h functions over math.h ones.
[edited by - Dredge-Master on August 13, 2003 11:20:33 PM]
x=|F|Sinß
y=|F|Cosß
F being the distance, ß being the angle
I use
double Theta,Cos,Sin;
_fm_sincos(Theta,&Sin,&Cos); (same speed as a single _fm_sin or _fm_cos)
nb; I use the fastmath.h version. I use the _fm_ calls incase I also link in math.h.
nb; I don't know if MSVC has fastmath. The server I use is written in BCB5
That way you can get your x and y position.
Whenever you turn, there is NOTHING stopping you from turning. only moving backwards and forwards.
So the direction will always be aligned correctly.
After that, fish out the relative x and y (or you can use the direction if you wish, I find the x and y method faster for data handling though when you save the objects - even though there is only 26 in gdarena, still faster with the amount of parses) and use that for comparison.
Everytime you see something, compare it to a reference copy (one from the previous fram). if the offsets (x and y) are different, just bump the player offset so it is correct. The direction doesn't matter after this
Hope that gives you a hint as to what I did. I don't want to give it all away as I plan on going into the competitive side of GDArena, not the fun one, but at the same time I don't mind helping everynow and then
edit for typos and an addition
About fast math if you haven't used it.
its the math.h library and header without any error checking. bascially faster
sincos in the normal math.h is for sincos with error checking
if you include fastmath.h but not math.h, both _fm_sincos and sincos will use the fastmath version
if you include BOTH math and fast math, you can create a define (check fastmath.h or its header for the define) and it will automatically use fastmath.h functions over math.h ones.
[edited by - Dredge-Master on August 13, 2003 11:20:33 PM]
I have 2 problems with this comp.
1)The contradiction between making it realistic - how a real bot can act - while also denying us information a real bot could obtain about the world. A real bot can see the wall in front of it but the arena does not permit this. A real bot can tell if its efforts to move fail (wheels slip/trips over/basic motion sensing technology). A real bot can relatively easily be made to detect roughly from what direction it was hit with something.
2)My personal problem is that my normal development process fails here. I''d normally make a simple system and slowly improve it. But a simple system cannot successfully even ensure not to get stuck in GDArena. It seems we need to start of with a reasonably complex algorithm just to do collsion avoidance which I happen to dislike. Just my pet peeve!
1)The contradiction between making it realistic - how a real bot can act - while also denying us information a real bot could obtain about the world. A real bot can see the wall in front of it but the arena does not permit this. A real bot can tell if its efforts to move fail (wheels slip/trips over/basic motion sensing technology). A real bot can relatively easily be made to detect roughly from what direction it was hit with something.
2)My personal problem is that my normal development process fails here. I''d normally make a simple system and slowly improve it. But a simple system cannot successfully even ensure not to get stuck in GDArena. It seems we need to start of with a reasonably complex algorithm just to do collsion avoidance which I happen to dislike. Just my pet peeve!
quote: Original post by JohnBSmallquote: Original post by Ready4Dis
Obviously, I can check if the distance moved against another object in view is correct or not, but if it''s not, I still don''t know which direction I''m off by. Maybe I slid left a bit, but the distance on tells me how far I should be now, doesn''t say which direction I could have moved. I''d be interested to hear how you are mapping the entire world and handling these cases, but if you don''t want to give out your secret, that''s cool too
That''s how my first version worked, and of course the map broke when the bot slid on a wall. But I''ve just added some code to calculate how far it''s actually moved. As long as it can match some objects in view with objects in its map (which is very easy - at least if you''re using the simple, brute force approach as I am) you can calculate where you''ve actually moved, and use that to compensate if you back into a wall and slide.
Right now, I''m thinking about what other information I can use from the walls. My code already matches walls to check for movement as a boolean (so if you back into a tree, and the only thing in view is a wall, it can compensate) but I think it may be possible even to compensate for sliding against a wall - even if the only thing you can see is the wall you''re sliding against.
Edit: I''m not actually going to give you my code, for 3 reasons: 1) It''s very, very easy to add, if you''ve already got boolean movement checking. 2) This is a contest. 3) I want to see how other people handle it, and the more people that write code completely on their own, the more ways it will be handled.
John B
[edited by - JohnBSmall on August 13, 2003 9:44:17 PM]
Yes, but the problem is, you can walk into a wall without seeing it. This isn''t a problem with an object, because you stop completely, but with a wall it can become a problem because it may return that you see nothing, yet your sliding, so no objects to judge by, which throws the map off. Of course, I think I figured out a GREAT way to figure out where all the walls are, which would simplify a lot
.
quote: Original post by Ready4Dis
Yes, but the problem is, you can walk into a wall without seeing it. This isn''t a problem with an object, because you stop completely, but with a wall it can become a problem because it may return that you see nothing, yet your sliding, so no objects to judge by, which throws the map off. Of course, I think I figured out a GREAT way to figure out where all the walls are, which would simplify a lot
If you back into a wall, then there are almost invariably other objects (trees and rocks) in your FOV that you can use to track your movement, so it''s just not a problem.
John B
Khawk said that in a future version the FOV for walls will be 90 degrees, so there''s no problem. As for the solution to the problem, which is about to be negated, it''s very easy. And it''s not a coding or maths problem, just common sense.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
