Collisions in a maze game

Hi,

I am an absolute Construct beginner, this is my first post.

After I've read the first tutorial and browsed through docs, I wanted to implement a simple maze game. I thought this would be the easiest thing to do, but I have stumbled upon a problem quite early.

I have a player (sprite with 8-dir behaviour) moving around Pacman-like maze (solid tiles), where the player's sprite has the same size as the free cell. The per-pixel collision with a wall works, but the gameplay is crippled, because the sprite can easily stuck with its arms and legs. The natural collision would be the bounding box check, but this does not work at all.

You can see the issue in the screenshot below:

<img src="http://www.b4d4.info/share/scirra-issue1.png">

The player starts moving from the right, hits the wall on the left and cannot go up or down. I've checked the player's position with the debugger, the sprite should have stopped at 64.0 horizontal position, but it never stops at exact 64.0, position varies as low as 64.0004 and as high as 64.2. I expect this to be a problem, because the engine then thinks the bounding box collides with the walls on the upper (moving up) or lower right (moving down). I have seen that with a per-pixel collision the sprite stops at position 63 and something, and a pixel of the sprite is actually drawn on the wall, which is ugly.

The workaround here is to set a collision mask (which I don't know how to, even though I have searched the forum and docs over and over) or have a free cell bigger than a sprite. This gives ugly result, because the player is not "locked" on the wall, it can move around in the empty cell by a pixel or two - the same happens with per-pixel collision (Pacman would look horrible with such solution). Or should I implement custom movement (which I again don't know how to, any pointers would be nice)?

Is it possible that the bounding-box collision has a bug/feature? This could easily be solved by giving a tolerance parameter to the bounding box check.

Thank you,

B.

first off, your char can probably be the cell size. what your gonna need to do is 1: make sure that 8direction has rotation mode set to "NONE", and make sure "direction" is on "4 directions"

your also probably gonna want to set acceleration and deceleration to some arbitrary high value like 10 000 or something. so that controlling the guy into a percision space isnt impossible. And lastly, make sure you create an always event. and set the player characters position to

X: round(.x) 
Y: round(.y)[/code:ncvg55r8]
if im right this should work perfectly for what i think your trying to do.

BUT... i'd say a GRID movement is your best bet here, it looks like your trying to emulate arcade controls in a tile game. and doing this with 8 dir is like caging the behaviour so it wont really work right.
GRID movement, on the other hand is exactly for something like this. try it!
or if thats not good enough, well thats where you make your own using events, and we can help you do that aswell.

If the character is animated, you might want to use a dummy till collision masks are fixed.

Yeepee Quazi, the provided solution worked. The rounding did the trick, the rotation was already set to NONE, otherwise the sprite graphics was rotated, but I like the 8 directions better - in order to quickly change the direction. I also did not change accel/decel yet, will try that later.

Also, is there any more information about these expressions/functions that I can use in actions than on wiki? For example, how could I know to use a round(self.x/y)?

I will certainly like to know how to do the custom movement, please help me out. In the meantime I will also check the grid behaviour.

I did not understand the newt proposal however. Did you mean to create additional sprite just to use it for collision detection?

Much appretiated,

B.

Hey, the grid movement works nicer than 8-dir, because you don't have to be very accurate when changing direction close to the crossroads. However, the player stops moving if I push more than two keys simultaneously, which is undesired if for instance the player is moving very fast and I want to change the direction in next few frames. For example, I am moving left and I know that in a second I will move upwards, so while holding the left key I also push and hold the up key. In the next intersection I will move upwards. Can I do something about it or is the custom movement my only solution?

Hey, the grid movement works nicer than 8-dir, because you don't have to be very accurate when changing direction close to the crossroads. However, the player stops moving if I push more than two keys simultaneously, which is undesired if for instance the player is moving very fast and I want to change the direction in next few frames. For example, I am moving left and I know that in a second I will move upwards, so while holding the left key I also push and hold the up key. In the next intersection I will move upwards. Can I do something about it or is the custom movement my only solution?

hmm well i never really played with grid movement so im not the best person to be telling you if you can do something right now.

about the round(.x/.y) stuff, theres really no way youll know when to do this stuff thats documented, you'll just pick up these things as you play around with construct and try to achieve new things, part of the learning process really.

hmm well when i say custom movement im not talking about the behaviour "custom movement" im talking about writing your own kind of movement script using events.

you need to tell us what exactly your game entails tho to have us help you make one.

I did not understand the newt proposal however. Did you mean to create additional sprite just to use it for collision detection?

B.

Yeap, but the bug that's causing the need for that is fixed in the next build.

Quasi

I think he's using the "avoid solids" feature that's built into the grid behavior.