AutoDoom monthly releases

I've decided to upload weekly monthly releases of AutoDoom, as long as I make progress on it. The releases are posted on Github. You can download them from there for Windows and Mac.

(EDIT: I changed it to monthly because doing releases weekly is too time consuming to set everything up properly)

For those wondering what I'm talking about, it's a vanilla-demo compatible (but based on Eternity) single-player and cooperative bot for DOOM. Here's an example video (recorded from coop bot's point of view; the green guy was me):

Very interesting! I will try this in no time.

That's impressive!

Official feature request for a hotkey to allow you to interrupt a bot and take control to get the bot past an obstacle it can't figure out on its own without having to fight the bot continuing to try and move.

This is pretty cool. Tried it out on one of my maps, and sooner or later it'll just stop and wiggle in place. Is that to be expected?

1 hour ago, boris said:

This is pretty cool. Tried it out on one of my maps, and sooner or later it'll just stop and wiggle in place. Is that to be expected?

Yeah, currently BOOM specials aren't fully supported (I'm working on it now) and I don't know what I'll do about voodoo Turing complete maps. Also the bot currently doesn't find jump areas. 

If you opt to play coop this experience may be better, because when the bot gets stuck, you can free it later as you reveal new objectives for it to find. Same if I go ahead and implement @Linguica 's suggested override. 

As promised, here's this week's release, r5349. Link on Github: https://github.com/ioan-chera/AutoDoom/releases/tag/r5349

I've answered @Linguica's request. You can also use a console command to see bot's current path in the automap.

The changes are:

1. Completed support for BOOM generalized and Eternity parameterized specials lookup. More complicated setups (voodoo doll constructs and scripts) are unsupported yet.
2. Improved the pathfinding behaviour when rushing to reach a timed lift or door.
3. Smoothed the non-combat movement. Bot no longer tries to recover the path — it was more harmful than good.
4. Improved the map effect analysis for more complex maps: now the bot tries its best to reach the benefits behind timed lifts or doors.
5. Made the shootable linedefs actively sought after by the bot. It may fail sometimes though.
6. User input now pauses the bot temporarily for one second. Useful to take over control when the main bot fails to advance.
7. The "am_drawnodelines 1" console command now shows in the automap, besides the bot map, also the bot's current path and any remote promised subsectors.

In the video it seems very jittery and continually turns from side to side - any idea why? From a purely aesthetic point of view it would be nice to dampen this perhaps just to make the videos more pleasant to watch.

7 minutes ago, fraggle said:

In the video it seems very jittery and continually turns from side to side - any idea why? From a purely aesthetic point of view it would be nice to dampen this perhaps just to make the videos more pleasant to watch.

Actually I've addressed some of that problem in the latest release but didn't get to upload a video yet! The bot should be smoother now. 

Why it was happening:

• It tried to go back on the path if overstepping out of it -- this was usually not the right direction. 
• Any little seam in the path may cause it, because its trajectory is heavily influenced by the node builder, which is needed for quick position lookup (thanks to @andrewj for GLBSP, I should really remember to put him in About next time). Maybe I should actually divide the sectors into more regular shapes for pathfinding, and accept the costlier lookup; maybe it doesn't matter for performance. 

Nice progress, it can now actually complete my fbase6.wad without intervention. At least with -nomonsters, otherwise it seems to be a bit overwhelmed with having monsters all around it. Especially in the beginning, with only the pistol, the decision to shoot at everything (including a Hell Knight and Arachnotron), but not killing anything, seem rather subpar. Running out of ammo pretty much stops it in its tracks, just wiggles around, "shooting" the fist.

It also seems pretty clairvoyant, like finding a supidly well hidden secret (but not another, I assume that's caused by the linedef actions I used), or going straight for the yellow door after getting the key, without having seen the door first. It's quite funny actually, seeing how unfazed the bot is by my bad map design decisions :)

Movement is indeed much smoother and way less nausea-inducing than last version.

6 hours ago, printz said:

Maybe I should actually divide the sectors into more regular shapes for pathfinding, and accept the costlier lookup; maybe it doesn't matter for performance.

Perhaps what you need is a "navigation mesh", and instead of following a narrow line, the bot would exist in a polygon and be trying to reach the next polygon, giving it more freedoom how to travel.

There's quite a lot of literature about navigation meshes on the 'net, worth the time to read about them.

3 hours ago, andrewj said:

Perhaps what you need is a "navigation mesh", and instead of following a narrow line, the bot would exist in a polygon and be trying to reach the next polygon, giving it more freedoom how to travel.

I already make it navigate polygons, not lines, except that those polygons are BSP generated, which makes it easy to find out on which one you are at any time, while becoming terribly dense in high detail maps (usually modern PWADs). 

Outstanding work, printz! Haha, I always wanted to play with bots like these way back, they are really cool and fun to play with. Sure beats the DECORATE bots I made way back. I gave it a quick test and noticed some things with it where the bots would get stuck on certain areas. Here are the issues I noticed so far:

* In AV MAP02, bots get confused when trying to grab the red key. Bots need to learn to "jump up" to a higher floor. Soon after this, it crashed.
* In Doom E1M9, in the secret area at the exit with many platforms with items on them, it would be nice if bots could pick them up. Maybe the bots need to become aware of player physics in terms of movement momentum and "jump" distance between differing heights. This would understandably probably be very difficult to get to work though.

I had made example wads of the above issues, but then I looked around and found this https://autodoom.net/2017/03/21/teaching-the-bot-to-jump/ , so I assume the bots still simply haven't been programmed to jump at all yet.

* If another player or bot is in the way, the bot will not try to move around it and thus effectively get stuck, especially if 2 bots bump into one another.
* In Doom E1M8, the bot acted weird when attacking the barons, it would not try to move around walls to find the barons if they were out of sight. It seemed to hump a wall behind the stairs trying to reach the baron, though I didn't seem to reproduce it again.
* In AV MAP03, the bots tended to get confused at switches that lowered unimportant unreachable floors, sometimes going back to activate them over and over again. They would also rapidly press the switches very fast. Eventually the bots moved on.
* It can sometimes get very laggy at times. Presumably the AI is working hard? AV MAP04 at yellow key area. The bots seem to jump down to a pit and use a lift there repeatedly for no reason. It then crashed after a while of doing this. I made an example wad (autod_av04.7z MAP01 in example) of the area where the bots glitched to reproduce it. Sometimes the bots manage to move successfully in the example.
* In Doom E3M4 (House of Pain), at the end before exiting it repeatedly returns to an area near map start to walk over linedefs to trigger crushers, that in turn stop when moving over another another linedef. And whenever it triggers the linedef to lower the crushers, it lags.
* The bots might need to be a bit more careful with the rocket launcher, they don't seem to be aware of splash damage. Maybe they could switch to other weapons if too close to enemies or walls.
* It seemed to repeatedly use a lift inside a pit in E4M1. Thankfully it moved on after a while.

And here are some minor suggestions and ideas for the future if possible:

* It would be nice if friendly fire could be turned off.
* It would be cool if you could take over a bot's movement when coop spying it to help it.
* Maybe when bots get stuck and they see a player nearby, they could try to follow it. If the player is out of sight again and a few seconds pass, they could maybe start to roam around looking for new paths/items/enemies/secrets or something.
* A command to tell individual or all bots to find you from afar, follow you and stay close to you.
* A command to tell individual or all bots to camp at a sector.

Anyway, best of luck to you. This is very impressive, looking forward to seeing new developments in the future.

Here's a new release after a long hiatus on doing releases: https://github.com/ioan-chera/AutoDoom/releases/tag/autodoom-r5712

I changed the plan to make monthly uploads, not weekly, due to the time needed to clean up each release. Even so, this one comes after two months of no uploads. Anyway, all updates are from the Eternity base. The most important one is that I rose the SDL version from 2.0.9 to 2.0.12 so expect system bugs to be fixed.