Restricting Grid Movement

I'm making a pacman style game, you can take a look at what I've got so far. I'm having movement problems. The player (grid behavior) moves smoothly but can pass through walls. The enemy (ball behavior) can't pass through walls, but often gets stuck on corners.

I've also tried bullet behavior for the enemy (which would work if I wanted to make it work) and 8-direction movement for the player. But I think grid movement will produce the smoothest movement with the least chance to get caught on a wall. (This was what I found most annoying about the original pacman and it didn't have the problem nearly as bad as this does when I try using 8-direction movement. Check it out for yourself.)

So as I said, my real question is how to I restrict my player's movement if he's using grid behavior? I have enough unique background tiles that I can use collision detection to easily determine which directions are passable. The problem is just preventing the character from going in the directions that I know he shouldn't.

edit: by the way, ALL the artwork is final. hope you like it.

I'm not entirely sure without seeing the .cap file, but I just did a quick test, and if I add a tiled background/sprite with a solid attribute, I can't pass through them with the Grid behavior.

I'm not entirely sure without seeing the .cap file, but I just did a quick test, and if I add a tiled background/sprite with a solid attribute, I can't pass through them with the Grid behavior.

That's true, but it appears that only works with keyboard input. If you manually tell the grid object to move spaces, it ignores the Solid attribute:

http://willhostforfood.com/users/deadeye/porkman.cap

For a Pac-Man style game you'd need that manual control because Pac-Man always moves in the last direction pressed.

But after playing with the Grid behavior in this .cap, I don't really think it's suited to a Pac-Man style game anyway... Pac-Man can turn on a dime, and Grid movement won't change direction until the object has reached the grid space it's heading for.

> I'm not entirely sure without seeing the .cap file, but I just did a quick test, and if I add a tiled background/sprite with a solid attribute, I can't pass through them with the Grid behavior.

>

That's true, but it appears that only works with keyboard input. If you manually tell the grid object to move spaces, it ignores the Solid attribute

Hmm, I was just using keyboard input, not manually telling him to move. Here is a cap that demonstrates the grid movement.

But after playing with the Grid behavior in this .cap, I don't really think it's suited to a Pac-Man style game anyway... Pac-Man can turn on a dime, and Grid movement won't change direction until the object has reached the grid space it's heading for.

Actually that's what I like about the grid movement. With pacman turning on a dime it takes some skill to turn at the appropriate time. Maybe that's just part of the challenge of the game. But I wanted a smarter pacman that would wait to turn until the appropriate time. It's much harder to turn with the 8-direction movement, even if you set it to only 4 directions. In the cap above try making the turn drawn in the arrow. With the grid movement it's easy to do at full speed. Now try changing the movement to 8-direction. With the 8-direction movement it's difficult to do the turn without slowing down.

Edit: I forgot to mention that I think with Deadeye's manual input scheme I can do the collision checking that I was talking about and make it all work.

But after playing with the Grid behavior in this .cap, I don't really think it's suited to a Pac-Man style game anyway... Pac-Man can turn on a dime, and Grid movement won't change direction until the object has reached the grid space it's heading for.

Okay now I know what you mean. Pacman should be able to do a 180 turn on a dime. I was thinking just about 90 degree turns. I figured I could grid movement to restrict the 90 degree turns to only when he gets to the actual corner. That way navigating the maze would be smoother. Well that part sort of worked (i.e. didn't work), but the 180 turns are a problem.

Edit: I forgot to mention that I think with Deadeye's manual input scheme I can do the collision checking that I was talking about and make it all work.

It turns out think was the operative word here.

So all in all I think I'm ready to abandon grid movement, but 8 direction movement is still too clunky. I always wind up getting caught on corners. Basically I'm back to square one. Maybe I could use the new custom movement when it comes out and just focus on the ghost movement for now.

Oh, here's the cap for the curious.

Make your Pac-man a bullet.

If Pacman is moving to left, pressing right should turn it instantly, pressing up and down should make it turn at the next intersection or corner.

If Pacman is moving to the right, pressing left should turn it instantly, pressing up and down should make it turn at the next intersection or corner.

If Pacman is moving up, pressing down should turn it instantly, pressing left and right should make it turn at the next intersection or corner.

If Pacman is moving down, pressing up should turn it instantly, pressing left and right should make it turn at the next intersection or corner.

If no keys are pressed when Pacman hits an obstacle (corner, wall), then it would just idle and wait for the input.

Simple, really. All you need is to make Pacman remember the keystroke until it reaches a turning point, then it makes a turn and forgets the stroke.

For ghosts, implement a basic bullet AI that decides where to turn on each intersection/corner based on distance from Pacman. You just change the angle, but keep the speed constant. Make sure they can turn in an instant.

As for corners and intersections, think you'd need to make some sort of detectors. In intersections there is no collision unless you make a detector there. So whenever Pacman or ghosts overlap the detector, the turning event would be initiate.

So maybe I could check (Player.x)%tile_size to see when he's centered on a tile and wait to give the up/down command until then.

Walls should work as detectors, right? I have walls underneath the white lines of the roads.

<img src="http://img48.imageshack.us/img48/2453/screenmd6.png">

Not at my construct comp right now so I can't try anything.

Or you can compare the sprite position with a map of corners/intersections. When it runs into one of those, it performs the turning event (if available for that spot). Remember that actions should depend on the intersection/corner type, for example in a corner you can't go forward or right, just left or back, so it would contain "Stop if no KeyPressed" and "set angle to 90 if KeyPressed" actions, for example. There are several options for each hotspot.

But I'm not sure if the sprite won't just zoom past due to frame skipping...

EDIT: You could simply set it this way... create 1x1 boxes, place them into 'hot spots', add them all to the 'HotSpots' family and then:

 Always
+Sprite.X=HotSpots.X
+Sprite.Y=HotSpots.Y

Okay, I'm running with it.

I just found a bug though and I don't know if I'll be able to go any further before the bugfix.

(posting to tracker now)