(sailor, i stole your font/formatting...hope you don't mind!
)
1. Do you feel that GameDev: Arena is ready for a beta contest? If no, what do you feel needs to be done to make it ready?
Yes, it seems to be ready.
2. If you could modify the GameDev: Arena interface, what would you change (without adding new or removing functionality)?
No changes needed for the *existing* interface
3. If you could modify the gameplay of GameDev: Arena, what would you change (without adding new or removing functionality)?
grendades don't seem to go as far as they did pre 0.035...i haven't experimented much with them since then, but i'd like them to go back to their previous range.
4. How long do you feel is sufficient time for developing a contest-worthy bot?
4-6 weeks.
5. Rate the GDArena interface ease of use. (1 = bad/difficult, 10 = good/easy)
9.345212345639 (heh)
6. Rate the GDArena "technical" support that you have received. (1 = bad/difficult, 10 = good/easy)
8
7. Rate the GDArena documentation. (1 = bad/difficult, 10 = good/easy)
3
8. Rate the current GDArena functionality (is it sufficient?). (1 = bad/difficult, 10 = good/easy)
6
9. Rate the difficulty of implementing a "good" bot. (1 = bad/difficult, 10 = good/easy)
happydude basically said it: reactive bots are fairly easy-- gonna go with an 8. taking it to the next level requires quite a bit more thinking/work. gonna go with 4.
10. Do you plan to enter the beta GDArena contest? Your answer is not a commitment.
Yes
11. If you have any other comments about GameDev: Arena, please put them as well (anything you want).
Previously, I said that i was fine with the proximity LOS not giving a definite direction, however, after playing with it a bit, I believe that it would be much better (both in terms of someone learning how to use the interface, and in terms of improving bot functionality) to stick with a perceptual scheme that is fully consistent (i.e. the proximity LOS and regular LOS should return the same types of information...should detect the same types of objects and give accurate direction/distance information). The key word here, i think, is consistancy. Either this, or if the LOS zones are going to be treated separately (in terms of the type of info returned) there should be two separate queries (GetObjectsInSight() and GetObjectsInProximity()). This would help alert people to the fact that these two queries do, in fact, return different types of info.
Although i think the current wall detection scheme is definitely "workable", i can see that it will probably be a major sticking point in the actual competition. The process of wall detection may be confusing to someone just trying to get into the competition. Plus, this might make people who are obsessed with "realism" in computer simulation/modeling (i confess, i get a little carried away sometimes...i can definitely understand the sentiment) a little bit ornery -- which would lead to whining -- which is unpleasant (especially, i'm sure, to khawk).
I think the ideal wall detection situation would be one in which visible wall segments are returned (i know, i know, the current query isn't set up to return this type of data...i'm just throwing out ideas). So, for example, if you were looking towards a corner and saw two walls, you would have returned to you two different wall segments. each segment would have the distance and angle to the first visible point of the wall to the last visible point. As i said, this is the ideal...i have no idea how practical it is. However, as far as implementation is concerned, this could be done with a simple frustum/segment intersection test between a trapezoidal approximation of the bot's FOV and the walls.
EDIT: Oh yeah, also, for everyone interested in machine learning techniques (neural nets, genetic algs, reinforcement learning, etc.) it is ESSENTIAL for there to be another mode for running the arena. Currently there is a release and debug mode. I'm gonna call this hypothetical mode learn mode. In learn mode, the arena could be run in a "fast forward" mode, and you would have access (only in learn mode!!) to information that you would not have otherwise, stuff such as (but not limited to): the enemy's health, your bot's accuracy, if your bot has collided with something, etc.
This depends on Khawks standpoint on the "fairness" of machine learning techniques in a competition like this. However, I'd like to point out that although many people tend to view these techniques as somehow magical, able to produce "ultimate" AI agents, machine learning techniques are simply that...alternate techniques. It can be just as difficult to create and tune a machine learning structure that successfully performs a task as it might be to "hard-code" a successful agent. I believe it takes just as much hard work and creativity as traditional AI techniques, so it shouldn't be disqualified on the basis that it is somehow taking the easy way out.
-------------------------------------------------------
A headache, ancillary; an hourglass auxiliary.
"something witty, blah, blah, blah"
--That One Witty Guy (remember? that one dude?)
(author of DustBot)
[edited by - drreagan on August 21, 2003 11:56:41 AM] [edited by - drreagan on August 21, 2003 12:51:25 PM]
------------------------------------------------------- A headache, ancillary; an hourglass auxiliary."something witty, blah, blah, blah" --That One Witty Guy (remember? that one dude?)(author of DustBot)
. 
