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]

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.

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]

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.

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.

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