bulb's Forum Posts

  • 3 posts

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

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

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

  • 3 posts