[v0.11.1-rc2] ZetaBot: The ZScript Bot

[Gustavo6046]

​ (For the Pretty Paths Compilation, see this reply.)

The ZetaBots are here, to side you in coop or to square you in deathmatch!

Status: Late Beta

Download Links:

• GitHub

The ZetaBot is the new generation of AI bots, whether be they friends or foes, still echoes of a distant, long forgotten past. Born to a world of chaos, they were forced to evolve and adapt since their inception. You don't want to learn the hard way, by being on the other end of the barrel!

• ZetaBot will be capable of using any weapon they find, because they use a special model where a ZetaBot class controls a 'doll actor' (made to look and sound like a player), which can pick up any weapons, which are used. The kinds of dolls that can be "possessed" and weapons that can be used are known thanks to special modules - ZetaModules.
• ZetaBots works for both cooperative and deathmatch play, including teamplay support. In the former, they're good at mopping the floor with monster brains, less so at navigating around obstacles, but still quite better than the default ZCajun. In the latter, they make for formidable opponents, easy to overlook but tough to overcome! You will have some new lead piercings after you encounter one. Hey, at least they're for free!
• A functional pathing system that the bots can actually use. Nodes are plopped manually, and can be stored both in a node list CVar or in node lumps. The CVar stores a serialization format that allows multiple levels into one. By default, dumping the nodes of a level will result in them being appended to this CVar, or overwriting a previous version of the section for the same map. It is also possible to copy the value of a nodelist to a ZBNODES lump even in a separately loaded WAD, a catch-all that can contain nodes for many maps, or if you're a mapper, you can include nodes for your newest creation as a ZBMNODES lump right after your map's lumps. Pathfinding is real-time and dynamic -- if a lowering floor makes a new area accessible, the ZetaBot will know!
• It is possible to place nodes ingame, testing with bots as you go, and even save. A set of default keybinds that uses primarily the numpad is included, but can be changed in the Controls menu. Tip: set zb_autonodes and zb_autonoderespawn to false as you do, lest some guinea pig test subjects ruin the whole thing for you! The navigation system was heavily inspired by Unreal Tournament - so if you have used the Unreal Editor and know how to plop down PathNodes in Unreal, you might already know how to plop down ZetaBot path nodes well here!
• Multiple bot voices, both male, female, and even robotic. With taunt lines, hurt ouchies and angry screw-yous, and of course the occasional silly idle chatter to top it all off, to give some personality to Alicia, your favourite war veteran boomer.
• Simulates an actual player as closely as possible, with a very similar movement set and default weapon module behaviour for your favourite games. Some obvious engine limitations (like not being present in the scoreboard) are ultimately inevitable... but might actually be worked around in the future, as the GZDoom source port is continuously developed and exposing more and more of its own guts to ZScript. Hayo! (Ew, guts, though.)

"Screenshots or didn't happen!" As for visuals, it's mostly just the plain old skins from the games supported by the ZetaBot. Except with a pretty Zeta Cape, if you enable it... But since you insist, here we go, some gratuitous bot action!

---

[Funky Gnoll]

ZetaBots: The ZScript Bot
ZetaBots are an early attempt at reviving the Doom bot scene

I've never opened a thread this quickly.

[Gustavo6046]

You are right, I should probably try and resume its content. But I'm not good at presentation of work

[Dark Pulse]

As an Unreal Tournament veteran (hell, I helped run BeyondUnreal for a number of years), I know quite well how PathNodes work... but then you've got me wondering how this would be supported in non-stock maps.

Would the mapper have to include these ZTPathNodes in their map? Does ZetaBots generate them on-the-fly through priority of powerups/pickups and knowing that there (should) be fixed MP/Co-Op starts? Would the end-user just generate these for maps and have them in a separate WAD or something?

Definitely intrigued by this, but if there's not some way of "automating" how the pathnode network is built, you're reliant on the mappers adding those to their maps or the end-user being able to do that somehow.

[Gustavo6046]

Like in Unreal, it is mostly the mapper's job right now - pathing usually takes up to 5 minutes for maps like MAP01. It can be saved in a CVAR named nodelist.

Automatic generation will be eventually supported, but it will be a Node.JS program that uses node-wad to parse the map and generate the pathnodes.

[Nash]

Commenting to try this later. I am fucking stoked to read about this!

[Gustavo6046]

stoked!

Have fun with a pathnode (de)serialization thing that saves and loads from a nodelist server CVar, and a bot that crashes on load because it can't use UserCMDs.

I began this project thinking on finishing it. I actually came close to it. But I needed help. I could not do it alone. I needed someone that cared. Even knowing that it might be very rare for someone to even give a shit with helping, each person that goes by and glares in the thread raises a little the smirk in my face.

[kadu522]

I can try to playtest this since i play mostly single player.

Do you have a idea where the crash usualy happens and recomended mods to test with?

[Nash]

So how do I test this? The ZScript is a little daunting for me to figure out on my own.

[Gustavo6046]

Sorry for the somewhat long time I was off, as I moved to Linux and I'm struggling to get SLADE3 to work, which might require me to install GCC 7.0.0... Why don't they just update Xubuntu to Ubuntu 16.10?

Anyway, I will work on the ζetaBots, making it some sort of super smart monster with node-based navigation and universal weapon usage. (We will probably not see custom player classes being used by the bot for a long while...) But that would be a very large change, so I'll schedule that for later. First off I want to update the DecoBots and give it female voices which I might reuse later with the ζetaBots. Hey, I might even make a similar controller scheme, but that works for any monsters (including some player class adapted for the bot)!

Node-based navigation will probably not be a large hassle (it probably works the way it is already), but universal weapon support (i.e. being able to use any weapon a normal player would) will be difficult.

I have a few alternatives for that:

1. Module-based. The idea here is that weapon support should be provided by separate "module" mods. Each module should give a simple way to rate different weapons - giving each weapon a priority or rating, based on a given scenario or situation -, in a way that is faithful to how the weapons themselves work, and in addition give metadata like minimal safety distance, and rapid-fire (whether it's more efficient to hold than to keep pressing the fire button). It should come with the default Doom II, Hexen and Strife modules (therefore the bots should be able to use the Rocket Launcher, Super Shotgun, the Crossbow, the HE grenades, and sooo on...); people can add support for their mods doing their own modules if they want.
2. Monster-based. The concept here is that the ζetaBots still have the controller schemes, but instead of controlling player pawns, they control monsters. Each monster has a set of attacks the ζetaBot controller should be able to use. However, playerlike ζetaBots can be created in a similar way to the DecoBots; a custom MONSTER class, that inherits from a player class (or something of the kind), and THAT class should itself decide which weapon to fire, and how: for example. the DoomPlayerBot wouid be able to select from the Doom II array of weapons, while the HexenPlayerBot branches into bot versions of the Hexen classes, and so on.
3. Mixed. Uses a combination of both bot schemes. In such case, I would make it very similar to the monster-based scheme, but have the playerlike monster classes select any weapon from the loaded modules (from the module-based scheme). This would allow for any supported monster or player class to become a bot, AND select any supported weapon available for the corresponding class. The catch is that both the monster/playerlike classes AND the weapons would need their support implemented, which usually implies extra work.

Which do you think would work better? Please tell me... I should open a poll about that here. (can I open polls in existing threads?)

So how do I test this? The ZScript is a little daunting for me to figure out on my own.

It can't be tested normally, unfortunately. I scrapped the current idea of how it would work (a controller that spawns and controls a random player class), since player classes are delicate internal stuff, and internal stuff is more inflexible than I imagined. (I bet even UnrealScript allowed compiled UC code to access native stuff!)

We need a good and proficient ZScript debugger, something that helps debugging in ways like inspecting the "variables" of the pointed-at actor (actor variables like position and velocity, custom variables defined in DECORATE and ZScript, and so on), as well as the function stack; but it should come with some GZDoom "debug mode" (who knows the developer CVar?) and somewhat easy to use in a visual way.

However, I presented three possible alternative ways that MIGHT work.

Do you have a idea where the crash usualy happens and recomended mods to test with?

I know why the crash happens, and there is no simple work-around - native/internal stuff.

I recommend mods that (will) support the bots in first place (since I plan to make the bot support for mods (and games/IWADs too!) depend mostly on the modders).

As for game mode, it should work for cooperative mostly (singleplayer, but it should work for multiplayer as well!) I plan to add Deathmatch and other teamgames later on. (Teamgames might have to be supported by modules as well, with the exception of the most common Zandronum gamemodes, like DM and CTF).

[XavierStudios]

I cannot claim to fully understand to what extent modders will have to go to add compatibility or what, if any, functionality is being traded between Module- and Monster-based bots, but I can presume that the mixed approach would offer the most flexibility in the end.

As such, in my ignorance, I cast my vote for the Mixed approach if only for the perceived benefits as compared to the other two concepts. Perhaps a more practical explanation of the pros and cons of each would help us (me) understand and make a more informed decision.

[Gustavo6046]

Thanks, buds. I did also bet on that one.

So, now I will write my AUR install script, so I can install SLADE3 in my new Linux system, and hopefully continue working in the ζetaBots once we have a better plan of "action".

[Rachael]

You should probably know that GZDoom currently has plans to ditch its internal bot system completely and use ZScript for its bots, sometime in the future. This is one of the projects I was thinking about when that hit the planning phase, but I don't know if you are interested.

[Dark-Assassin]

Any chance that a system like A* could be used instead? This would have to account for line actions and such too.

[Korell]

You should probably know that GZDoom currently has plans to ditch its internal bot system completely and use ZScript for its bots, sometime in the future. This is one of the projects I was thinking about when that hit the planning phase, but I don't know if you are interested.

Would this then mean that botmatches could then be possible within GZDoom?