- Home /
how do i make level in the foreground and background. like paper Mario the thousand year door
how do i make the level in the foreground and the background, like in paper mario the thousand year door how if you go through a pipe or somn it will take you to the background. i tried putting a tilemap in the background but no matter how far back i put it, i can still interact with it. the only other thing i can think of is turning off the collider of the background while in the foreground and vice verca (however you spell that) please help
Answer by Eno-Khaon · Oct 18, 2021 at 01:49 AM
All the Paper Mario games are 3D, so it's not really comparable as-is. A closer comparison, incidentally, would be Virtual Boy Wario Land, since that game did have a distant background available to play on, but the game itself was entirely 2D.
That said, in both cases, the foreground and background elements were effectively two independent gameplay regions (with more-variable controls schemes in Paper Mario games, as well, when it switches between 3D- and 2D-based movement schemes). Plus, neither of those were using an all-purpose game engine with built-in physics engine designed explicitly for realistic physics interactions (tumbling objects, etc.).
One way to effectively try and replicate that in this case of effectively largely-intersecting environments (without disabling/enabling a ton of colliders, anyway) would be to put foreground elements on a "foreground" layer, background elements a "background" layer, then swap characters between other layers with carefully controller collision groupings.
For example, 6 layers could give you something like:
foreground environment (non-combative stuff, basically)
background environment
foreground player (the player and player's attacks/projectiles)
background player
foreground enemy (enemies and enemy attacks/projectiles)
background enemy
Then, by preventing foreground and background physics objects from colliding with each other, you can still let enemies on the opposing plane attack blindly for aesthetic as desired.
The downside with this approach is that you basically max out at availableLayers / 3
planes to make use of, in case you'd want more than just two (foreground/background). By extension, if you *do* intend to make use of that many gameplay planes, then you'd probably be better off just using that same 6 layers as "active" and "inactive" variants, and changing layers by way of a parent-container per gameplay plane and a script to perform cascading layer changes.
the problem is i use layers to tell when thing damage you like if its on enemy layer it and you touch it you take damage, or to tell if you touched floor and can jump. how can i get around this? maybe use tags instead of layers for those other things?
Going based on the foreground/background variant approach, you could use bitwise operations to set up your comparisons:
if((1 << spikes.layer) & (1 << player.layer) != 0)
{
// Player landed on spikes
}
So, how does that work? Well, let's break it down quickly. Let's say that, for visual-aid-example, the player is on Layer 2 (0-based) and spikes are on Layer 3. Let's throw in another enemy attack on Layer 2 for good measure. Now, the layers themselves are just sequential values (0, 1, 2, 3, etc.), but we need to use them as bit flags (1, 2, 4, 8, etc.), so we shift the number 1's bits left by the layer's ID number. It would look like this in Binary:
Bit shifting:
Take a value (1, in this case)
0001
and shift that single bit to the left:
1 << 0 = 0001
1 << 1 = 0010
1 << 2 = 0100
1 << 3 = 1000
player: (1 << 2) 0100
spikes: (1 << 3) 1000
enemy: (1 << 2) 0100
A Bitwise AND operation (&) compares those individual bits and returns a new integer comprised of any matches. If you compare the player to the spikes and enemy attack, it would look like this:
player X spikes:
0100
& 1000
= 0000 (NO MATCH)
player X enemy:
0100
& 0100
= 0100 (BIT #3 MATCHED)
By that logic, you can compare the current layers of multiple objects. If the result of the AND operation is 0, the layers didn't match, so there's no collision to occur. This is how the collision layer settings work as well, so you can think of this as thinking in the same way.
Of note, this does mean that taking an active/inactive layer approach would become a bit more involved. The player logic wouldn't need to change, but for any interactions on inactive layers, instead you would need some script holding a gameplay layer that you could perform the same logic on (and could then share "layer" data more thoroughly). Then you'd also need to ignore only relevant collisions, and that gets a bit more complicated, really. While it's a passable solution, it's not really tailored to a completely 2D gameplay environment and physics set.
Your answer
![](https://koobas.hobune.stream/wayback/20220613044311im_/https://answers.unity.com/themes/thub/images/avi.jpg)
Follow this Question
Related Questions
Tilemap With Irregular Lines 1 Answer
2D Tilemap Collisions 1 Answer
Some questions about the Tilemap API 1 Answer
Changing background color every time I score 0 Answers
How can I make a large 2d tile map into mesh for easier rendering 1 Answer