Packman style pawn movement

Development Programming & Scripting Blueprint
1

Hi all, mostly I need some inspiration.

I have a packman game about 90% done.
The biggest issue is emulating PacMan’s movement.

For now, movement works with collision detection via box trace:

The pawn has a collision set to barely fit between labyrinth walls, it can thus move along the pathway, but never move towards a wall (except for intersections).

on tick, I’m running 4 box traces. One in each cardinal direction.
Those are used to determine if a change of direction is possible.

Player input simply changes the desired direction of travel when possible.

This emulates the behavior rather well, but falls into some LOC driven pitfalls.

Basically whenever the pawn is traveling the direction change/box trace detection of a corridor can fail due to the position the pawn has. X505.431, y800 for instance.

To eliminate that I tried moving in %5 increments which works better, but still occasionally fails, and also prevents speeds greater than the value of the modulus.
.

So, Here’s the question:
is there a way to get the trace to happen at different frequency? Something like substep for physics or similar?
I tried changing tick group, but that hasn’t really changed anything.

Is there any other way to achieve the “buffer” effect of a turn happening only when possible except for traces?

I’m using a box trace for commodity really. The corridors don’t have a path or anything that I could align with if I used a linentrace, and they rely on the size of the box trace to allow for the turn to happen at the perfect moment when the pawn is aligned perfectly with the corridor.
again, 90% this works fine. 10% or so you get stuck or can’t make a turn.
you’ll know how important making that turn is when Blinky is behind ya…

2

Hi [USER=“3140864”]MostHost LA[/USER]

Let me know if i get it right,

the problem is that your packman dont always align with the hole in the wall, even for 0.431 and you cant go in there ?
So you tryed to move in smaller step, 5% but sometimes you dont get the “Window” .

You can build an helper behaviour that moves your pacckman in the perfect spot for enter the path,
I think you can handle it better casting 3 rays, one on the left -forward, right-forward , and center-forward (Like arms and nose )
When you check if the pacckman can go in a direction you can get 3 outcomes.
3 Rays are blocked , There is no way
2 Rays are blocked, you are near a path , but not enough
1 ray is blocked, You are really near the path, and i would say that your packman “slide in”
Lets say you are walking right , and the path is down, if i press down i checck the outcomes upper here,
when i am really close and get only 1 ray blocked, i press down, but i want the packman to move Right until my last ray is unblocked, then mhy pacckman go down.

3

To prevent these type of headaches is the reason I prefer to use grid movement for these type of games.

4

I’m doing that with a single box trace. The result wouldn’t change because during the tick, due to movement rate, you get offsync from the underlying “grid”.
meaning if at frame X you are at 125.146 instead of 130 you would never find the correct path to the hole…

Right now I’m thinking the only real viable alternative is to recursively ray-cast.

Assuming the corridor has a hole to the right.
line trace will eventually return a false hit.
let’s assume we are casting from pawn center so its easier to figure out distances.

​​​the instant the trace is false, I can trace perpendicular to the first trace, so as to “map” the hole.
If I can get this second trace to return a distance to the wall, I can then use the information to position the pawn before the turn.
perhaps more accurately, detect when that distance is close enough to half the pawn bounds so as not to look weird when the location is set to be precise before/during the turn.

Seems like it could potentially offer a better result…

@EvilCleric
wouldn’t grid movement require tiled floors?

5

This look good enough no ?
You cast from the middle of the packman and if you find an opening, you cast again perpendicular and find the Left-Right Walls, get the middle distance .
so you can move until reach the middle distance with packman and then , Enter

6

Pacman is usually the one of the first games I do when using a new game engine. If I remember correctly, I didn’t use 4 traces, but only one in the desired direction. If next position is empty or ghost then lerp from current position to position + delta, with a snap in the end for correction. This snapping guaranteed a good alignment for the next mov.

7

@EvilCleric seems like a much cleaner solution.
then again its not like you have any overhead at all from 4 traces vs 1 :stuck_out_tongue:
The game it self is so simple you could run ray tracing on a 1060 and still catch 60fps at 4k… depending on mats.

Anyway.
I’m trying to implement various “evolutions”.
So far removing sweep and managing impact with line trace results is far more accurate.
mostly because it prevents the need from aligning perfectly.

I’ll give your idea a go though. Lerping may be a better solution since I now have a way to get the proper distance with the perpendicular trace idea.

Funny how something so simple has

  1. a miriad ways to achieve it
  2. can actually be quite complicated…

Really making an AAA character was a walk in the park (but a time sink) comparatively.