Visual Doom AI Competition
vizdoom.cs.put.edu.pl
vizdoom.cs.put.edu.pl
Baby steps. Beating other bots in deathmatch is a good start. I love that they only use the rocket launcher, giving the careless bot an equal chance of blowing itself up.
Parsing what's on the screen in Doom is potentially a lot easier than in modern games: since there is no texture filtering or anti-aliasing, and due to the 2.5D perspective, most vertical runs of pixels on the screen map exactly to (linearly?) scaled columns in wall textures or sprites. I would not be surprised if you could come up with a fairly simple algorithm to determine the exact position and orientation of the player and the objects on screen within the map, without any real AI/learning involved.
I will fight you ;-)
But seriously: The project uses a source port of Doom[1] based on ZDoom[2] which supports high screen and texture resolutions, mouse look, colored lights etc.
Although I think that since Doom has less visual clutter (bloom, shadows, ambient occlusion, screen distortion) than a modern AAA game its display should be easier to read.
[1] https://github.com/Marqt/ViZDoom [2] http://zdoom.org/About
Google DeepMind AI navigates a Doom-like 3D maze just by looking
To the point on visual processing a stealth A.I. (not for long) working in this space is Magic Pony Technology (http://www.magicpony.technology/) operating from London and guys I spotted at London A.I. who have previously hosted Prediction IO and Swiftkey at their last events.
Another caveat for this test is sound, human players will have audio but the A.I. will be purely visual so a slight disadvantage.
We are working on speech-to-text and text-to-speech technology for our A.I. voice enabled finance assistant which is in beta at WealRo (http://www.wealro.com) with a view to enabling a visual face recognition at some point in order for the A.I. to gather information from facial expressions. Always happy to get any thoughts on the potential usefulness of such an integration?
This project says it only uses the screen buffer, but perhaps (and this is beyond my low level knowledge) there is also an equivalent "sound buffer" where it could tap into left and right channels?
Clearly this competition is an attempt to build off successes in reinforcement learning with agents that play games using only images and scores.
"this contest is like making Google make Alphago have to also include a robot and image recognition and making the robot have to place the stones." obviously that has "nothing to do with" the game and is "how Alphago gets the information."
But Go (and tetris etc) are games of perfect information where perception of the game state is not a challenge. If you have access to the internal data structure representing the Go or tetris board that's the same as having to scrape it off of a screen and recognize it or do real world image recognition.
If your parent comment is wrong it's because that's not the kind of game Doom is.
So what you consider "intertwined" really isn't, unless Google has not even built a go engine, since a human was doing the perception.
(again, I am just saying your parent's argument is easy to follow, not that they're correct in this case.)
>But Go (and tetris etc) are games of perfect information where perception of the game state is not a challenge.
In general, "perception of the game state" is not a challenge, at least according to good game design principles (e.g. in danmaku shmups, perception can be a challenge because of visual effects that are not really part of the game, but this is seen as poor game design, similarly to how being unable to differentiate backgrounds from platforms in a run&jump is bad design). Although there are games where the perception of the game state is a game mechanic, but Doom isn't really one.
But even in Doom, you can separate quite neatly the two tasks. The vision task essentially aims to reconstruct a model of the world. But in a video-game, this model comes for free. You can trivially limit the information an agent get to what he would get as a player (in games like MGS it's already the case, albeit in a very simplistic way). It's fairly easy to make a function that computes what is visible, what sounds a player would hear, etc. You can then rephrase the problem as make an AI that can only access this function, and this wouldn't change anything.
So for the AI community, I think a more interesting question would have been to design an AI over such a function.
The only reason people have historically (and many currently) separate the two is because it's been too hard! But that's the point of research: solving hard problems.
Of course it does not make sense to use in a real game implementation. The idea is that such technology could (with further development) be used in real world scenarios/applications. The problem is simply posed in a game environment to make it interesting and easier to approach.
Motivation
Doom has been considered one of the most influential titles in the game industry since it popularized the first-person shooter (FPS) genre and pioneered immersive 3D graphics. Even though more than 20 years have passed since Doom’s release, the methods for developing AI bots have not improved significantly in newer FPS productions. In particular, bots have still to “cheat” by accessing game’s internal data such as maps, locations of objects and positions of (player or non-player) characters. In contrast, a human can play FPS games using a computer screen as the only source of information. Can AI effectively play Doom using only raw visual input? Goal
The participants of the Visual Doom AI competition are supposed to submit a controller (C++, Python, or Java) that plays Doom. The provided software gives a real-time access to the screen buffer as the only information the agent can base its decision on. The winner of the competition will be chosen in a deathmatch tournament. Machine Learning
Although the participants are allowed to use any technique to develop a controller, the design and efficiency of the Visual Doom AI environment allows and encourages participants to use machine learning methods such as reinforcement deep learning. Competition Tracks 1. Limited deathmatch on a known map.
The only available weapon is the Rocket Launcher, with which the agents start. The agents can also gather Medikits and ammo. 2. Full deathmatch on an unknown map.
Different weapons and items are available. Two maps are provided for training. The final evaluation will take place on three maps unknown to the participants beforehand. Important Dates
31.05.2016: Warm-up deathmatch submission deadline
15.08.2016: Final deathmatch submission deadline
20-23.09.2016: Results announcement (CIG)
Contact For announcements and questions subscribe to vizdoom@googlegroups.com
Bugs: Open a new GitHub ticket
Getting started Download (or compile) the ViZDoom environment.
Follow the instructions.
What will the Deathmatch Look Like?Your controller will fight against all other controllers for 10 minutes on a single map. Each game will be repeated 12 times for track 1 and 4 times for track 2, which involves three maps. The controllers will be ranked by the number of frags.
In the case of lots of submissions, we will introduce some eliminations.
Technical Information Each controller will be executed on a separate machine having a single CPU and GPU at its only disposal.
The machine specification: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz + GTX 960 4GB
Operating system: Windows or Ubuntu Linux 15.04
How to Submit my Entry?To accept your submission we will need the following data:
name of the team
team members and their affiliations
max. 2 pages description of the method used to create the controller (pdf)
a list of (sensible) software requirements for the agent to run (ask beforehand)
a link to the source code of your controller and additional files (max 1GB in total)
an instruction how to build and execute the controller
The form to submit the above data will be provided later. In the spirit of open science, all submissions will be published on this website after the competition is finished.
OrganizersWojciech Jaśkowski, Michał Kempka, Marek Wydmuch, Jakub Toczek
Doom is similar to the Lenna picture in image processing: Somewhat prurient, but well-known. See for example psDooM, where you kill Linux processes: http://psdoom.sourceforge.net/
P.S: Who will teach the AI cheat codes such as idchoppers?