Jump to content

Isometric Gaming Physics


FrancoisSoft
 Share

Recommended Posts

Posted from my website.

The World of Isometric Collision Detection
Isometric gaming is new to me so far. I have actually never created an isometric game. I will be creating a game in the future called the Chronicles of the Bicycle Brothers and this will be isometric. So far I am looking at two games that are isometric. That is:

Super Mario RPG
https://www.francoissoft.com/Images/Super_Mario_RPG.png

and...

Earthbound
https://www.francoissoft.com/Images/Earthbound.png

Both of these games are clearly isometric but it looks like Earthbound is slanted at 30 degrees. It seems that not too many games are isometric. Most games that I have seen that are RPG or adventure are top-down view which is not my preference.

Collision Detection
I am currently interested in collision detection in isometric games. But how to do this? Not sure but I'll try to take a guess. So right now I'm going to look at Earthbound and divide it into bounding boxes.

https://www.francoissoft.com/Images/Isometric_Collision.png

I highlighted some bump maps for some of the collision maps. This includes a bump map that is rotated at 30 degrees. For the normal bump maps we can just handle collision normally. For the rotated bump map we may need to use hill based collision detection. However, this kind of collision detection scenario is too complex. Let's look at something simpler.

Let's look at a tree. If you look at the highlighted tree in the picture you can see that it is a regular box. Pretty easy, right? Yep, but remember if you want your characters to be able to move behind the tree you'll need to break it up into different sprites or have different bounding boxes.

https://www.francoissoft.com/Images/Isometric_Collision_1.png

So in this example we have the tree trunk with the hit box and the top of the tree without it. That way the player can go behind it.

The fence that you can see in the distance is slanted and that can be broken up into "slopes". In some games like Earthbound Zero they did not use slanted hit boxes.

image.png.1375dacb325add39506eb517bbb18bd3.png

image.png.411dc37268e294a86622da013d925c24.png
This happens in Earthbound Zero. You can do this too!

Take a look at the first image with the blue line. I marked the blue line as the slope but fences can be approached from left or right. This means that to properly detect collision on a fence you need to calculate the Y coordinate from each side and maybe make an adjustment to take into account the width of the fence.

Jumping Up and Over Stuff

When you're standing next to a wall, tree, etc. you're normally blocked. That is, you can't go through these things. When jumping in isometric games things change. When you jump you can no go through walls, trees, people, etc. Jumping works by moving in the direction you are jumping, stopping, and falling back to the original location.

Here's an example of how this works:

image.png.2c072ab96b29aabf0c79e875c1eb5b79.png

In this example the bike is trying to jump over the river but has reached it's limit. Now it can only fall in but at this point the fallback must be in a direction perpendicular to the jump. So basically jumping in this scenario works just like in a 2D platform game.

Ok, smarty pants, what about this?

 image.png.0e80f90452f501c999f40dff801ddc54.png

Rules, rules, rules. It seems that jumping will be different in the Y axis than it is in the X axis! Here we need to think. We will need to detect what is in front of us. We have a river, not a wall, so if we reach max height we should just stop and fall in. That is, make the sprite disappear!

In the next case we have hit a wall so, naturally, we should crash into it! Once we hit a wall we go forward until we hit a landing zone like a ledge or ground otherwise we fall back down!

 image.png.d61f707c20ec04ec0bbb987774e0a499.png 

If the jump stops on a wall we fall down again but if it stops on something else like a ledge, ground, roof, etc. we don't need to fall down! This is the importance of checking the sprite type!

image.png.63f558486828b66ac8211dda51289dfb.png

We could super jump and then if we hit a ledge like this one we allow the jump to stop and forgo the fall. A biker that can jump this high has probably drank a case of Mountain Dew!

image.thumb.png.9046dd2a6416aed86039bfad975df9bd.png

What about this case? This is where you jump up a hidden cliff. Because of the nature of isometric graphics, like this one, you should treat the ledge as a wall - at least part of it! If player is mostly inside of ledge, stop. Otherwise, fall back down.

Initiating Fall

When you fall and how is going to be determined largely by direction that the player is going in and what the ledge, wall, roof, etc. will allow.

image.thumb.png.60b13ef0afd6eb641b8785e451622d4d.png

To fall down a ledge or cliff you would look at what direction one would consider falling. In the image above if the player is facing south and moves towards the back of the sprite then the player will fall. Depending on which the direction the sprite is oriented which is indicated by tags would cause a fall. So approaching a ledge from behind would initiate a fall. From the front, a jump!

Closing Words
Still, a lot of research is to be done on isometric games. I am planning to create an isometric game myself but wanted to come up with some proof of concepts.

image.png

image.png

Link to comment
Share on other sites

Have you considered doing your collisions on a dataset that isn't the isometric view?

For example, the isometric world is likely created with tiles (2D) from a dataset (2D map)?  Why not generate a "hit map" (2D top down) at the same time the isometric tiles are parsed?  Then use that exclusively for collision detection and Y displacement (for raised areas).

I have a vague recollection that the original "Marble Madness" (or another old school game) used a chromakey of the isometric view for collisions and physics properties.  A chromakey (where each item has a unique color, thereby representing a unique item identifier) can be useful for pixel specific item selection so may be worth a look.

Link to comment
Share on other sites

4 hours ago, b10b said:

Have you considered doing your collisions on a dataset that isn't the isometric view?

For example, the isometric world is likely created with tiles (2D) from a dataset (2D map)?  Why not generate a "hit map" (2D top down) at the same time the isometric tiles are parsed?  Then use that exclusively for collision detection and Y displacement (for raised areas).

I have a vague recollection that the original "Marble Madness" (or another old school game) used a chromakey of the isometric view for collisions and physics properties.  A chromakey (where each item has a unique color, thereby representing a unique item identifier) can be useful for pixel specific item selection so may be worth a look.

This is interesting. I will look into datasets. I am new at isometric gaming and have not created one yet. Thank you!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...