I think it is only 1v1.

quote: Original post by Xgkkp
Uhh something which i think i have totally misinterpreted -

Is it 1v1 i.e. only ever two bots in the arena at once? I was thinking under the assumption that there would be several bots in the arena at once.

I thought this because I thought the question - Can a bot see more than one bot (or object) at once? or only the nearest.

Yes, the tournament is only ever 1 vs 1.


Jason Doucette - online resume page: www.jasondoucette.com
projects / games | real-time graphics | artificial intelligence | world records | wallpapers / desktops / backgrounds
"Great minds discuss ideas, average minds discuss events, small minds discuss people." - Anna Eleanor Roosevelt, 1884-1962

quote: Original post by Jason Doucette
After 22 pages, I have a few comments:

Khawk : "The view is about 3/4''s 3D. "

Do you mean the view for the spectators? I assume that the bots can ''see'' an environment similar to what a player can see in a game like Doom - is this true? If the bots only see a 3/4 view, then that implies a restriction on view distance (a sudden cut-off, unlike real life, even if there is fog).

That statement was in response to a question about the spectator view, just like the screenshots show. There is also a restriction on bot view distance.

quote:
Khawk : "Yes, the weapons have variance, to the point where a weapon might not always be predictable. I like the idea of kickback.. there are already time delays that will be described when the contest starts. "

I would expect the less variation, the better the contest will be. When someone wins a chess game, they can blame no one but themselves. When someone wins at poker, luck plays in every win (although, the better player will win more games in the long run). Of course, if this is put in purposely to give weaker bots a fighting chance, then this will certainly give them that chance - at the expense that the best bot may not win.

The variation isn''t as great as you''re thinking. The idea behind weapon variance is to induce more strategic thinking behind what weapon is fired and when.

quote:
Khawk : "This was one of my primary concerns, but the way it''s implemented seems to be fair. Let''s say bot A takes a ridiculous 5 seconds to process its update cycle, and bot B takes 2 seconds. Well, to start with, bot A is only hurting itself because the movement and physics are based on the real time of the system. This means that the commands sent to the arena by bot A will execute over a time period of 7 seconds (A+B). For AI, that sucks. That means they''re only getting updates on the world every 7 seconds.

For me, that would be motivation to write bot code as compact and fast as possible. Otherwise, the bot isn''t going to get updates of the world as fast as he should and will not perform at its maximum level.

And yes, it does suck that it hurts the faster bot as well. For this particular contest, it''s just part of the challenge. "

I thought it was previously said that a bot that took too long would only hurt itself. But, this hurts both bots. If you could program a bot that performs reasonably well by taking a long period of time to think, and it competes against bots that expect to react quickly - then the slow bot will win. I think this is unfair. This delayed reaction can be pushed up to some unknown limit before it is DQ''ed. I think a FAR better way to handle this is to assume real-time interaction, sort of like you are doing now, but allow the bot that takes 2 seconds to update to interact 2.5 times as often as a bot that takes 5 seconds to update. This can be accomplished as follows:

Keep a current game time, and process both bots, and record their times (hopefully, this timing will NEVER be faulty from caching disk access from other programs, etc, otherwise one bot may be doomed from this alone - in any timing method implemented). One will be faster than the other, so advance the current game time by this amount, and respond to that bot''s commands. Now, process that bot again, recording its time. You have 2 future times for when both bots will be done performing, and advance the time to the soonest time, respond to that bot''s commands, and process it again. Repeat. I can elaborate if you do not understand. The results would be:

0 sec - game starts
2 sec - bot 1 responds
4 sec - bot 1 responds
5 sec - bot 2 responds
6 sec - bot 1 responds
8 sec - bot 1 responds
10 sec - bot 1 & 2 responds
etc

Assuming no problems with timing issues, this is a great solution to allow a fast bot expecting fast reaction to not lose because of a purposely delayed reaction bot - who would die very quickly in any real-life quake / unreal contest. Any bot that takes forever to respond with my method will die quickly.

I considered that as a possible solution when I started development, but it still has its problems.. mainly in the synchronization of the bots with the game time. For one, the bots will never execute in the same amount of time each update, so you will always keep a bit of unfairness in that the bots will not have the same amount of time to execute their code. The current implementation is turn-based, which I think is fair for the first contest. Future versions may provide the capability for faster executing bots to update more frequently.

quote:
Khawk : "I thought of a better idea for the whole timing issue.. I''ll just lock the framerate. That way there''s a set amount of time for bots to finish their update cycle. I''ll figure out a reasonable number in the coming weeks. "

I just read this, and this is a reasonable solution, as well. But, I think the difference in speed for bots thinking was a neat thing for the contest to have (as long as a slow bot didn''t slow everything down, as in your prior implementation), so please consider what I said above.

Yes, it''s just a future thing.

quote:
More thoughts:

Will there be any feedback on whether or not your weapon is actually hurting the other bot? Even in the form on blood, and not something that is measurable? I believe you should be able to tell the direction the other bot is facing, if you can see him - but, I also understand that this is not a high priority visual cue for a good bot.

There isn''t a plan for this contest to introduce feedback for a bot when it damages another bot, but there will be in the future. Orientation of the enemy bot has been put in place already.

quote: Original post by BlackEye
Khawk,
This Luck v AI issue. 1 round is not to bad if the health of a bot is slow to reduce. For example is it like 2/3 shots and your dead, or more like 30+ ontarget shots to kill? As the latter would help lean towards the AI side.

thanks
pete

It takes a good number of shots to kill. I'd say at least 30 shots of the weakest weapon.

How do bots see? I hope they don''t get a screenshot from their viewpoint and have to decipher it (or else that''s my entry dumped!)

Can you give us a rough time till we start - days, weeks, months etc? Can''t remember if it''s mentioned, but how long do we get also altogether?


Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor

John 3:16

quote: Original post by d000hg
How do bots see? I hope they don't get a screenshot from their viewpoint and have to decipher it (or else that's my entry dumped!)

Can you give us a rough time till we start - days, weeks, months etc? Can't remember if it's mentioned, but how long do we get also altogether?

That's part of the interface and something you'll have to wait to find out when the contest starts.

It will start hopefully by next weekend, but because I'm making changes based on feedback here, it might not start until after the weekend (especially since I'm possibly going out of town for the weekend). How long? It's on the contest rules page.

quote: Original post by Khawk
That statement was in response to a question about the spectator view, just like the screenshots show. There is also a restriction on bot view distance.

Yes, I suspected that. I have no idea why people are worrying about what the spectators can see - that's fairly trivial, since you can make them see whatever they wish. The concern is what the bots can see... So, there's a definite cut off to view distance? I guess we will have to wait and see exactly what type of information our bots have access to. I was thinking it would be neat that they got a screen shot of what they see, sort of like what you would see in Doom, excepted minimized to a very small view screen, like 20x15. It would be the raw aliased version, so each pixel of the image is a distinct object. The low resolution accounts for inaccuracy of judging distances, and for a very inaccurate view of (or loss of sight of, when it is far away) the enemy bot. It would be very quick to calculate this screen for each bot, and each bot would be able to analyze it very quickly. Everything would need to be approximated, just like in real life - from where the enemy bot is, which direction it is moving, and even the speed and rate of fire of the enemy's projectiles (as well as your own).

quote: Original post by Khawk
I considered that as a possible solution when I started development, but it still has its problems.. mainly in the synchronization of the bots with the game time. For one, the bots will never execute in the same amount of time each update, so you will always keep a bit of unfairness in that the bots will not have the same amount of time to execute their code. The current implementation is turn-based, which I think is fair for the first contest. Future versions may provide the capability for faster executing bots to update more frequently.

Yes, I forseen that each frame will take different amounts of times for the bots to compute, as well. But this algorithm handles it, and this is how it would be in real life. If you want to compute more things about the environment for some frames, then you are allowed to - but you now react slower.

The turn-based approach is decent for version 1, though, and it does keep things simplier.

Jason Doucette - online resume page: www.jasondoucette.com
projects / games | real-time graphics | artificial intelligence | world records | wallpapers / desktops / backgrounds
"Great minds discuss ideas, average minds discuss events, small minds discuss people." - Anna Eleanor Roosevelt, 1884-1962

[edited by - Jason Doucette on July 13, 2003 4:20:52 PM]

How''s the gameplay? How long would the typical match be? You said that with the weakest weapon it would take at least 30 hits to win, which is rather much IMO. Since the bots only have to play good and not necessarily convincingly human-like, I could imagine that it could be fast-paced... is it? Long games could get boring to watch.

quote: Original post by eighty
How''s the gameplay? How long would the typical match be? You said that with the weakest weapon it would take at least 30 hits to win, which is rather much IMO. Since the bots only have to play good and not necessarily convincingly human-like, I could imagine that it could be fast-paced... is it? Long games could get boring to watch.

Depends on the AI.. some matches can go fast, some can go slow. It''s possible to kill an enemy bot within 10-15 seconds, though.

quote: Original post by Jason Doucette
I was thinking it would be neat that they got a screen shot of what they see, sort of like what you would see in Doom, excepted minimized to a very small view screen, like 20x15. It would be the raw aliased version, so each pixel of the image is a distinct object. The low resolution accounts for inaccuracy of judging distances, and for a very inaccurate view of (or loss of sight of, when it is far away) the enemy bot. It would be very quick to calculate this screen for each bot, and each bot would be able to analyze it very quickly. Everything would need to be approximated, just like in real life - from where the enemy bot is, which direction it is moving, and even the speed and rate of fire of the enemy''s projectiles (as well as your own).

*Shakes head*
Some people just like unnecessary work!

---------------------------------------------------
There are two things he who seeks wisdom must understand...
Love... and Wudan!