How do I properly align/rotate sprites on a checkboard/grid?

0 favourites
  • 4 posts
From the Asset Store
Snap to visible grid - perfect solution for any game genre
  • I'm having some issues with getting a player-sprite to move/align properly within a checkerboard-style map.

    The player-sprite, which is 60x60px, is within a 60x60px grid, on the background of a checkerboard tilemap, and the player-sprite is supposed to move similar to a chess-piece, but also rotating before moving in a cardinal direction. Think Zelda, but restricted to rotating in place and moving in cardinal directions on a grid.

    My problem is that the player-sprite won't align/snap on the grid-view properly unless I alter it's origin point to be in the top left of the sprite square. This then causes complication when I try to rotate the sprite.

    If I put it in it's default central position, it snaps in between the checkerboard squares of my tilemap which I don't want.

    In addition, I added walls of 60x60 size to serve as 'edges' of the map, but my sprite appears unable to move near them.

    The code I used for the grid movement was copied from one of the other tutorials on the site.

    Long story short:

    • Construct's Grid-view and hand-made checkerboard tilemap grid do not match each other, despite being same size.
    • Player-sprite is having issues with alignment, rotation, and movement on the grid because of above.
    • Sprite also won't move near/between walls for some reason.

    EDIT: Okay, apparently I lack the rep points to link to dropbox, and the forum keeps giving me SQL errors when I try to add an attachment. How do I share my .capx file?

  • Hey Zarhon,

    One approach that might work...

    If the player object stores it's tile coords internally, in private variables, then we can multiply those coords by 60, to get the pixel location of the tile's corner, and then add 30 to get the pixel location of the tile's center.

    If the tile coords are (0,1), the "multiply 60" step converts it to pixel coords (0, 60), but this will be a tile corner, so the "add 30" step converts it to (30,90), which is a tile center.

    Whenever we change the tile coord, we recalculate the player's pixel location in the above fashion.

    This way we can keep the player's hotspot in the center of the sprite, and snap to tile centers instead of corners.

  • Hey Zarhon,

    One approach that might work...

    [stuff]

    Thanks for the advice! After fiddling around with the code in the manner suggested, came up with this code as a solution, with the origin point in dead center of the PC-sprite (pics in link):

    http://imgur.com/DLWfx5H,pAgqenl,cKYtUhS,1oy222T#0[/code:w46z9a1c]
    
    Now, the movement is working as intended (spin into desired direction, then move on grid, with WASD), however, now I need a way for the PC-sprite to be 'blocked' by the 'wall' tiles (see picture below), for which I need to 'detect' the wall tile, whilst still being able to go right into the square next to it (or in between).
    [img="http://i.imgur.com/1oy222T.png"]
    
    I'm also a bit unsure what a good methodology would be to apply the same movement to the AI - pathfinding behavior, or a specific re-work of my existing code?
  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • You could try using the "overlapping at offset" condition of the Sprite object to test to see if it *will* be overlapping a wall if it makes a given move. You can use that information to cancel the move if it would result in overlapping a wall.

    The "overlapping at offset" condition basically ghost moves your object temporarily to a nearby offset, where it checks for an overlap, and afterwards returns the object to it's real location.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)