Sign in to follow this  
ZeHa

Jump'n'Run engine with uneven platforms

Recommended Posts

Hey there, I think you all know Jump'n'Runs like Super Mario, where tiles can easily be spotted because everything is rectangular and every platform is totally plain. Everything is based on a big grid and so on, and it's no big deal to program an engine like that. But maybe you know Earthworm Jim or similar games, where platforms aren't rectangular and box-like anymore. Instead, paths are curvy and uneven, and the characters walk along that curvy path. My first thought about how to do that was this: use a normal tile engine, but give every tile an additional angle and height information, so that when a character walks on that tile, the vertical position of the character would be calculated by taking the tile's Y position + the individual tile height and, depending on the X position of the character and the tile's angle, adding or subtracting the according amount. Also, the angle (representing steepness) could be used to let the character slide down (if steep enough). And also slow him down when he's "climbing". The path of course wouldn't be a real curve, it would still be a little bit edgy, but if a tile has about the same width as the character it shouldn't really matter. Also, in games like Earthworm Jim, the platforms aren't shown directly from the side, the top of it is also shown, so the edgy path wouldn't be noticable I think. That way it should work, I assume, but maybe there's a better or smarter approach. How would you do it / how have you done it?

Share this post


Link to post
Share on other sites
Okay I see, well basically it would be similar but more exact. But I think that way it would be enough to just store a height value for every vertical pixel row. Let's say a tile has 64x64 pixels (and complex platforms would of course be put together by several tiles), then a tile would also have 64 height values stored somewhere which could be immediately accessed depending on where the character is currently standing. Maybe those could also be quantized to only 16 values, should be sufficient.

An advantage compared to my previously explained way would also be that those values would be precalculated instead of being calculated from height and angle each time :)

Thanks for the idea... I think I'll try that :)

Share this post


Link to post
Share on other sites
That is a viable alternative, one which I saw as far back as the Commodore 64 days. its fast and not memory intensicve. But, if you use a complete bitmap rather than just a 2d height map, you can also collide with the bottom and sides, rather than having square bottom and sides and a shaped top.

Share this post


Link to post
Share on other sites
That's true of course... well I think it depends on the type of game. For Worms it's essential of course. For Jump'n'Runs it can be a bit dirtier, but of course there are also platforms that the character should collide with not only from above. Maybe it would be possible to break up tiles into a smaller grid and have each grid field either as an obstacle or as "air". Basically your idea with the 2D bitmap but rasterized, so that I won't have to do too exact calculations (which would waste time because it doesn't have to be that exact).

Then again, this grid would make very "stairy" movements when walking horizontally. Well, I think I'll have to figure it out a bit more... does anyone know the method of those Earthworm Jim-like games (there were lots of them that all seemed to use a very similar engine)? Maybe it's really the bitmap method, but I think they used some trick to minimize CPU time...

Share this post


Link to post
Share on other sites
Well, if I were to go about it, I would allow the level designer to define the "solid" areas using polygons. That way the ground could be any shape, only limited by the processing power, which in nowerdays should be more than enough. I have no idea how it was done in Earthworm Jim though, especially the "digging" level in Earthworm Jim 2 was awesome, where you could use your gun to shoot your way through the ground.

Share this post


Link to post
Share on other sites
I agree with the point about making a lookup table for each of the angles. The trade off is memory (but not that much) for processing power. "MC Kids" for the NES used the lookup table approach, I remember reading one of the developer's articles about it.

Share this post


Link to post
Share on other sites
I'd do it this way:
Use tiles for the look, but not for the collision. The level editor would also have a "collision" editor, in which I would be able to define collision paths. These can be curved, can have different attributes, like only triggering a collision when overlaping from above and can also be generated by the level editor itself if I only needed "per-tile" rectangular collisions.
So for curved tiles, like loopings in sonic, you would just define collision paths and give them a specific attribute, so you engine knows how to handle collisions with a specific path.

Share this post


Link to post
Share on other sites
I started programming today and as a first approach I just used the black and white masks. But for the beginning, I only check from above, so I have 64 values (tile width is 64 pixels) horizontal.

Later I may expand it to the other sides as well, but for now this should be enough.

Thanks for your tips and hints!

Nice greetings
ZeHa

Share this post


Link to post
Share on other sites
Quote:
Original post by ZeHa
I started programming today and as a first approach I just used the black and white masks. But for the beginning, I only check from above, so I have 64 values (tile width is 64 pixels) horizontal.

Later I may expand it to the other sides as well, but for now this should be enough.

Thanks for your tips and hints!

Nice greetings
ZeHa

I've used this approach before (generating 1d heightfields for each tile from black and white masks), and it worked really well. It's light on memory since it's still basically tiled rather than a big image, and it's easy to sync up with the actual tile graphics (a lot of the time I just made the masks directly from the tiles). Plus it's plenty fast too.

One slightly tricky bit to watch out for is walking between tiles - in particular an upward slope which means your character has to walk off the top of one tile and onto the bottom of another. I seem to remember having to check the tile above to see if there was something to step onto rather than just following the height of the current tile.

Share this post


Link to post
Share on other sites
As you stated, another approach commonly seen, is to store a height value per column. This reduces the storage to 16 bytes for a 16x16 tile, and reduces the collision check to an offset add and a '>' or '<' compare. The down side of this is that it only allows collsion with the top part of the path. You could easily expand it to store a upper and lower collision height.

The quantized height values would probably add more in calculations than they would save. And, you would miss the details of a curve, and potentially end up with misaligned heights.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this