Gaming Your Way

May contain nuts.

Slopes in a tile based game. The dirty way.

In a recent comment posted here I was asked about the slopes in the current platformer, and I promised I'd go over it, so here it is ( Albiet slightly rushed and with no nice diagrams, deadlines and all that ).

In a tile based engine it's fairly simple to work out where the position of the sprite is in relation to the tile he's standing on. So as you move over a tile you're updating the x position which is obvious enough.
Also usually with map data you have an attribute value / byte for each tile, again if you've worked with tiles you're with me so far.

To simulate a slope easily you have an array of y positions for the sprite. In my case I have 8 values for every sloping tile, as the player moves at 4 pixels per frame, and the tiles are 32px wide, so it's 32/4 = 8 possible positions for every tile on the horizontal.

Let's say our slope looks like this ( In array form )

[0,2,4,6,8,12,14,16];

If we're at position 0 on the x of the tile, ie the left hand side, we read the first value in the slope array, in this case 0, and we decrease the sprites._y by that amount ( Decrease 'cause we're moving him up ), so the next step will make the sprite 2 pixels higher up the screen than he was last move and so on.

Above I mentioned using attributes, this is how I get an offset into the array of slopes ( They're just stored as a 2 dimensional array ). If you didn't use an attribute in the map data, just used the tile number, then you'd need to have an array for every single tile ( Where the vast majority would be flat ), which is a hell of a lot of work for no reason, and a waste of resources.

So again we're stepping on our tile, and it's attribute is 1. We know to look into the slope array at attribute-1 ( Arrays start at 0 ), which gives us our first saved slope value, and from there we can get the correct y position for each step of the way.

Simple as you like, hardly any real cpu overhead, and so far with what I've been working on it seems to cope with any angle I've thrown at it. If you wanted to add more realistic movement ( So the sprite stuggles up a hill, sprints down it ) you could store another array with the players max moving speed for each position and add that to the overal speed.

Squize.

Comments (2) -

  • Daniel 'Viza' Vandali

    11/1/2007 5:17:12 AM |

    Thanks a lot mate! It's great to hear that you could free up some time just for my request. :D

    The post was super basic and really informative, so I had no trouble following it. I'm personally yet to start working with tiles (as my planned game was originally art based, but now it’s getting re-coded to become tile based, and also because I've only now just finished polishing up Bounce ;) ), but I have briefly glanced over TonyPa's tutorials and it seems relatively easy at this point. Though I've not planned for any sloped surfaces in my game, this post has really cleared my knowledge on how you would go about sloped terrain in a tile based environment.

    I can’t wait for future posts on the methods and code underneath the hood of this upcoming platform game; but don't go to too much trouble just for me of course. :)

    Daniel Vandali.

  • Squize

    11/1/2007 2:21:41 PM |

    np mate, hope it's some help ( Some images would have made it clearer, but my time is tighter than a nun ).

    Using this system I was able to drop in a Sonic style bridge in an hour or so which works pretty well. Hopefully I'll do a follow up post and go into a bit of detail with that soon-ish.

Comments are closed