Share this post

Link to post

I used to think there was one called Henning.exe. ;)
To be honest, the gains would be extremely small over the best TAS demos.
unless you mean an interactive bot which could play any map. not impossible, but that would take quite an impressive group of AI algorithms to teach it to 'learn' the map as well as know how to approach every type of enemy and obstacle.
Sure would be darn cool to watch though.

take the approach of Chess. decades of AI programming.. and the board is static. the pieces are always the same.
Now program it that the board could be 10 times as big, with an unknown number of Queens on the other side... to develop a realtime, interactive AI strategy for such possibilities would be very difficult.
watching the best human players play is impressive enough, but your idea is neat to think about.

Share this post

Link to post

I thought about this a while ago (the task, not about actually programming it!), and feel that it would be very difficult be make even a competent speedrunner bot. Maybe a computer-aided demo-builder program would be more effective, where the human guides the whole thing, and the computer just optimizes it within very narrowly defined parameters (partly by extra precision, and partly by brute-force experimentation with slight variations {"perturbations"} to the route).

BTW, an AI-based approach to chess playing/analysis programs has never got anywhere. All the modern programs use a brute-force search together with pruning (alpha-beta and more, incl. null-move), search extensions, and highly evolved evaluation functions.

Given the far greater number of permutations in a speedrun* of a moderate length, I don't see any realistic chance of a purely AI-based speedrunning program getting too far.

* Typically 40 moves in a chess position (of which most will quickly eliminated by pruning and null-move); as a very rough rule of thumb need to search c. 14 plies ahead in the main line of search to play at a level equivalent to a human grandmaster. Compare this with the situation in Doom where in every gametic the player has hundreds of possible actions (though only a small number will be a good idea in a speedrun), but there are 35 gametics per second, and the justification for a particular decision will only become obvious many seconds or even minutes later.

Share this post

Link to post

I thought about this a very long time ago, except I was thinking a program that could do all the computing and write out an LMP.

The first problem is writing AI that could find its way through a level. I just don't think that's possible, at least without a little player input. My solution to the "route" problem would be for the player to place "nodes" that would tell the bot what to do, where to go and in what order(switches, for example). It would be easy enough to write that(no AI involved, really).

Now, the dynamic componenets(monsters). Two ways: you could tag the monsters to be killed in a particular order and write AI to decode the best route to them(same problem as the last); or program the bot to kill the monsters whenever they're in range. The latter would be fine for a speedrun, but a 100% run is another story. I think the only way a 100% run could be done is to plan the route down to each ammo box and let the computer do the killing.

It's not a bad idea, actually. The player programs the route and the order in which to kill the monsters(and refining the route to account for monster movement) and the computer chooses the weapon, timing, etc.

I think the best way to start would be to have the bot calculate the run only between each node(optimize point A to point B, then B-C and so on). That would narrow down the possibilities so one could get the algorithms worked out.

Just imagine how cool it would be to watch a player who always knows where the RNG is. He'd never get hit, never miss and always kill the monsters with the minimum number of shots. Even with TAS that can be hard to do...

Share this post

Link to post

Interesting topic! I specialize in autonomous systems and AI at KTH (http://sans.nada.kth.se/ , nada.kth.se/cas ) and I have to disagree with Grazza on the topic of AI and chess computers. Although a ridiculous amount of researchers are occupied with brute-force methods, there is interesting progress in the Reinforcement Learning, or RL, approach (i.e. giving the learning program feedback only occasionally) which is particularly useful when the problem domain is hard or impossible to model; it is even possible to combine with traditional models such as neural networks. The advantage is the mimicry of some aspects of human learning -- the program isn't told, and does not calculate at each point, what to do, but instead through trial and error learns and develops a strategy.

Human example: A human, given instructions on the legal moves of the game, at his or her first chess games might treat the queen as a lowly pawn; sack it, only to lose quickly. After doing so a couple of games one will realize that sacking your queen often might not be a wise decision, and so you try a different tactic where you hopefully last longer.

So, the idea is to let the learning program face IMs or GMs (or even play a couple of thousand games on one of the better chess servers) and it will through trial and error learn a usable strategy. There are numerous examples of chess programs using RL methods (and/or genetic algorithms) that have achieved a high level of play. One example I remember was a program that improved from a 1600ish rating to a 2100ish rating in just a few days of play on FICS chess server.

Share this post

Link to post

There are numerous examples of chess programs using RL methods (and/or genetic algorithms) that have achieved a high level of play. One example I remember was a program that improved from a 1600ish rating to a 2100ish rating in just a few days of play on FICS chess server.

2100 is not really a high level of play (esp. with chess-serving ratings typically being rather inflated) - more than three class-intervals below the best programs. What is the best SSDF rating achieved by a program of this type?

In the early days of chess-computer programming, there was a lot of interest in AI-based approaches. People gravitated towards a brute-force approach because it yielded better results. (Notably, Botvinnik devoted the latter portion of his life to developing an AI-based chess engine, and never produced anything that was made public. One tends to presume that was due to lack of success, but who knows - maybe he had his sights set unfeasibly high, and didn't want to release anything to the public until he was truly happy with it. That would have been in keeping with his character.)

Kristian Ronge said:

Human example: A human, given instructions on the legal moves of the game, at his or her first chess games might treat the queen as a lowly pawn; sack it, only to lose quickly. After doing so a couple of games one will realize that sacking your queen often might not be a wise decision, and so you try a different tactic where you hopefully last longer.

As an aside, I don't know if you're familiar with the program Zillions of Games, but that generates an engine based on just a knowledge of the rules of a game. It comes up with a table of piece values that is very similar to the standard one. It plays to about a 1900 standard (no doubt a bit higher on newer hardware - the 1900 figure was a few years ago).

Sure, it's interesting that progress is being made in this area, and the knowledge gained from it will doubtless be more transferable to other areas than that gained from brute-force programming - and I presume that is the motivation. But the fact that it is so far behind the brute-force approach in terms of results surely just demonstrates that it is not a very effective approach in this particular instance.

Coming back to the Doom question, planning a good route through a complex map involves schematic thinking and leaps of logic of the type the human mind is (relatively) very good at (example: the idea of staying pacifist during the first part of a NM run so as to lessen the chaos later). Maybe the AI route will be relatively more successful than a brute-force approach in this instance, but I suspect neither will get too far, and a method that uses the human and the silicon mind together is the best bet. (As it is for chess analysis, for that matter, albeit just by a class interval or two.)

Share this post

Link to post

Grazza said:
2100 is not really a high level of play (esp. with chess-serving ratings typically being rather inflated) - more than three class-intervals below the best programs.

That was by no means the upper bound of performance or skill of the program in question; the example was mentioned to show how quickly some programs are able to learn (in this case, I think it took 300 or so games to reach a 2100 ELO rating).

What is the best SSDF rating achieved by a program of this type?

Hm, good question. Not quite sure. I could look it up. An educated guess, though, is that it's comfortably below the latest Junior/Fritz packages. Perhaps 2400?

In the early days of chess-computer programming, there was a lot of interest in AI-based approaches.

There still is. :-)

As an aside, I don't know if you're familiar with the program Zillions of Games, but that generates an engine based on just a knowledge of the rules of a game.

Unfamiliar with it, sorry. Though it sounds interesting...

But the fact that it is so far behind the brute-force approach in terms of results surely just demonstrates that it is not a very effective approach in this particular instance.

Hardly "ineffective". No human GM evaluates chess positions by brute-force computation of hundreds of million moves per second. The only GMs that do that are chess computers á la IBMs Deep Thought/Deep Thought 2/Deep Blue projects (and beyond). That's why the brute-force approach is so fundamentally wrong.

EDIT: This is becoming *extremely* OT, so any further discussion on this topic would probably best be handled by e-mail.

Share this post

Link to post

I'm surprised no-one's mentioned it yet, but one of the DHT's that was never claimed was - IIRC - for a bot that would produce a 100/100 run of a level without human intervention.

My take on this - bot programming for dm has always shown that the 'nodes-and-human-tweaking' approach tends to be best (the best bots are given very detailed node routes and some extra level-specific hints; most of them will play on J. Random Level but noticeably worse than they play on levels for which they have been optimised), and this can only hold more true for speedrunning. It would also probably take some detailed programming for the bot to be aware of tricks like wall-running (programming a bot that could work out the MAP24 trick, for instance). I'm not sure bots are the best answer to super-optimised speedrunning; you'd have to optimise the code so much for each particular map that it would probably wind up being more efficient to build the demo. (For those not aware, built demos are made by hand-editing the demo file (or, rather, its lmpc-converted version), and are currently the best known way to make ultra-optimised demos, like E1M1x008).

Share this post

Link to post

I was talking with Ken Silverman about this since he made some automatic player AI's for Minesweeper, Solitaire, and Internet Checkers. Here's what he said:

I can give you some advice on how I would do it though.

I would let the human do all the recording, and write special tools inside the original game's source code that would assist the recording process. The main problem with human-recorded games is people make mistakes - like missing a ledge because you pressed the jump key 1 frame too soon. If you didn't have to go back to start every time, correcting things like this would be much easier. I would make a "continue recording" feature, so that you could continue recording at any point while you are watching the playback of a previously recorded demo. This shouldn't be hard to do in any game that uses a "synchronous" protocol, such as the Doom or Build engine games. The other thing I would do is hack the game so you can play it in super slow motion - I think this is rather obvious though : )

Well, that's my 2 cents. If you want to get something working, then take my advice.

Share this post

Link to post

What might be a step forward is a kind of super-TAS, or a cross between TAS and building. As it stands, building a demo is a horribly laborious task. It would make it a fair bit easier if you could immediately see the result of each gametic you type in. Thus, you have prboom (or whatever) running (action paused), and have a text-box in which you type in the next gametic ("GF50 SR40 TR20" or whatever), and you see the result of it on-screen immediately; it then waits for the next gametic to be input.

Perhaps this is the sort of thing Andrey Budko could add in to his version of prboom if he were suitably motivated. Which he may not be, since even this form of building would be tedious work.

Anyway, this would still produce demos that are wholly created by the human, so isn't really on-topic either.

Share this post

Link to post

I just googled and found http://www.planetquake.com/demospecs/lmp/lmp.html and it seems like it would be certainly possible to make a mod that advanced tic by tic and in each one you input your "movements," as well as turning the player to face whatever direction you wanted. According to the specs, there's only 4 components to a Doom demo anyway so it would be relatively simple.

Share this post

Link to post

Nice idea Fred, but I don't think it'd really work. The Doom guy isn't an entity like a mouse cursor, over which you have *entire* control. He's subject to Doom's approximation of physical laws like inertia, friction and gravity, so you can't really just 'draw' out a course and have him follow it.

ling: yeah, I agree, something like that shouldn't be too outlandishly hard to achieve.

Share this post

Link to post

Of course it'd work. You'd just have to make the editor aware of the physics so it performs accurate calculations in each step, and accordingly restricts drawing to movements that are possible. Also note that given Doom's low CPU needs it would be no problem to calculate the next 10 or so tics ahead of time to display consequent results for each move.