Smarter Monsters?

[Elaxter]

Is there a mod out there for increased AI intelligence? Like how Brutal Doom's AI changes are. Hiding monsters, better pathfinding, etc.

[scifista42]

I wonder. Knowing how the AI routines and scripting works, it's nearly impossible to do more than make the monster more aggressive or move more unpredictable. I doubt anyone ever bothered with elaborated AI changes (that aren't tied to a particular map, as a scripted event). For me, the monster's predictability is part of Doom's gameplay fun, good maps often utilize it as a feature, to achieve interesting gameplay scenarios.

But it may be interesting to see such a mod if there was any.

[BlueFeena]

Unless ZDoom offers some way of grabbing line, vertex, and maybe sector or blockmap data from inside a script, creating better path finding is an uphill battle. I should confess that I really don't know the first thing about ACS, so a lot of this is just general programmer ramblings:

Say you wanted to implement A* path finding. The best way to do this, would be with a grid. Unless you can read blockmap data from an ACS script, you basically get to build your own grid and assemble path finding data from that. You'd need the general size of the level, a reasonable grid size to utilize, and way of isolating which "tiles" are inside and outside the level. Alternatively, you could try some triangulation technique that might be otherwise over my head, but you'd still have create vertex and edge data so the triangulation could be calculated correctly. For that, you'd essentially need the level's wall data, and I don't know if there's a way to get that information in ZDoom. If there isn't, you'd basically need a fork of Doom Builder that would auto-generate a gigantic Enum, in ACS format, that stores all of the level's line and vertex data. At the point, the implementation would be up to the programmer from inside ACS.

[boris]

BlueFeena said:

Alternatively, you could try some triangulation technique [...]

Using the subsectors should be a pretty good starting point for A*. While they are not triangular, they are convex, which is perfectly fine.

BlueFeena said:

[...] you'd basically need a fork of Doom Builder that would auto-generate a gigantic Enum, in ACS format, that stores all of the level's line and vertex data.

What does that have to do with Doom Builder, let along the need to fork it?

[Gez]

Implementing A* in ACS is a dumb idea; you should rather implement it in the ZDoom code directly as a new A_Chase option.

[BlueFeena]

boris said:

What does that have to do with Doom Builder, let along the need to fork it?

I was referring to a way of reliably getting get line and vertex data from inside an ACS script (I'm not aware of ACS currently having any such functionality.) You'd need the variable data one way or another, and that's the only way I can think off the top of my head.

And yes, Gez, I don't doubt that implementing a new path finding algorithm via ACS might be ridiculous from an implementation standpoint, but it would allow for some kind of cross source-port AI behavior.

I guess the easiest way would be to just update ZDoom / GZDoom directly, but then you'd be out of luck for some of the multiplayer source ports.

[Doomkid]

Elaxter said:

Brutal Doom's AI changes are.

It would be nice if the AI changes from Brutal Doom were released as their own mod. Lost souls/Cacodemons that avoid projectiles, Shotgunners that 'commando roll' out of the way, and imps that actually jump as they slash.

All this, without the new guns, excess gore and new SFX would be amazing. Mark could just call it Brutal AI or something. Anyway, it obviously is possible in Zdoom/Zandronum, as BD demonstrates.

[gggmork]

I think to get a basic map layout in acs you could use acs spawn to spawn a grid of dummy things, maybe in 16 pixel increments, then treat anything that has a return value of 0 as a wall/obstruction. Save that as a 2d array grid of 1s and 0s for what is or isn't an obstruction. Maybe do this in an open script before other monsters warp in so the monsters won't interfere to behave as obstructions themselves.

I was thinking about ignoring decorate completely. Like even treat every single frame and rotation as a separate simple 1 frame behaviorless 'thing', then just remove the old thing and spawn the new one in acs to create animation or whatever you want with more control than decorate seems to allow with its less intricate larger lego pieces of premade functions. Maybe even calculate the angle to the player to spawn the appropriate rotation graphic of the current frame. You could even have like 64 rotation frames doing it that way. Whenever you want to move somewhere, spawn a dummy thing to see if it is blocked and fails to warp first. The monster behavior overall is quite fun as it is for gameplay, but acs could allow fun unusual experiments. I still haven't dabbled with things much. I know decorate does allow 'user variables' and acs execute probably, so maybe it is more powerful than I know. So far I like ACS better. Coding in zdoom itself would be powerful too but I don't know how and that'd be a big hurdle.

[Gez]

BlueFeena said:

I guess the easiest way would be to just update ZDoom / GZDoom directly, but then you'd be out of luck for some of the multiplayer source ports.

Only if it is possible at all with the features allowed by these ports. I don't think it is the case. There are hard limits to what you can do with barely-above-vanilla-Hexen ACS and no easy way to make actor logic refer to scripts.

In ZDoom it's less of a problem because you can use CallACS in DECORATE code and use its return value. In Odamex and ZDaemon you're limited to DEHACKED so you can't do that kind of things. In Zandronum, well, it's supposed to update one day.