Duke4.net Forums: DukeThought - Duke4.net Forums

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

  • 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   TerminX 

  • el fundador
  • 5,044

  #31

View PostTrooper Dan, on 29 September 2017 - 09:25 AM, said:

P.S. to any devs who may be reading -- as I was saying above, it's not possible to switch weapons by setting the corresponding bits in the input structure. I would be very helpful if that could be changed.

That would require an additional event that's similar to EVENT_PROCESSINPUT but executes at a different place in the code.

EDuke32 • wiki • svn builds • bugs
Join us in #eduke32 on irc.freenode.net!
0

User is offline   Drek 

  • 1,206

#32

View PostTrooper Dan, on 26 September 2017 - 07:38 PM, said:

My focus for the last few weeks has been on single player AI, and I have allowed my coop AI to become broken (mainly because it sits on top of items because it doesn't notice that they stay in coop).

It would be really cool if access to some of the bot behavior here was exposed to con. In my multiplayer thing I worked on source side to change preferences for which guns to grab, I also coded in health/ammo level checks for the bots to prioritize those pickups when low on health/ammo....

irrelevant code block, getspritescore in player.c
Spoiler

0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#33

View PostTerminX, on 29 September 2017 - 03:53 PM, said:

That would require an additional event that's similar to EVENT_PROCESSINPUT but executes at a different place in the code.


Alternatively, I would be happy if there were a CON command selectweapon <weapon#>, which when executed would act like the player had pressed the corresponding weapon key. Alternatively alternatively, I would also be happy if I could figure out why the shotgun often locks up when the bot switches to it. Everything I have checked looks normal when it is locked (weapon_pos==0, kickback_pic==0, etc.) but pressing fire won't fire. I feel like I have seen this happen before in some other context, but I can't remember the solution.

View PostDrek, on 29 September 2017 - 04:53 PM, said:

It would be really cool if access to some of the bot behavior here was exposed to con. In my multiplayer thing I worked on source side to change preferences for which guns to grab, I also coded in health/ammo level checks for the bots to prioritize those pickups when low on health/ammo....


I'm not sure what you mean about exposing bot behavior to CON. My bot is entirely CON coded, and I'm not interested in piggy-backing on the hardcoded bot behavior.

As for prioritizing pickups, yeah that is a good thing to do, especially in a coop situation where the same resources are needed by all players. I haven't made use of prioritization much for my bot, though, because he goes to the first goal he finds which has any value at all. In the future I may have him find several different potential goals and choose the most valuable. The value assessment that I do assigns a "botneed" to each item that is searched. For example:

		case SIXPAK
			set temp MAXPLAYERHEALTH
			sub temp sprite[].extra
			mul temp 15
			setav[botvar2].botneed temp
		break


In this case botneed would be 15 points per point of damage the player has taken.
1

User is offline   Drek 

  • 1,206

#34

Ahh I see, you're completely bypassing the hardcoded bot stuff. In your case then it should be easy enough to change pickup priorities just by con. A thing to take note of is some trouble I had with SOS tricking the bots, they would go to the proper coordinates, but be in the wrong place SOS wise and then just sit there, I put a cheap time check where if the bot was in the same place for a few seconds the sprite got put onto an ignore list. It was far from perfect but it at least kept bots moving around in death matches.
0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#35

View PostDrek, on 30 September 2017 - 06:33 AM, said:

Ahh I see, you're completely bypassing the hardcoded bot stuff. In your case then it should be easy enough to change pickup priorities just by con. A thing to take note of is some trouble I had with SOS tricking the bots, they would go to the proper coordinates, but be in the wrong place SOS wise and then just sit there, I put a cheap time check where if the bot was in the same place for a few seconds the sprite got put onto an ignore list. It was far from perfect but it at least kept bots moving around in death matches.


My bot has 99 problems but SOS ain't one. Mainly because his navigation isn't based on map coordinates. His primary mode of navigation is to move through a list of connected sectors to the target. Once in the same sector with the target, he also does a visual check. Normally he doesn't even check distance to the target unless he is already in its sector. I do run into plenty of problems with odd shaped sectors, child sectors and very small sectors, though.
2

User is offline   Perro Seco 

  • 140

#36

I find this very impressive. Even more if is only a 5% of what you want to do.

Some years ago I tried to make a bot to help the player killing enemies but I couldn't even make him shoot properly or follow the player. It was pure crap. :D

Posted Image
1

User is offline   Darkus 

  • 263

#37

It's funny, I also started coding a coop bot some time ago. But the only thing I made is the pathfinding code, it's unfinished, but it actually works, and need some refining, like choosing between alternate path/objectives.

I'll probably go back finish it, understanding and making pathfinding works in EDuke32 made me want to continue.
0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#38

View PostDarkus, on 01 October 2017 - 08:55 AM, said:

It's funny, I also started coding a coop bot some time ago. But the only thing I made is the pathfinding code, it's unfinished, but it actually works, and need some refining, like choosing between alternate path/objectives.


That's cool, I'm curious as to how your pathing handles this kind of situation:

Posted Image

The "shortest" path goes directly from the outer ring sector to the room in the north, since that involves passing through the fewest sectors. But the bot will walk into the child sector, taking him off the path.

This will cause him to make a new path. The new path starts from the child sector. BUT: the particular wall he chooses to reach the northern rooms matters. If he just goes through the first wall, he will end up going south, then loop back infinitely. So I had to make sure my path stored not just a list of sectors, but a list of walls to cross. Then I discovered that even this wasn't good enough. For example, it fails when going for the fan sprite on the roof of E1L1. No matter which wall he chooses, the walls are so far from the target that he will end up going back to the big child sector in the middle. In the E1L1 case, he can just go straight for the fan once he sees it, so it's not a game breaker. But that's not a general solution.
0

User is offline   Darkus 

  • 263

#39

Well for now my code just check if there a valid path between the player and an atomic health, then draw the path by turning passable sectors to blue. It still does not check for doors, elevators, teleporters... But it check for heights, for the sectors you can jump on, or if there enough space to crouch down.

I did an test map with a small maze, it contains some invisible walls (the teleporter is only here to check if 'failing' condition):

Posted Image

So after executing the pathfinding code, you only need to follow the blue sectors, until you reach the atomic health, avoiding the invisible walls:

Posted Image


In your case, since my code choose a random wall to move to the next sector, I see what will happen: the bot will enter the sector, calculate the new path, pick a random wall, and leaving the sector in the wrong side, then I will re-enter the sector, re-calculate new path, and re-pick a random wall until it finally get out. It may work, but as you said, it's not a solution (funny thing that the orinigal bots from Atomic Edition have the same problem).

Maybe the solution consists to make the bot ignore the sector, until it reach the desired one. but the sector may be a hole or a wall, so the bot need to act accordingly, for example, moving along the walls.

I also though to check if there a visual contact between passable walls, to make the bot move directly to the last visible wall but I never tested if it really works.
1

User is offline   Micky C 

  • Honored Donor
  • 3,426

#40

DT I'm sure you've already thought of this, but what's wrong with generating a trail of sprites for the bot to follow based on your sector code? For example, if it looks at the smallest number of sectors to pass through, then places sprites in the center of those sectors. In the case of your example, it would place the sprite in the middle of the child sector, but that isn't necessarily a problem. Then there could potentially be some code to delete redundant sprites to make the path shorter.

Although I have a feeling that there are countless numbers of tricky situations with problematic solutions, and this is just one random example you happened to post.

Polymer wishlist: Global illumination, SSAO, Bloom, reflective surfaces, adjustable specular (wetness), volumetric lighting.
Mapper of the Month December 2014.

Herbs? Tell me more!
1

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#41

View PostMicky C, on 01 October 2017 - 04:08 PM, said:

DT I'm sure you've already thought of this, but what's wrong with generating a trail of sprites for the bot to follow based on your sector code? For example, if it looks at the smallest number of sectors to pass through, then places sprites in the center of those sectors.


It's true that there are advantages to using a sprite trail in some situations. I don't currently spawn one in the E1L1 case, but I did at one point. I do use sprite trails as an emergency backup system, but it's not reliable because I don't have good code for placing the sprites. The main use case for sprite trails is oddly shaped sectors. For example, imagine if you took Darkus' maze up there and deleted all the red walls, so it was just one big sector. Clearly, a navigation system based on finding viable nextwall relations between sectors would be useless. But the trick is, how do you know where to put the sprites without actually opening up the map in a map editor? Putting a single sprite in the "center" probably won't help in the cases where sprites are sorely needed. In many cases, the "center" is null space (imagine, for example, a sector with a white walled square cut out of the middle instead of a child sector, or imagine an L shaped sector where the midpoint would be in the void).
0

User is offline   Gambini 

  • 1,290

#42

Clever thing. A step forward in Duke AI for sure!!

My maps

eat my shorts
0

User is offline   TerminX 

  • el fundador
  • 5,044

  #43

Can't you just ignore a child sector if every wall in its loop has a nextwall that matches the sector you're starting from (or -1)?

EDuke32 • wiki • svn builds • bugs
Join us in #eduke32 on irc.freenode.net!
0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#44

View PostTerminX, on 02 October 2017 - 09:38 AM, said:

Can't you just ignore a child sector if every wall in its loop has a nextwall that matches the sector you're starting from (or -1)?


That would probably work in the simple case described, but it fails if the child sector is split in two (or any more complex configuration of child sectors). It might be worth trying anyway, since there are plenty of simple cases like that in maps. However, "ignore" means substituting the parent sector for the child sector in the navigation code, which means running the wall loop to check and then doing the substituion in all the relevant places --- not something I want to do if I can avoid it.
0

User is offline   Forge 

  • 5,382

#45

How well does it do jumping from 'platform' to 'platform' in a large 'bottomless' cavern?

Like the jump-puzzle section in Dagger's Cavern

Posted Image

This post has been edited by Forge: 02 October 2017 - 10:30 AM

0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#46

View PostForge, on 02 October 2017 - 10:30 AM, said:

How well does it do jumping from 'platform' to 'platform' in a large 'bottomless' cavern?

Like the jump-puzzle section in Dagger's Cavern


I haven't even started working on platforming yet. The only time it will jump is when it is bumping up against something directly in its path, and it perceives that there is more room to move forward if it were a jump height higher. Consider what it takes to get the bot to make and execute a path to the secret rocket launcher in E1L1. The pathing code has to be able to see that you can jump from the box sector up to the apartment balcony, despite there being no direct link between those sectors (there is a much lower sector in between). Right now, if the next sector is too high relative to the sector you are coming from, then it is ruled out. So if the lower sector that the player jumps over is included in the path, then there must be an exception based on jumping from the previous sector.
0

User is offline   Gambini 

  • 1,290

#47

The ultimate achievement for your bot would be to beat Roch Island!

On a serious note, this project, specially the challenge behind, is very interesting. Looking forward to see progress!

My maps

eat my shorts
1

User is offline   Micky C 

  • Honored Donor
  • 3,426

#48

View PostGambini, on 02 October 2017 - 03:48 PM, said:

The ultimate achievement for your bot would be to beat Roch Island!


I'm sure there's a huge list of maps that the bot wouldn't be able to beat, no matter how smartly you programmed it. Something as recent as Spacetronic would be a massive challenge. If nothing else the bot would have to hit some obscure touch plates (as it wouldn't realize that there are 'items you can pick up' there), and then use the corresponding switch back at the central computer. In cases like this, the code would certainly have to do some kind of scan of the map to see how things are connected, and even then I'm not sure it'd work.

These kinds of mapping tricks will be one of the major problems.

Polymer wishlist: Global illumination, SSAO, Bloom, reflective surfaces, adjustable specular (wetness), volumetric lighting.
Mapper of the Month December 2014.

Herbs? Tell me more!
0

User is offline   Gambini 

  • 1,290

#49

IIRC Roch Island features classic duke mechanics, in a complex way, but still classic.

Maps like Spacetronic or LPT are extravagances nobody would expect a AI would beat, but there is a good amount of hard maps which only rely on classic duke mechanics (shootable buttons with "password" keyhunting, timed doors, destructible environment, pipebomb puzzles, etc, which would be a nice challenge.

My maps

eat my shorts

This post has been edited by Gambini: 02 October 2017 - 06:11 PM

0

User is offline   Forge 

  • 5,382

#50

As long as it was smart enough to get that keycard hidden on the roof
0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#51

I'll be happy if the bot can complete even a relatively simple map. Believe me, it is still very very stupid. It is still having problems with looping on groups of sectors and getting stuck on scenery and stuff like that. I don't even know the proper way to tell it if a door has been unlocked.
0

User is offline   Drek 

  • 1,206

#52

                case CHEAT_UNLOCK:
                    if (VOLUMEONE) return;

                    for (i=numsectors-1;i>=0;i--) //Unlock
                    {
                        j = sector[i].lotag;
                        if (j == -1 || j == 32767) continue;
                        if ((j & 0x7fff) > 2)
                        {
                            if (j&(0xffff-16384))
                                sector[i].lotag &= (0xffff-16384);
                            G_OperateSectors(i,g_player[myconnectindex].ps->i);
                        }
                    }
                    G_OperateForceFields(g_player[myconnectindex].ps->i,-1);

                    P_DoQuote(100,g_player[myconnectindex].ps);
                    g_player[myconnectindex].ps->cheat_phase = 0;
                    KB_FlushKeyBoardQueue();
                    return;


Judging by that block of code I'd have to guess that the sector itself holds the data in its lotag.

This post has been edited by Drek: 03 October 2017 - 11:19 AM

0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#53

Over the past few days I have been trying to fix some foundational problems with my pathfinding loop. It was failing to find paths to goals when the paths were more than about 25 sectors long, mostly do to the search looping back on itself depending on the level construction. I would have it just give up when it detected that it was looping too much -- a failsafe mechanism at best.

So I added the ability for the recursive search to detect and mark dead-ends. Any sector that only leads to a dead-end is also marked as a dead-end, so as the search progresses more and more sectors get marked as dead-ends and will never get looped back into. I also have the search now moving the start position of the search with each iteration as appropriate, which eliminates a lot of redundant looking back through the incomplete paths as the search goes on. Overall, it's a lot better now. The path length limit is much higher (don't even know what it is) and searches are much more efficient.

This has been a painful process. I often make careless errors, and I have a very small working memory. It's very difficult for me to remember what is going on in a chunk of code that I'm not actually looking at, so I frequently break things and then spend a lot of time trying to understand how I broke it. The best defense is to write code that is extremely modular and well-organized, with a clear understanding of what the purpose and output of each state/function is. This doesn't come naturally to me, but it's absolutely necessary in a difficult project, which this is.

In a difficult project, the challenge is a test of character as well as engineering. What are you going to do when it gets frustrating and it seems like nothing you do will work? Are you going to give up? Are you going to change your goals? Are you going to keep working, carefully and step by step, until you get it right?
1

User is offline   Gambini 

  • 1,290

#54

Quote

In a difficult project, the challenge is a test of character as well as engineering. What are you going to do when it gets frustrating and it seems like nothing you do will work? Are you going to give up? Are you going to change your goals? Are you going to keep working, carefully and step by step, until you get it right?


Personally I have been blessed with a stuborness worth a gold medal. I never give up when things get tough, even at times when itīs no longer worth. It has costed me a few expensive mistakes, but lots of succesful achievements too.

As for your project, today i thought about it and how a reverse progress (something that goes back from the dukebutton or endlevel sector) system may be useful when teh bot gets stuck. I know itīs cheating, but may be a good option for when thereīs no easy way around making progress to the end. Kind of you use your path method both ways and when they meet, you have a clear path to the end.

My maps

eat my shorts
2

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#55

View PostGambini, on 04 October 2017 - 03:49 PM, said:

Personally I have been blessed with a stuborness worth a gold medal. I never give up when things get tough, even at times when itīs no longer worth. It has costed me a few expensive mistakes, but lots of succesful achievements too.


You get the gold for sure -- I'm a bronze medalist in that category at best.

View PostGambini, on 04 October 2017 - 03:49 PM, said:

As for your project, today i thought about it and how a reverse progress (something that goes back from the dukebutton or endlevel sector) system may be useful when teh bot gets stuck. I know itīs cheating, but may be a good option for when thereīs no easy way around making progress to the end. Kind of you use your path method both ways and when they meet, you have a clear path to the end.


Working backwards from a goal would not be cheating -- the bot gets access to all information about the map, just as if the mapper was playing it himself. Cheating would be giving the bot abilities that the player does not have, such as extra jump height, smaller hitbox, etc.

The bot gets stuck for a variety of reasons, but mostly because of incomplete features and flawed code. It's still so unfinished that I can't predict what strategies might be useful later on.

The final stage of the pathing process does involve starting from the goal and working back to the starting sector, but that is only possible because in an earlier stage of the process, various routes were explored and at least one path going all the way from the player to the goal was found.
0

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#56

Fucking locked swing doors.

I'm trying to modify my pathing system so my bot can figure out what is going on with them. So here's the problem: A sector outside the locked door sector can connect directly to the sector beyond the locked door. When this happens, the pathing code thinks it is possible to skip the locked door sector, even though you can't really. So it makes a path through a locked door that the bot can't yet open. Marking the locked door sector as a blocked sector doesn't help, because it isn't on the path at all (because the sector you reach right before the door leads directly to the sector beyond the door -- from the other side, too).

So I tried also marking sectors directly connected to the door sector as blocked, as long as they weren't parents of the door sector. This didn't work either, because the non-parent sector that needed to be blocked technically wasn't connected to the door sector. This gets to the root of the problem: a wall that coordinate-wise is part of the door sector is actually considered part of a different sector that is outside the door sector. So now what I'm trying is looping through ALL the walls in the map to find ones that coordinate-wise are in the door sector, whether they are technically part of that sector or not. Then I check what sectors those walls are linked with, and block those sectors from the path if they are not parents of the door sector.

This worked in one test at least. It's probably going to break things. :angry:
1

User is offline   MYHOUSE.MAP 

  • 508

#57

After you get the nav code down to a decent state, have you thought about "optimizing" how it handles combat? Say, have it so that the AI knows that only one Shrinker blast is required to shrink a foe so that it doesn't waste ammo rapid-firing five rounds into a single Enforcer, like it did in the video you posted earlier? Tell it to prefer the RPG, or even better, the Devastator to clear out Octabrains? Or would that be too much work for too little payoff and possibly cause problems down the line?
0

User is offline   thisbecasper 

  • 1

#58

View PostMYHOUSE.MAP, on 14 October 2017 - 11:56 PM, said:

After you get the nav code down to a decent state, have you thought about "optimizing" how it handles combat? Say, have it so that the AI knows that only one Shrinker blast is required to shrink a foe so that it doesn't waste ammo rapid-firing five rounds into a single Enforcer, like it did in the video you posted earlier? Tell it to prefer the RPG, or even better, the Devastator to clear out Octabrains? Or would that be too much work for too little payoff and possibly cause problems down the line?


He mentioned exactly this, when someone else asked him the same question earlier in the thread. I think it's on the first page :)
EDIT: Found it: "The bot will get better about ammo usage and weapon selection. This may sound strange, but I haven't spent much time on combat because I know it's much easier to code than level completion. I don't want to focus on something easy and put off the more difficult problems that can break the project. So for now, he has the bare minimum combat knowledge to get him through basic combat situations while I try to teach him about how to move through a level." - Trooper Dan

This post has been edited by thisbecasper: 16 October 2017 - 04:57 AM

1

User is online   Hendricks266 

  • EDuke32 Senior Developer
  • 5,686

  #59

I wish I had time to throw my hat in the ring. In school I learned all the necessary data structures and AI techniques to do this effectively and efficiently. Looking forward to seeing your progress.
1

User is offline   Trooper Dan 

  • Duke Plus Developer
  • 2,266

#60



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.
9

Share this topic:


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


All copyrights and trademarks are property of their respective owners. Yes, our forum uses cookies. © 2017 Voidpoint, LLC

Enter your sign in name and password


Sign in options