Creating AI using Table Collision

LiquidGameworks

Yo!
I have been working on this the last couple days, haven't been able to make a fully working version, and ran out of ideas.

The basic idea:

Using the table collision detection system proposed by Utopian (you guys are great), I want to create an AI actor that will detect if it can no longer proceed on its path. If it collides, it randomly chooses to rotate left or right, and continues checking its position. If its open, it moves. If its blocked, it checks the next position.

I was able to make it sort of work, except that it would sometimes confuse its location and actually occupy a spot that it shouldn't be able to occupy. (In testing, i ignored the random aspect). Essentially, I had my actor check its next occupiable space, and if it was false, it would rotate 90 degrees, and check again. It would travel around my map pretty well, except occasionally the checking would get choked up, and it'd start doing square shaped movements through walls.

Any insights would be greatly appreciated!

LiquidGameworks

Here's a vid showing what's currently happening. The block is only supposed to take right turns by design, but it gets confused, as you see. The display text shows the actors current self.rotation. I used that to determine which space it was checking for true/false feedback.

tatiang

Is there a reason you're using rotation instead of move/interpolate/change attribute? When I created a maze/dungeon game, I checked surrounding directions for true/false to see if I could move that way and then just moved the block to the next square.

LiquidGameworks

I should specify, I'm changing the self.rotation attribute. I did this so my block would know which square to check. May I ask what your process was?

tatiang

I'm assuming then that you're rotating the block and having it check the direction it's facing? What I did was to have the block check all four directions (n, s, w, e), like this:



PlayerX and PlayerY are actually the row and column numbers not the pixel positions of the block. I set a bunch of booleans for possible movement (game.West+0, game.North+0, etc.) but there is probably a cleaner way to do that.

So for example, if the block is at a certain location (row, column) and the table looks like this:
1 0 1
1 0 1
0 0 1
Then the block (which is always the center 0 location) can go up/north or left/west.

I didn't use rotation.

LiquidGameworks

I'm sorry, I'm being a little dense here. Then otherwise what? Is that where you flipped possible movement booleans?

By the way, I really appreciate this help.

Edit: I'm just now seeing the image block. Did you just add that?

LiquidGameworks

Okay, I may come back and have more questions, but you've given me a lot to work with. I'm going to see if I can't get this all sorted. Thanks again!

tatiang

I'm happy to provide my template, but the reason I haven't yet is because it's a murky build... it's for a 3D maze adventure game that I've just started playing around with. So it's a bit of a mess to be able to share it, but if you need to see it, I can clean it up (a little) and give you a link.

LiquidGameworks

I don't think I'll need it quite yet. So I have it set up now that it can detect all sides every .1. I've also set up the first movement to confirm its correctly detecting. So far so good. Now, when you say you had a boolean system set up, do you mean you have a rule for all of the 16 possible combinations? It sounds like you're doing this as the user, so a combination of N is true and Up is pressed, move self position y.

I'm trying to set mine up as an AI. At the very least, the first tip about checking all directions was immensely helpful.

tatiang

Yes, mine is a first-person maze so the player actually presses a key. But I would think it would be similar to set up AI. I have a boolean for each of four directions because I limit movement to NSWE. Technically, I have 8 booleans because I draw the maze around the player in 3D based on what you should be able to see/not see. But as far as actual movement is concerned, there are 8 (why 16?) possible directions, so you'd need 8 booleans. But I would think with AI you wouldn't need the booleans because you can just move the block if the direction is open. But again, I'm not sure what you intended.

tatiang

Here's the file in its very rough form. If you look at the "Control" actor, you'll see all the movement checks. Again, it's not in template form and I haven't really annotated anything with notes yet, but feel free to check it out: [will repost link when updated].

LiquidGameworks

I was saying 16, because of the total combinations of 4 directions. For instance, N=True SEW=F, N= True South = True, EW=False. But I'm hoping that's not necessary. By the way, when this all gets settled out and I have a working template, I'll send it over to ya. I'm trying to make a "bomber man" type game, so need baddies to move within the same maze context as the player.

I'm curious, where do you get 8 directions? I would think 3D (incorporating the z axis) would only have 6? For mine, there is no cross directional (no SE, NW). THough I'm still having a hell of a time coming up with the logic.

In bomberman, or pacman, or whatever, the enemy follows the maze and turns when it has to. My problem is when more than one direction is open... If two directions are open, I don't want the baddie to get stuck in a loop. However, as I'm typing this, I realize Pacman may actually be a searchable topic, with possible templates out there.

tatiang

Yes, there are pacman templates available. I get 8 directions because if I'm a block in the maze and my maze looks like this:

1 2 3
4 B 5
6 7 8

With the numbers being possible directions and the B being the block, I can move one of eight directions, NW N NE W E SW S or SE. (In my game, you're limited to N, W, E, or S, so four directions). If I replace the numbers with boolean values (1 or 0), it looks something like this:

1 0 1
1 B 0
1 1 1

In that case, I can move N or E.

LiquidGameworks

I'm getting close @tatiang! I managed to get it to work with no collision rules at all, just tables. This keeps it from doing the weird stutter bug when an enemy touches multiple walls. I've also managed to get it so that it won't easily be forced into a pacing holding pattern.

Things to still do:

1) Smooth movement: because the table and the directional sense utilize a grid pattern, smooth movements don't seem to work. I've tried move, acc, interp using both self.position and next.position (the whole number associated with grid). For now, its grid movement.

2) Now that I have made it so the enemy can never be stopped, I'm going to try to enter logic that'll allow it to change directions at intersections, even if it isn't stopped.

@tatiang You've been a big help, as the multi directional sensing is a huge part of this. Want me to package this up and send you a copy?

tatiang

Looks good! Sure, I'd like to see the game file. I might be able to offer a suggestion for intersection detection after I see how you have it set up.

LiquidGameworks

I have it set up! Surprisingly, it was rather easy and is nearly totally random without inappropriate pacing. I tried to write some notes in there, but we'll see if they're recognizable.

I'll be sending a dropbox link to your pm here in a minute. Again, thanks for the help!

GLGAMES

woah looks good maybe i can even use that for my own maze game :P

Though my game is moving the whole grid instead of the actor. I just dumb the actor in the middle of the maze and setup 4 limits in 4 direction that are contrained to the next possible grid in the four direction so i can only move if limit is false in that particular direction.