FrancoisSoft Posted June 28, 2021 Share Posted June 28, 2021 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 and... Earthbound 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. 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. 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. 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: 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? 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! 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! 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! 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. 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. Quote Link to comment Share on other sites More sharing options...
b10b Posted June 28, 2021 Share Posted June 28, 2021 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. Quote Link to comment Share on other sites More sharing options...
FrancoisSoft Posted June 29, 2021 Author Share Posted June 29, 2021 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! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.