Duke4.net Forums: DukeThought - Duke4.net Forums

Jump to content

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

DukeThought  "the bot I'm working on"

User is offline   Jblade 

#61

View PostTrooper Dan, on 17 October 2017 - 02:02 AM, said:


This is as good a time as any to post about some progress. Duke Thought is still incapable of completing any real levels, but the bot can get off to a good start in some levels before dying or (more commonly) getting hopelessly stuck.


That's still extremely impressive even if it can't finish the level yet. I know this is kinda down the line, but you thinking of integrating item use into it? It would be neat for the bot to be a bit artificially less accurate in dark areas but allow it to use the NVG to 'counter-act' that.

This post has been edited by Jblade: 17 October 2017 - 02:23 AM

3

User is offline   Danukem 

  • Duke Plus Developer

#62

View PostJblade, on 17 October 2017 - 02:22 AM, said:

That's still extremely impressive even if it can't finish the level yet. I know this is kinda down the line, but you thinking of integrating item use into it? It would be neat for the bot to be a bit artificially less accurate in dark areas but allow it to use the NVG to 'counter-act' that.


He's definitely going to use items -- so far only medkit, but other items will be used eventually. I don't know about NVG, though. I'm still having so much trouble with level navigation that worrying about item use seems like a distant luxury.

I can't overstate how hard it is to get the bot to navigate levels. In E1L1, he is able to get down onto the street and make his way into the theater before getting stuck there. But let's pause and think about how many hurdles there are to accomplish that simple feat. He has to understand that the SEENINE and/or FANSPRITE are things that you destroy and that you don't want to be near the SEENINE while it's blowing up. Then he has to understand that it's not a dead-end. This means he has to know that the teleporter in the chute (but not the one in the street area) is something to go towards. Navigating to it is actually tricky (as discussed in some earlier posts) because his walk will take him through child sectors that are not part of the official path. I haven't given him any fear of heights yet, but when I do I'll have to make an exception for when it's your only option to proceed. And that's not even one of the more difficult areas to navigate.
3

User is offline   DavoX 

  • Honored Donor

#63

I assume it can be used in dukematch as well? would be nice as a mode to play in faux multiplayer
0

User is offline   TerminX 

  • el fundador

  #64

This is really impressive. What can I do to EDuke32 to help you?
0

User is offline   Phredreeke 

#65

Have you considered adding a slight delay to the bot reacting to enemies? As it is right now it appears to have superhuman reflexes
0

User is offline   Danukem 

  • Duke Plus Developer

#66

View PostTerminX, on 17 October 2017 - 09:31 AM, said:

This is really impressive. What can I do to EDuke32 to help you?


I guess the biggest thing right now would be making it possible for the bot to be fully controllable via the input structure, rather than relying on hacks to simulate input for some things. I mentioned the weapon switching problem a while ago, and that's still an issue. The use of inventory items falls into the same category.

Another issue is that it's sometimes very difficult to figure out what the bot is bumping into. Regular actors who use move commands can check htmovflag, but that never gets set on a player. I have to rely on hitscans from various angles and heights and try to piece it together, often very inaccurately. I wish that htmovflag would get set on the player sprite based on the player's movement. I've thought about making the bot send out "probes" that report back to him about his environment, but that will add a lot of overhead to manage and I'm trying to avoid that.

A minor thing that would be useful would be the ability to log array elements directly without putting them into a var first. For example:
addlogvar wallpath0[savednode]


View PostPhredreeke, on 17 October 2017 - 10:09 AM, said:

Have you considered adding a slight delay to the bot reacting to enemies? As it is right now it appears to have superhuman reflexes


That's not one of my design goals. I'm not trying to make a bot that plays like a human, I'm trying to make a bot that can complete levels without "cheating". Cheating is defined as doing things that would be impossible to input with a mouse and keyboard. Imagine a speed runner who had played a level a thousand times -- they know where everything is and could hit enemies before they even appear on the screen, but that's not cheating.
1

User is offline   Kyanos 

#67

View PostDavoX, on 17 October 2017 - 09:25 AM, said:

I assume it can be used in dukematch as well? would be nice as a mode to play in faux multiplayer

I forked off from the old-mp source here and added some code to the bot ai for that deathmatch thing I worked on. It would be easy to add a bit of smarts and spice up the fake multiplayer that way, but that's derailing the thread on my end. Nice work TD. I must admit when I first saw what you are trying to do here with only con code I sort of thought you'd gone mad lol. Maybe the challenges of these things are half the fun.

View PostTrooper Dan, on 17 October 2017 - 11:00 AM, said:

That's not one of my design goals. I'm not trying to make a bot that plays like a human, I'm trying to make a bot that can complete levels without "cheating". Cheating is defined as doing things that would be impossible to input with a mouse and keyboard. Imagine a speed runner who had played a level a thousand times -- they know where everything is and could hit enemies before they even appear on the screen, but that's not cheating.

Your bot will end up setting new record times for speed runs :rolleyes:

This post has been edited by Drek: 17 October 2017 - 11:35 AM

1

User is offline   TerminX 

  • el fundador

  #68

View PostTrooper Dan, on 17 October 2017 - 11:00 AM, said:

Another issue is that it's sometimes very difficult to figure out what the bot is bumping into. Regular actors who use move commands can check htmovflag, but that never gets set on a player. I have to rely on hitscans from various angles and heights and try to piece it together, often very inaccurately. I wish that htmovflag would get set on the player sprite based on the player's movement. I've thought about making the bot send out "probes" that report back to him about his environment, but that will add a lot of overhead to manage and I'm trying to avoid that.

The value of RETURN in EVENT_CHECKTOUCHDAMAGE is equivalent to htmovflag.
2

User is offline   Danukem 

  • Duke Plus Developer

#69

View PostDrek, on 17 October 2017 - 11:26 AM, said:

You're bot will end up setting new record times for speed runs :rolleyes:


It really won't, though. :excl: It's based on the principle "find stuff to do that you haven't done yet". It doesn't even prioritize finishing the level when it has the opportunity -- it can be standing next to the nuke button, and it will go back and pick up health in a distant room before finishing. I regard that as a good thing, since completing an episode will be more likely if the bot keeps its health up.

It's quite possible that I'll hit a brick wall soon with regard to the pathing limitations, too. Jumping/platforming situations pose a huge challenge, for example, since they involve reaching a sector that is not directly connected to the one you are jumping from, and is only reachable via jumping.

About Dukematch: Making a bot that is actually fun to play against would require making it more human in terms of its reflexes and aiming ability. It's not fun to fight an opponent that instantly hitscans you with 100% accuracy. Also, dukematch levels tend to be very simple in design, so most of the work I have done on the bot would be irrelevant for navigating them. Since there are a relatively small number of dukematch maps, it would be much more efficient (both in terms of coding and CPU usage) to simply edit the maps to add paths to them. In fact I did something like that a long time ago with my Duke Nukem Arena mod, which had a lot of different gametypes where you could play on teams that included a combination of bots and monsters. I'm not saying that Duke Thought won't eventually have a Dukematch mode, but it's certainly not my focus at this time.
0

User is offline   Danukem 

  • Duke Plus Developer

#70

View PostTerminX, on 17 October 2017 - 11:48 AM, said:

The value of RETURN in EVENT_CHECKTOUCHDAMAGE is equivalent to htmovflag.


Cool, next time I work on this I'll need to experiment with that. I'll probably end up redoing a lot of stuff, but it should be better in the end.
0

User is offline   Phredreeke 

#71

Does the bot carry what it learned after each playthrough (like a human player would) to allow future attempts at the same level to be faster?
0

User is offline   Danukem 

  • Duke Plus Developer

#72

View PostPhredreeke, on 17 October 2017 - 12:27 PM, said:

Does the bot carry what it learned after each playthrough (like a human player would) to allow future attempts at the same level to be faster?


No. It's possible in CON code to save arrays and vars to files and read them back in subsequent sessions, but the bot in its current state is not able to make use of any saved information. Saved paths would be useless anyway, since the algorithm that makes paths would just generate exactly the same paths again given the same map. I don't see any way to provide it with deep reinforcement learning -- there's no way to make it generate new code to replace old code. So the kind of learning it would do would be very limited at best. I suppose there could be some vars that represent enemy threat values and item utility, and those could be adjusted over time to reflect the bot's experiences, but that's about it.
1

User is offline   Danukem 

  • Duke Plus Developer

#73

I have had a few crashes recently that coincided with garbage information in the log -- I tested with the newer snapshot that fixes some log errors as well as an older one, and it can happen in each version. The crashes take the form of the app suddenly quitting without warning. When I say "garbage" in the log I mean there are warnings about stuff but they either correspond to line numbers that do not exist at all, or line numbers where there could not possibly be an error of the kind named. Also the log said to send it to the devs along with instructions on how to reproduce the problem :rolleyes: I'll see what I can do the next time it happens.

I suspect that the problem has to do with my pathfinding code, and in particular with recursion. So hypothetically, what happens when a state calls itself hundreds of times and makes a huge stack that way? What is the limit on the depth of nested recursive calls, and what will happen if there are too many?
0

User is offline   Danukem 

  • Duke Plus Developer

#74

Progress is still slow and painful. I try to work on it at least a little each day.

Sprite bridges are a problem. My pathing code requires a YES or NO answer when querying whether the player can use a given wall to enter the next sector. Sprite bridges are not friendly to this requirement because the answer is "it depends". If you are trying to reach the nuke button in E1L1 (let's pretend like the jetpack doesn't exist), then you cannot do it directly from the street below, but you can do it from the very same sector if you are walking across the sprite bridge. My current strategy is to treat the bridge as a special exit, but not from the sector that the bridge is actually in. It is a special exit from the sectors on either side of the bridge. This way I avoid violating the rule.
1

User is offline   blizzart 

#75

View PostTrooper Dan, on 04 November 2017 - 02:57 PM, said:

Progress is still slow and painful. I try to work on it at least a little each day.

Sprite bridges are a problem. My pathing code requires a YES or NO answer when querying whether the player can use a given wall to enter the next sector. Sprite bridges are not friendly to this requirement because the answer is "it depends". If you are trying to reach the nuke button in E1L1 (let's pretend like the jetpack doesn't exist), then you cannot do it directly from the street below, but you can do it from the very same sector if you are walking across the sprite bridge. My current strategy is to treat the bridge as a special exit, but not from the sector that the bridge is actually in. It is a special exit from the sectors on either side of the bridge. This way I avoid violating the rule.


Excellent work, Trooper Dan.

Just out of curiosity:
Can this code or AI later be used for enemies in a similar way? Like enemies taking cover or hide when being shot. Or enemies looking for a way to get in the back of a player instead of running into him? Or, for example, when the player enters a builing and an alert starts, the enemies in an area nearby start to search for the player or looking where that alert is coming from?
I don´t know if porting an AI bot code to enemies is that easy, but that would be a massive improvement to the gameplay. Especially for mods.
2

User is offline   Danukem 

  • Duke Plus Developer

#76

View Postblizzart, on 24 November 2017 - 05:52 PM, said:

Excellent work, Trooper Dan.

Just out of curiosity:
Can this code or AI later be used for enemies in a similar way? Like enemies taking cover or hide when being shot. Or enemies looking for a way to get in the back of a player instead of running into him? Or, for example, when the player enters a builing and an alert starts, the enemies in an area nearby start to search for the player or looking where that alert is coming from?
I don´t know if porting an AI bot code to enemies is that easy, but that would be a massive improvement to the gameplay. Especially for mods.


First let me say I have taken about a month off from working on this project, due to burnout and real life priorities. However, I will be getting back into it this weekend.

For any mod or TC where you are releasing maps, I believe it is much easier and more efficient to use a waypoint system with sprites placed in the saved maps to aid in enemy navigation. For example, you can put invisible sprites at coordinates that you know are good cover, and place trail sprites throughout the map, indicating where enemies can walk without obstructions. This still requires a significant amount of work to code enemies to traverse the waypoints and use the cover sprites (and also to analyze the tactical situation in relation to the player), but it is still way easier and less resource intensive than coding a bot to complete levels unseen with no waypoints, which were not designed for bots. Work that I and other Duke modders have done on earlier projects already suffices for accomplishing most of what you are asking about, whereas what I am doing on Duke Thought isn't directly relevant.

One technique that works very well as far as getting enemies to follow the player over long distances is, making the player spawn invisible "bread crumb" sprites for enemies to follow. Something like this is present in Duke Plus when "advanced AI" option is enabled, but I refined and simplified it quite a bit in Duke Forces and Essential Duke, and you are welcome to port it to your own project. For making enemies use cover without any real intelligence, I recommend defining the cover points with sprites, then scripting certain enemies to run towards them when the fight starts. It's also good if they telegraph it by yelling "take cover!" or something like that.
0

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options