Slashdot Mirror
New AI Is Capable of Beating Humans At Doom (denofgeek.com)
An anonymous reader quotes a report from Den of Geek UK: Two students at Carnegie Mellon University have designed an artificial intelligence program that is capable of beating human players in a deathmatch game of 1993's Doom. Guillaume Lample and Devendra Singh Chaplot spent four months developing a program capable of playing first-person shooter games. The program made its debut at VizDoom (an AI competition that centered around the classic shooter) where it took second place despite the fact that their creation managed to beat human participants. That's not the impressive part about this program, however. No, what's really impressive is how the AI learns to play. The creator's full write-up on the program (which is available here) notes that their AI "allows developing bots that play the game using the screen buffer." What that means is that the program learns by interpreting what is happening on the screen as opposed to following a pre-set series of command instructions alone. In other words, this AI learns to play in exactly the same way a human player learns to play. This theory has been explored practically before, but Doom is arguably the most complicated game a program fueled by that concept has been able to succeed at. The AI's creators have already confirmed that they will be moving on to Quake, which will be a much more interesting test of this technologies capabilities given that Quake presents a much more complex 3D environment.
this is a video game, after all...
The point is that the AI learned to play the game from only screen data. No maps, no preset strategy, just visual data. So, it has to learn to recognize threats and obstacles, and what to do when it does.
Beating humans is a good test, because humans are good at exploiting patterns, so shortcuts like always taking a fixed route wouldn't work for long.
Socialism: a lie told by totalitarians and believed by fools.
You totally miss the point: it's trivial to write a perfect bot that hooks into the game's internals and always wins. It's difficult, and more generally applicable, to make a bot that learns to play by watching only the same info the human players get: the screen buffer.
Can I rig Call of Duty with an AI auto-pilot plug-in, and just sit back and watch it steam-roll over all the sucker humans in the game? If I play an online game like Overwatch and get smeered over and over by an opponent(s) with perfect aim and lightning-quick moves, will I just assume someone's introduced a bot into the game and I'm wasting my time with my hopelessly inferior carbon-based reflexes? Gaming may need its own version of the Butlerian Jihad.
Take it easy, Charlie, I've got an Angle...
In-game bots may be operating on a limited view, but they're operating on actual hard data in basically machine-usable form. What's impressive about this is that it learns from what's on the screen -- distances, obstacles, paths, its location are all learned from visual input.
What I'm curious about is how adaptable their visual learning system is or whether it's extremely Doom specific. I'd also be curious at how long it took to learn to play. I'd also be curious what the learning curve was -- linear, non-linear, flat, steep or what.
It will be interesting to see how future games develop to keep them fun for humans in an AI-filled world.
Imagine your AI setup gets to the point where it truly has the same input, not needing to be directly fed the screenbuffer but can use a camera pointed at your monitor. Suddenly current anti-cheating technologies mean nothing, and enough people using these would quick ruin a game.
All the way back in the original Quake there was a really nice learning AI written in quake C. One version allowed you to add practice bots to work on your deathmatch strategy.
Similar to the AI described in this article, the AI in this mod was ignorant of the map and had no preset patterns. It learned by doing. So as you began playing against them they were easy kills in the early rounds. They'd often just stand there and get shot. And they couldn't hit the broad side of a barn.
But they learned the map. And they learned your moves. And within a few rounds you'd be lucky to stay alive long. And finally they would learn enough to get you every time. They'd know which direction you were going to dodge before you did. And they kept track of every resource in the game and all of the respawn times, so they'd deny you any ammo or health by timing their movements perfectly to collect all spawns instantly.
It was very cool.
Then the guy who wrote it used his AI to replace the original game AI for all of the enemies. Wow. It made the game into an entirely different experience.
After about a half-level, the enemies would learn to avoid you, go out and recruit all the bad guys from the level and return in force. After a couple of more levels they'd learn to ambush, flank and surround you. They'd team up their fire, so you'd dodge a fireball to the left and strafe right into another fireball.
It was really interesting, but ultimately unplayable. It really gave me an appreciation of the level of "balancing" that goes into creating a proper game AI. It certainly isn't about the same thing as making a chess AI that can beat Kasparov. It requires a great deal of work to make the enemy realistic and interesting and difficult but ultimately beatable.
Yeah, but does the AI live in its parents basement and pee in empty Mountain Dew bottles ? I think not!
AI may win at DOOM, but we're superior LOSERS!
So there...
Ehh, a first-person shooter is not really all that great a test for AI. Being a videogame programmer, and one who has programmed his share of AI in commercial videogames, the trick is not to create unbeatable AI, but to create an interesting experience for the player. Granted, we use a lot of internal data structures to assist the AI (like for navigation), and we obviously approach things from a completely different angle, but we also have to drastically handicap the AI's responsiveness and aim in shooter-type games.
Remember, it's trivial for a computer to paint a bulls-eye between your eyes from 500 yards out with a sniper rifle no matter how you're moving or hiding. It's still reasonably easy even with true projectiles, as the AI can calculate perfect flight trajectories so that rocket will precisely intercept a moving target. An AI can't get disoriented, or confused, and has near-instant reflexes that no human can match.
One trick I've used for shooter bots is to incorporate virtual springs attached to the bot's targets, helping to throw off their aim according to how the target is moving. You can also dynamically adjust the target spring tension or based on other factors, like difficulty scaling, whether the AI agent is running, jumping (throwing off his own aim), etc. That sort of thing, along with adding blind spots, artificial reaction times, intentional mistakes, and so on, are the things you have to do to keep the bots from kicking the crap out of human players just because they could instantly headshot you from across the map otherwise.
Don't get me wrong... this is a neat little project. But beating humans in a shooter where fast reflexes and perfect aim dominate isn't really the end-all and be-all of AI tests, because our strengths and weakness are in different areas than for computer-based opponents.
Irony: Agile development has too much intertia to be abandoned now.
From TFP
b) Game Settings: A state was represented by the most
recent frame, which was a 60 × 45 3-channel RGB image.
The number of skipped frames is controlled by the skipcount
parameter. We experimented with skipcounts of 0-7, 10, 15,
20, 25, 30, 35 and 40. It is important to note that the agent
repeats the last decision on the skipped frames.
and
b) Game Settings: The game’s state was represented by
a 120 × 45 3-channel RGB image, health points and the
current tick number (within the episode). Additionally, a kind
of memory was implemented by making the agent use 4 last
states as the neural network’s input. The nonvisual inputs
(health, ammo) were fed directly to the first fully-connected
layer. Skipcount of 10 was used.
The only thing they gave the AI for the experiments were the screen image, the time, and in the second case, the health.
Modern re-implementations of Doom and Wolfenstein have a depth buffer. The original do not.
Doom used BSPs to sort walls from front to back and a scanline like algorithm that guaranteed no overdraw, so there is no use for a depth buffer. Sprites were sorted from back to front, and occlusion with other sprites was handled by painter's algorithm, and occlusion with walls was done by using a list of drawn walls and direct intersection testing. Again, no use for a depth buffer.
The algorithms in the original Doom wasn't perfect, and there are some severe artifacts to find if you know where to look, especially if sprites where near a step. Also, re-implementing Doom in something with a depth buffer like OpenGL either requires modification to how sprites are rendered, or you will get a visual difference from the original game. In Doom, the lack of clipping of sprites against the floor and ceiling is usually easy to handle by just shifting of sprites vertically, for example. But some other games made with the Doom engine depended more heavily on the lack of such clipping in the perspective used by the artists creating the sprites, and it can take some effort to get OpenGL to not clip things clip when that weren't clipped in the original game.
I will break with my urine. Bzzzt!!!
If that's the sound you make when you pee, you should see a doctor.
systemd is Roko's Basilisk.