Visual Doom Bot Competition

Yipe. This looks cool as hell. All this is happening while I'm sitting here contemplating life and wasting time on the internet.

Wow. Hard to believe that the bots will be any good at all, but sure sounds intriguing.

visual doom page linking to wikia smh

cool though

AD_79 said:

visual doom page linking to wikia smh

cool though

I noticed that. One of us should probably correct them :)

I don't know how plugged-in to the community the people behind this are, but since they based their custom port on ZDoom and linked to a wiki (even if it's the wrong one) they seem like they know a little bit about the game.

david_a said:

Participants will create a Doom bot (hooking into a custom version of ZDoom) that works purely off the same input that human players have.

Has anyone managed to run ViZDoom on their computer (I haven't), so that they would confirm if the automap is available or not, respectively if IDDT cheat works? I bet the bots would use it pretty much solely instead of normal 3D vision.

david_a said:

I noticed that. One of us should probably correct them :)

I've left a note on their github.

I wish this was for vanilla Doom or PrBoom+, or maybe even Zandronum, but not ZDoom.

scifista42 said:

Has anyone managed to run ViZDoom on their computer (I haven't), so that they would confirm if the automap is available or not, respectively if IDDT cheat works? I bet the bots would use it pretty much solely instead of normal 3D vision.

Well apparently the competition involves deathmatch, so cheats like IDDT will presumably be disabled.

OK, but what about just the automap, for navigation around the map's layout?

This is cool.

scifista42 said:

Has anyone managed to run ViZDoom on their computer (I haven't), so that they would confirm if the automap is available or not, respectively if IDDT cheat works? I bet the bots would use it pretty much solely instead of normal 3D vision.

That'd defeat the purpose of the exercise, plus it'd mean not being able to tell anything about where height changes are. Relying on the automap view might possibly make basic navigation easier in the short term, but it'd limit the bot's ability to improve.

esselfortium said:

That'd defeat the purpose of the exercise,

And that's exactly why I'm asking whether the engine makes it possible or not, because if yes, the participants will surely exploit it. If not entirely, at least to some extent.

I don't see what is cheating here. If you can parse the automap easier than the player view, just do it. You'll still lose some information, but you cam tell the bot to press tab periodically and record the player view.

Can you also rely on sounds with this? Or is ViZDoom totally silent?

Uhh, if they are going to use the automap then it's not interesting at all... I want to see them analyze a mess of pixels in a 320x200 resolution and try to get some useful info from it. I hope they will clarify on this.

This reminds me of that Starcraft 2 bot that someone created. It actually analysed the screen for information and nothing else, if I understood it correctly.

Anyway, I want to see more info as this progresses. It seems so hard to me to just rely on the player's viewport. Using the automap too would help with navigating. It should be allowed IMO.

Apparently they are allowed to use a depth buffer as well, which seems to defeat the purpose?

Linguica said:

Apparently they are allowed to use a depth buffer as well, which seems to defeat the purpose?

Yeah a big part of the challenge would be to figure out how close a nearby wall or object is. Using the depth buffer from the rendered scene is a massive cop-out. Makes it much easier to figure out what is a wall (same depth going down), what is floor or ceiling (same depth going across) and what is an object (same depth going down and across).

depth buffer = ?

kuchitsu said:

depth buffer = ?

http://vizdoom.cs.put.edu.pl/user/pages/01.home/depthbuffer.png

I guess that implies GL-only too.

Jon said:

I guess that implies GL-only too.

I guess so, though Quake's software renderer uses a depth buffer.

I was able to approximate a depth buffer in Wolf4SDL by calculating the pixel color change density per area. I took advantage of the pixellated graphics. However, this is not effective at low resolutions, and can be fooled by textureless areas.

Does prize money constitute commercial usage?

This would probably have been more interesting if it were for example Chocolate Doom playing with just the screen buffer and sound channels compared to say an OpenGL port with a depth buffer.

Why the hate for the depth buffer? Isn't that basically what other real-world systems use? Like autonomous cars using Lidar.

boris said:

Why the hate for the depth buffer?

Participants will create a Doom bot that works purely off the same input that human players have.

Can AI effectively play Doom using only raw visual input?

But the human brain has an built-in depth buffer, too, so to speak. Giving this information to the program is a more realistic scenario IMO.

boris said:

But the human brain has an built-in depth buffer, too, so to speak. Giving this information to the program is a more realistic scenario IMO.

Oh come on, monitors display a 2D image. If the point is to research a computer program that can reconstruct a 3D understanding from a 2D image, then giving access to a depth buffer is totally missing the point. If the point is to navigate an environment using a depth buffer as pseudo-lidar, then why put any emphasis on a comparison to human play?

Linguica said:

If the point is to navigate an environment using a depth buffer as pseudo-lidar, then why put any emphasis on a comparison to human play?

To be fair, the bots are going to suck even with access to the depth buffer, so that comparison to human play would be interesting and worth researching/showcasing even then. But it's still contradicting the point that they are proposing the challenge with - "only raw visual input".

Yes, when put like that, the bots should have access only to the displayed frame and the sounds being played. And they should use the player available controls in any way they seem fit. Like opening the automap every few milliseconds for example.

But it's still very interesting. I want to see what progress will be made in these short few months. Maybe printz can get some ideas or code for his AutoDoom project. (although it is different)

kuchitsu said:

Wow. Hard to believe that the bots will be any good at all, but sure sounds intriguing.

You extremely underestimate the power of these systems.

I suppose the depth buffer access is intended to shift the focus on the competition to reacting to the situation a lot more than trying to just read it. It does foil the description a bit, but it's still a valid challenge, I think. Probably without this access most of the time developing a bot would be spent just on figuring out a reliable method of figuring out how far something is, rather than the actual gamey parts. Doom on its own is a lot more complex than what most visual learning game bots have been made for (2D platformers like Mario with simple graphics and few colors, no varying lighting conditions, etc.) Doom's lighting is made even more complex to read thanks to its fake contrast. So the depth buffer access just helps to bridge that gap.

My question is exactly what access the bot has - can it access the console? Can it change its player color to try to blend into the map? If other bots are programmed to look for a green marine that sure could throw them off. Can the bot read data from the WAD itself to know best what to look for? I guess not, because that's also more than visual input.

EDIT: In fact, I don't see anything about depth buffer access on the competition page, just "access to the screen buffer as the only information". Only the ViZDoom page mentions the depth buffer. Possibly the competition doesn't use the depth buffer feature of ViZDoom. Though this should be clarified for sure.

Jon said:

I guess that implies GL-only too.

The lighting and color falloff looks distinctly software-rendered.