Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

dalleboy

Why mapping?

This topic is 5449 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Why should we have to map the surroundings of the bot instead of concentrating on the AI for the bot? Everyone (that stands a chance of winning the contest) will have to do some type of mapping, the solution of this will be somewhat different but the results will be the same. The mapping is only one extra layer of the problem, and I think it is totally unnecessary. The GDArena API does not provide sufficient functions for checking if a move/turn/strafe/anything-else fails or not, and what the result of the move/turn/strafe/anything-else really is. You can only guess that the SetSpeed(SET_HIGH_SPEED) moves the bot 0.8888 units forward, but as SetSpeed will return true even if the move resulted in moving the bot 0.2672 units forward or 0.5367 units forward because of a collision with something else. My proposal is: - Add the function GetMyXPosition that returns the x position for the bot on the map relative to the left of the map. - Add the function GetMyYPosition that returns the y position for the bot on the map relative to the top of the map. - Add the function GetMyRotation that returns the rotation for the bot on the map relative to the top of the map. - Add the function GetNumStaticObjects that returns the number of static (rocks & trees) objects on the map. - Add the function GetStaticObject that returns information (type, position, radius) about a specific static object on the map. - Add the function GetXSize that returns the x size of the map. - Add the function GetYSize that returns the y size of the map. - Change the GetNumObjectsInSight and GetObjectsInSight functions to only handle non-static (enemy, grenades & ammo) objects. OR: - Change the movement functions so that they (in some way) report their (level-of) success and the result accordingly. [How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]

Share this post


Link to post
Share on other sites
Advertisement
I think the whole point of it is to let the Bot/Program learn the map by itself.

Think of it this way.
You get given a paintball gun and an exploding lemon (well its yellow like in gdarena).
Then you get blind folded and whacked in a forest.
Blind fold gets removed and you have to get your orientation back, and not get lost whilst you try and scon the other bloke with the lemon.

Share this post


Link to post
Share on other sites
quote:
Original post by Dredge-Master I think the whole point of it is to let the Bot/Program learn the map by itself.

I have nothing against the actual learning process, it is that the GDArena API is written in such way that it impairs the learning process.

A so-so working mapping is not hard to code using the GDArena API, I''ve already written one.

quote:
Original post by Dredge-Master Think of it this way.
You get given a paintball gun and an exploding lemon (well its yellow like in gdarena).
Then you get blind folded and whacked in a forest.
Blind fold gets removed and you have to get your orientation back, and not get lost whilst you try and scon the other bloke with the lemon.

If you run around in the woods with a paintball gun and an exploding lemon you would tell if you run into a tree, would you not?

I think GDArena would get a lot more entries if it where a bit easier to use.

[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]

Share this post


Link to post
Share on other sites
Well it does give you the distance to the tree and we know how big the trees are in gdarena.

Rocks are a bit annoying though as we can''t tell which are small or big though.

Share this post


Link to post
Share on other sites
quote:
Original post by dalleboy
quote:
Original post by Dredge-Master I think the whole point of it is to let the Bot/Program learn the map by itself.

I have nothing against the actual learning process, it is that the GDArena API is written in such way that it impairs the learning process.

A so-so working mapping is not hard to code using the GDArena API, I''ve already written one.

quote:
Original post by Dredge-Master Think of it this way.
You get given a paintball gun and an exploding lemon (well its yellow like in gdarena).
Then you get blind folded and whacked in a forest.
Blind fold gets removed and you have to get your orientation back, and not get lost whilst you try and scon the other bloke with the lemon.

If you run around in the woods with a paintball gun and an exploding lemon you would tell if you run into a tree, would you not?

I think GDArena would get a lot more entries if it where a bit easier to use.

[How To Ask Questions|STL Programmer''s Guide|Bjarne FAQ|C++ FAQ Lite|C++ Reference|MSDN]


I think the point he was making is that we don''t have a GPS system built into our heads, we have to use are sences to navigate our world reletive to everything else.

I can agree partly with the splitting up of static and non-static objects up in the get sight type functions, but it is not crucial since the objects can be split up in a function/class that manages your FOV (assuming you use one). Personally i like just having one list of all objects in your view, and then just sorting the list myself in a way i want to use it.

Anything todo with exact orientation though would make it to easy, and more harder for those like me with little experiance in AI (if it was pure coord based).

Just my opinion,

-J

Share this post


Link to post
Share on other sites
I can see exactly why we''re got given absolute positions, but I do think we should be able to tell if the direction we attempt to move in is blocked. For instance if you''re strafing you just can''t see anything!

Share this post


Link to post
Share on other sites
Aside from never letting your bot walk into trees or rocks, it''s relatively easy to determine how far you moved in what direction each cycle, as long as you have something in view, by comparing their previous distances/directions with their new ones.

For the part about static and non-static objects, it''s easy enough to sort them out on your own, or if you wanted, it would take very little time to write functions that did it for you.

For the part about GetXSize & GetYSize - the map is 320x240.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
i tell you what. if the interface to the arena is changed so that you can get fixed positions, directions, etc. out of it, then to me this contest becomes a dud and misses out on a large part of what is there to be learned.

you don''t need a map to navigate and you don''t need a map to keep the bot from getting stuck and you don''t need a map to do good.

a good part of a real bot''s AI is navigation and even today very few bots navigate via GPS. navigation is as much about AI as is any other aspect of this contest.

Share this post


Link to post
Share on other sites
I don''t think there is any need to be given information about your position, or even information about movement. When you''re playing an FPS (for example) you don''t get tactile feedback about whether you''ve hit something. All you get is audio-visual input, and yet it''s perfectly easy for you to tell when you''re moving, and when you''re not, and how far you''ve moved. You can even turn the sound off, and you can still tell very easily whether you''re moving, and how much, so therefore, the only required inputs to be able to measure your movement are visual, and your brain is simply converting this into positional information. So obviously, the inputs to the bot are enough to let it calculate its movement quite easily. Or at least, they would be if there was always something in view[1].

You may think that it''s very hard to make a system like that, but it really isn''t. I''ve already got a bot that can tell whether it''s actually moving, based on visible objects, and it works very well, and was easy to implement.

Other than that, the arena is pretty small at the moment, and there aren''t that many options for what you can do in any one update, so giving the bot positional information on a plate would just take away an interesting challenge (even if it isn''t an extremely challenging challenge)

John B

[1] The problem of not always having static objects in your field of view, that you can use for reference is something that should be addressed in my opinion.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
you don''t need a map to navigate and you don''t need a map to keep the bot from getting stuck and you don''t need a map to do good.

That''s true - you can get a long way without a map. But I think having a map does allow some slightly more intelligent decisions to be made. For example, if you''re backing away from the enemy, and you want to strafe, a map can be used to decide whether to strafe to the left, or to the right. If there''s a tree on the left that you don''t want to get stuck on, and there''s a tree futher forward on the right that you can try and hide behind, it''s obvious you should strafe to the right - but without a map, it would be impossible to tell which way would be better, and you could easily get stuck on an object that isn''t in your field of view, giving the enemy bot a target that isn''t moving.

John B

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!