🎉 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!

Deeper Issues

Started by
15 comments, last by zealouselixir 20 years, 10 months ago
This topic serves as a channel for you to wax philosophical about the finer points of GDArena strategy, balancing, morality, and what have you. I will start off with a concern that has been brewing at the back of my mind ever since I first saw the arena in action. It can''t really be described briefly, so I''ll express it as succinctly and completely as I can in the following paragraphs. What potential is there for genuine strategy and complex AI techniques in the arena? It seems that there are two primary goals in any battle: finding the enemy, and killing the enemy. Other things, such as replentishing ammo, avoiding obstacles, finding absolute orientations, etc. either subcede or compose these two goals. All the bots I''ve seen so far seem to be based on an FSM with two or so states: one to run and spin randomly (some more effectively than others) until the enemy is encountered, and another to determine the best way to attack (most often simply rotating the opposite way the enemy is facing and blasting away with the default weapon). The issue here is not over the approximate simplicity of the bots. But, this is a major concern: it is extremely difficult to construct a bot that can consistently beat the best of the bots that use the above strategy (see Leftie). What we have effectively done is narrowed the contest down to who can build the bot that can most quickly figure out how to line up with the enemy and fire (prediction and other such pseudocomplex methods included). So, the question is this: is there any strategem or body of strategies that can be applied to create a bot that can outperform the simple tactic of "aim, hold, and shoot"? Later, ZE. //email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

[twitter]warrenm[/twitter]

Advertisement
To answer your question ZE, yes. i think that most people are holding out there advanced strategies until tournament time. i have a good bot but i cant release him because it would show the way to a couple of higher order tactics.

Your point is good and i still kind of feel the same way, but what we are basically arguing is that its not complex enough to be absorbing, right?
"Let Us Now Try Liberty"-- Frederick Bastiat
i think that you have a point ZE, and in part that is why this is just a beta test...so we can pinpoint possible "problems" with this contest (not just bugs, but "gameplay" type issues as well).

i think one thing that is currently holding people back from using more complex behaviours is the fact that right now you can''t even see the walls! this makes it hard to implement any type of internal spatial map, as you don''t know for sure if you are bumping up against the wall and moving in the internal map, but not moving in the actual arena.

this, i''d classify as just a plain bug though...

other things we should give kevin feedback on though are:

for instance, although i''m working on implementing a strategy utilizing moving to obstacles as cover, i don''t know if it''s worth it. it seems to me that rocks offer almost zero protection from fire (kevin says that they should block gun shots, but not ''nades) and trees provide a very very narrow field of protection (sometimes my bot will try and use a tree for cover, and shoot out from the tree. my bots shots are blocked by the tree, but the incoming shots arent!?).

another obvious thing holding people back from using adaptive, learning methods is the fact that we can''t batch run matches at high speeds (can only run at default speed). plus, we can''t log any *reliable* info about each match (yes, you can implement a logging system internally in your bot, but it can''t be 100% reliable...only what you deduce from your bot''s perceptual inputs).

if issues such as these are addressed and changes made, i think more complex strategies will be viable.



A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)


------------------------------------------------------- A headache, ancillary; an hourglass auxiliary."something witty, blah, blah, blah" --That One Witty Guy (remember? that one dude?)(author of DustBot)
another thing that i meant to address is:

grenades! although i fully support random-noise in their velocity, i think currently it is MUCH too much.

so, either i think the firing rate and damage done by nades should be upped, or the randomicity of the nades lowered!

A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)


------------------------------------------------------- A headache, ancillary; an hourglass auxiliary."something witty, blah, blah, blah" --That One Witty Guy (remember? that one dude?)(author of DustBot)
Well, the first thing I''m going to do is calibrate the frame rate and then hard code it into my bot. Then I''ll be able to determine the exact speeds of fast/slow rotation and movement. It''s a trivial thing to do so why doesn''t KHawk release the info?
i second the tree issue as cover, it only works occasionally, maybe if you made the coverage larger it would work properly, as far as rocks go the only thing they stop are the bots, bullets pass right thru them.
"Let Us Now Try Liberty"-- Frederick Bastiat
quote: Original post by Sailorstick
Well, the first thing I''m going to do is calibrate the frame rate and then hard code it into my bot. Then I''ll be able to determine the exact speeds of fast/slow rotation and movement. It''s a trivial thing to do so why doesn''t KHawk release the info?


he has released it. look through the "Bot speeds" thread.

A headache, ancillary; an hourglass auxiliary.

"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)


------------------------------------------------------- A headache, ancillary; an hourglass auxiliary."something witty, blah, blah, blah" --That One Witty Guy (remember? that one dude?)(author of DustBot)
Thanks mate
One issue that I have with play balance is with the Molotov Cocktails. If my understanding of them in the real world is correct then they are glass bottles filled with a flammable substance that breaks upon impact and spreads burning almost anything it comes in contact with. In the Arena we could just have it break upon impact and create a small patch of ground that burns for a short time, causing damage to bots on the burning ground. I could see how if this effect was implemented with the Arenas Molotov Cocktails then it could make them useful and create ways for new strategy. I feel that with the way they are now they are not useful as they take too long to explode and can be easily avoided, hence making them practically useless and no threat to more advanced bots.

One other thing that could balance the play a bit is when the ammo box is created and made available; also make two health packs available to the bots that will restore partial (not full) life. This would give an advantage to try and run, hide and try and seek out your health box when your health gets low. Another way to implement this is to allow the bot to regenerate life (by calling a function) slowly while it is not moving.

These are just pointless ramblings that I wanted to get out into the wild before I forgot, and may be better suited for the suggestions / idea thread.
I think that at the moment, there are several problems with the arena that make complex AI techniques difficult (although some interesting things are still possible).
A few things I can think of (some have been mentioned before):

  1. The obstacles do not provide effective cover, all they do is prevent movement, which means that at the moment, it's probably more effective to just try and avoid obstacles than it is to try and use them to hide.

  2. The arena is too small, which means you will find the enemy bot quite quickly, at which point the match quickly degenerates into the two bots predicting each other's movement, aiming based on their prediction, and strafing to try and avoid the enemy fire.

  3. The grenades/molotov cocktails are too uncontrollable, and slow to explode, so they're pretty much pointless. If they were more controllable, it might be possible to use them in a situation where the enemy has just gone behind a tree. You could then throw a grenade to get it to go just to the side of the tree, and hopefully either flush the enemy out, or even better, hurt them.

  4. There isn't enough choice of weapons (with the current limitations on the grenades, there isn't a choice at all). Basically, when the enemy is visible, you use the main gun, and when the enemy is not visible, you either don't use anything because you don't know where he is, or you use the grenades. Imho there should be at least 3 weapons - short range (quite powerful, aimed, but loses power at greater ranges - ie, a shotgun), long range (lower power, but aimable at long range - like a UT shock rifle or something), and explosive/throwable (gives splash damage, or very high damage on a direct hit, slow to refire, ie, hand thrown grenades, grenade launcher, or possibly rocket launcher). If the arena was more complex in other respects (different shaped obstacles or internal walls, and item spawn points instead of a single ammo crate in the middle of the match) then an even larger selection of weapons may be appropriate (for example, a sniper rifle - extremely slow to reload, but very powerful and aimable, probably have a sniper mode too - you can only fire it when you're in sniper mode, your field of view is very limited, and you can't move)


On the other hand, with the arena in its current state, some things that might be possible if you can get the implementation right are:

  1. Good mapping system, using a combination of dead reckoning, and a more realistic sight based movement tracking system. What I'm thinking of here is: when you move, you know how far and in what direction you've moved. But you don't know that stuff by thinking (subconsciously) I walked at speed x for t seconds, so I must have moved n metres. You do it by visual references. I think the same thing is possible here. Each frame, make a temporary map of the objects you can see (simple trigonometry will suffice for this) then, using your internal, persistant map, plus information about how far and in what direction you think you *should* have moved, you should then be able to work out exactly how far and in what direction you actually did move. With this information, you can track your movement pretty exactly, and you'll know if you've backed up against something (for example) because your actual movement, as measured by object position inputs, will be zero. When no objects are visible, you can probably rely on dead reckoning until you see something again. Of course, you don't get anything as easy as a unique object ID for each tree, so you've got to work out which objects you can see in the current frame correspond to which objects you've seen before, and then add any new objects to the internal map, so you can use them for further tracking.

  2. Inference of object positions. If you back into something (an you know you've backed into something because you tried to move backwards, and your visual positioning system tells you that you didn't actually move) then you can infer that there's an object (a wall, a tree or a rock) behind you, and you can add it to your map for confirmation later (since you don't know what it actually is unless you've seen it before, you can't add it as a definite object of a definite type).

  3. Using your internal map to help govern your movement. As you're moving, your high level AI routines (selection of search/mapping mode, or tracking mode, etc etc) can produce the movement in terms of something like a target position and angle, plus movement specifiers (for things like whether speed is very important in which case you should make sure you travel forwards, as that gives you the highest possible speed). This target movement information can then be passed into a set of routines that check the map and what you can see, and will automatically avoid getting stuck behind something on the way to your target position.

  4. Trying to keep where the enemy can't see you. This is in too parts really, one is hiding, which should be done based both on what you can see, and what you've got stored in your map, so that you can hide without needing to see the object you're about to hide behind - useful so that you can move to a hiding position by strafing and moving backwards and forwards, while continuing to face the enemy to shoot. The other part is trying to keep behind the enemy. You know what direction the enemy is facing, so if he hasn't seen you yet, it may be possible to stay behind him, while moving closer to a) making staying behind him easier, and b) mean you're more likely to hit him when you do start firing.


Anyway, this has turned into a much longer post than I intended, so I'll stop here (also, I'm tired and I can't think of much else to write )

John B

Edit: formatting, Edit 2: wording, Edit 3: hmm... I hope I haven't just ruined my chances of having a unique bot...

[edited by - JohnBSmall on August 7, 2003 12:21:18 PM]
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.

This topic is closed to new replies.

Advertisement