ZDoom: Replace ZCajun by ZDoomBot 5.2

[Arctangent]

Maes said:

hitscans

... don't need to be predicted at all, you literally just have to put the theoretical crosshairs right on the target. In fact, predicting a player's movement with hitscans would lead them to miss, because there's no delay between them being fired and them hitting; leading the shot would then lead to shooting not your target, but something else entirely.

The only reason humans lead their hitscan shots is to compensate for the fact that they are human and therefore don't have frame-perfect reflexes, especially with compensating for the trigger pull of Doom's arsenal.

Also, your theory on projectile prediction sounds more like something you'd use for spamming than precision shooting. You know a player is likely to be between x1y1 and x2y2, so you hold down the fire command and shoot projectiles at random places in the area. Which I suppose is actually far more realistic than actually leading the shot, considering how players actually move, hrm ...

[Maes]

Arctangent said:

Also, your theory on projectile prediction sounds more like something you'd use for spamming than precision shooting.

That's correct, in a way. Imagine being able to constantly harass your opponent by having him encounter projectiles right in front of his path. Just the psychological impact of knowing that it's not enough to run away/keep a distance from your opponent should be devastating. Superficially, it would appear like an unusually accurate spamming (or "zoning", if you prefer the 1337 pro-competitive term for it) or like your opponent always knows where you are.

Arctangent said:

hitscan delay

I actually managed to get a kill by "leading" my SSG aim in an extremely laggy ZDaemon game (mapset was Cybercrime 3.0). But the ping was really extreme, like 2000 ms :-)

[wallabra]

Sorry to stop your interesting discussion, but from here on this thread will be for assistance with DoomBot-esque bots.

[kb1]

Maes said:

It's kinda of a paradox that in the quest of trying to make bots "more human", they actually end up being less efficient/less of a challenge for human players. In theory, a bot could snipe a human opponent with perfect pinpoint accuracy from well beyond visual range with hitscan weapons ("pixeling", but WHILE MOVING), or calculate 100% accurate leading for projectiles. A bot could also simply run up to a player, and orbit around him while destroying him with melee attacks, avoiding retaliation, instantly turning etc.

I believe that there can be ways to mitigate the issue "honestly".

The easiest (and least 'honest' way would be to simply add some randomness to the aiming and nav accuracy). But, if you really try to emulate some more subtle human characteristics, some inaccuracies can start to creep in, in a more-natural manner.

For example, sure, even a human, camping in a dark isolated tower above the arena, can spend multiple seconds aiming, waiting for the exact moment that DoomGuy walks in front of your line of sight. But, for a bot to do that, it must not be "frightened" that it might be in danger. A "smart" bot might "hear" a person or monster coming, and be afraid of standing still. Could be as simple as a couple of vars: 'bool being_chased', and 'int fear_level'.

Furthermore, a bot coming towards you should be afraid of you! Especially if you're looking (aiming) in their general direction. This may cause the bot to retreat, or dodge.

Other vars come into play: A hurt bot should have a heightened 'fear_level', and a bot with 1 bullet left in their current gun should be afraid of a room with more than 1 opponent.

How about desire to collect health vs. desire to kill? Or, "Wow, a BFG!".

I am not trying to explicitly build a bot in this response, but I am trying to make a point: A bot can be made 'smarter' by making it more sophisticated. And it doesn't have to be difficult code - what I'm driving at is that your bot could have more info to work with. A handful of real-time statistics would make your bot more human-like, and would allow more sophisticated behaviors naturally.

You don't have to be a genius to come up with interesting AI modifiers, either. I would try to imagine what I would do in a particular contrived situation, then imagine the fastest, most-efficient way to convey that information to a bot via a data array.

For example:
* There's a 25% health box, and my health is 70% (score +25)
* ...but it's 43 units away (score - (43*some scale factor) = -4.3))
* ...there's a skeleton near the health box (score -15)


You tally up the positive possibilities, and subtract the negative possibilities, and end up choosing 1 action that seems like it minimizes the bad and maximizes the good. I know this is a generalization, but not a huge one. Some actions require an action to be dedicated over time, like navigating to a spot, or aiming a gun. This causes actions to take time, and, maybe the bot's desire changes in that time.

Back to point: That delay, combined with the possibility of a decision change, can lead to a bot that doesn't spam fire, and doesn't orbit you in small circles, etc. Or in other words, a more-human bot, made possible because more real-time situational data is available to it.

I proclaim that: A bot that chases you and spam-fires at you relentlessly, with perfect aim, is a dumb bot! A second coop player, or a monster can blow them to bits with ease.

Now, gathering all of this real-time data efficiently can be a daunting task, and make require some serious pre-processing of the level. Special nodes, some A* pathfinding, etc. Doom already possesses some of the run-time tools needed to gather info.

To summarize:
1. Adding a little bit of randomness can reduce a computer bot to human-like abilities, but please use lightly!

2. The more info a bot has available, the more things it has to consider, and the more human-like it will appear to be.

3. Psychology major not required. If enough pros and cons are gathered and accumulated, complex, non-spastic behavior will emerge, without having to make the AI brilliant.

4. Writing the code to support efficient gathering of these types of info may not be trivial.

[wallabra]

That would be a brilliant bot!
And mine would build navigation based up on glnodes!

[kb1]

Some type of nodes are needed, because sight is an extremely complex problem for a computer, but pretty trivial to a human, or so it would seem. You know, a coop bot would do a decent job by simply going where the player has already gone, and that would be very simple to implement. Not really smart enough, but good enough to use during development of some of the other characteristics, and it wouldn't require a complex node lump.

The building of a good bot system, that can be dropped into a vanilla-like port, is on my list of projects that I'll probably never get to :(

[RestlessRodent]

kb1 said:

The building of a good bot system, that can be dropped into a vanilla-like port, is on my list of projects that I'll probably never get to :(

Eventually for ReMooD I may get to the bots for it. However even at this early stage I plan for ReMooD bots to interact via an API (over a TCP connection) of which another port could write an adapter for the protocol. ReMooD being a bot client could just connect to the port's server. This would be a simpler route since ReMooD is in Java which if direct execution with JNI was used then other ports would require a JVM. ReMooD would also be receptive to being a bot server, thus if someone writes a bot which talks via the protocol it could be used with the port. At least using a protocol one can keep the bot separate from the port and would allow different bots to be used in place (could have bot competitions for example). The main purpose of this would be for me to implement a receptor to the protocol in Chocolate Doom and then have a bot try to beat Doom/Heretic/Hexen at the same time on ReMooD and Chocolate Doom (using the same inputs) to check for compatibility (since I care for Vanilla compatibility). This would work better than demos because more game state information may be compared since demos may appear in sync yet be desyned or are crippled (such as in Heretic), it would also be simpler since checks can be done ad-hoc rather than just a heavily modified Chocolate Doom which just dumps information at maximum verbosity (adding in those data dumpers would be a huge pain also).

[wallabra]

So, which is the best modern bot? How to write a bot for ZDoom or PZDoom?

[kb1]

GhostlyDeath said:

Eventually for ReMooD I may get to the bots for it. However even at this early stage I plan for ReMooD bots to interact via an API (over a TCP connection) of which another port could write an adapter for the protocol. ReMooD being a bot client could just connect to the port's server...

This is a brilliant idea! It would almost work for Vanilla, except that the bot needs some real-time data from the port. It would be really nice if we could devise a standard way of writing that data out to bots. This idea stirs the imagination.

[RestlessRodent]

kb1 said:

This is a brilliant idea! It would almost work for Vanilla, except that the bot needs some real-time data from the port. It would be really nice if we could devise a standard way of writing that data out to bots. This idea stirs the imagination.

For the TCP API I was thinking a kind of poll-based system so that data is obtained as it is needed. There would need to be basic notifications though such as when the level changes or an important event occurs (level change, player getting killed, CTF flag obtained, etc.), depending on the port. Possibly could use a registration system to request for events with a lifetime if supported, so the bot client could ask if "May I be told when sector 42 changes floor height only for this level?" then the server would say either YES or NO.

As for vanilla, it runs on DOS so it is not like it cares about screwing with its memory. As such you would need to know Doom's memory layout and then have a program which reads from it, so the bot would basically be a DOS TSR that runs in protected mode or at least a bridge to another computer (say over a serial port for example). Vanilla has this remote tic driver thing one can use for joysticks but it could be hacked for bot input.

The API over the network would need to be abstract enough where it can support ports more advanced than vanilla however (so not many magic numbers) and varying differences between ports. So instead of saying that a cvar 1 changed value, it would instead be "remood_co_enablebloodsplats" changed value. A port such as a modified Chocolate Doom would ignore this variable because it has no idea what to do with it rather than just crashing.

If you do want to devise a standard along with me, I would only want to standardize the TCP aspect rather than the C/C++/Java API aspect of it. Also TCP because it is a stream protocol and it could easily be attached to UNIX sockets or a serial port (you could use socat or similar), the bot would most likely be very local so ping would not be an issue nor would bandwidth. I would also want a binary format so that 123456 is encoded as its actual binary bits rather than literally "123456". The packet format should also be extendable so something along the lines of an 4 character ASCII magic number (such as qCVR for request CVAR value), followed by the packet size, then the data. Then if the remote end can then reply with pCVR which contains the value of the CVAR, reply with eCVR if the CVAR is unknown, or say eUNK if the packet is of an unknown type so it may be ignored. Would be similar to PNG in a way ([QPE]??? could be for non-standard packets). This way the protocol remains extensible and easier to look at on the transport layer.

EDIT: Fix wrong character.

[sgtcrispy]

I miss Eraser bots...

[wallabra]

sgtcrispy said:

I miss Eraser bots...

What-bots? I never heard of them.

I miss the time where bots were great, now even Quake one bots surpass that :(
Saying on bots, what 'bout bots in other games?


(On a unrelated note, topic starters get less atention nowadays :P)

[wallabra]

DoomBot is great! Now I can update its code... if only someone release its source code...

[RestlessRodent]

Gustavo6046 said:

DoomBot is great! Now I can update its code... if only someone release its source code...

Convince the author to license it under the GNU GPLv3 then it will truly be free.

EDIT: You could also write your own code. A bot written in ACS meant to run with the limitations of ACS is not going to perform well in general. It could work but it would be very messy. Your best task would be to take up Java/C/C++/Python/Ruby/etc. to write the bot.

[wallabra]

GhostlyDeath said:

Python

I am a so great Python coder! Unfortunately this should only work as an addon for a Python source port of Doom (say, PZDoom), including Python's GUI limitations.
So sad I am still learning C++... (but that will be very useful in the future!)

[kb1]

GhostlyDeath said:

...If you do want to devise a standard along with me, I would only want to standardize the TCP aspect rather than the C/C++/Java API aspect of it...

Please see your PMs.

[wallabra]

In fact how to make a Python bot?