Level design - (Walls, Holes, Moving Platforms)

[tightninja]

Hello Everyone,

I am trying to understand how the wall placement works in the modders tool.

From what I understand:
The base color (dark blue) section is where you CANT go.
The top color (light blue/turqouise) is a platform that player can walk on or through

If they overlap, I assume the dark blue takes precedence?

What about the area between in the "middle of the cube" It seems sometimes the player can walk between the two top and bottom. Other times the player is prevented I am sure I am doing something wrong. I am just trying to figure out how it is implemented in addition to the best practices using fglayer vs background etc. I want to start implementing moving platforms for jumping sections as well.

If there is a post already on this topic in the forums that goes into greater detail that the documentation can someone post a link?

 

[DCurrent]

Hello Everyone,

I am trying to understand how the wall placement works in the modders tool.

From what I understand:
The base color (dark blue) section is where you CANT go.
The top color (light blue/turqouise) is a platform that player can walk on or through

If they overlap, I assume the dark blue takes precedence?

What about the area between in the "middle of the cube" It seems sometimes the player can walk between the two top and bottom. Other times the player is prevented I am sure I am doing something wrong. I am just trying to figure out how it is implemented in addition to the best practices using fglayer vs background etc. I want to start implementing moving platforms for jumping sections as well.

If there is a post already on this topic in the forums that goes into greater detail that the documentation can someone post a link?

@Piccolo is the man to ask about the modders tool, since he built it.

As for layers, fglayer is pretty much always the best. Layers are layers under the hood - the rest is just interface. The bglayers, legacy frontpanel, and water are hardcoded to specific positions, visual effects, and scroll settings. The fglyaer command exposes all of those for you to adjust at will.

The legacy background is still useful though because it will load a 24 bit .png for true color without extra steps, and in general it can be useful as a final backdrop.

DC

 

[Piccolo]

Hello,
Honestly I don't really know, it's actually an OpenBOR issue, even though you used CMT to describe wall components.

From what I recall, you can't "climb" a wall (what you call the middle part), you can only jump on it (even though there might be some funky collision code that let's you climb a wall without jumping under specific conditions). If you want to climb a "wall" without jumping, you have to use basemap instead.

If they overlap, I assume the dark blue takes precedence?

The base rectangle and the top rectangle of a wall always overlap, because they are defined by the same coords.

 

[O Ilusionista]

I am just trying to figure out how it is implemented in addition to the best practices using fglayer vs background etc

Background and fglayer aren't exactly the same thing.
As Damon mentioned, you can use the native background to load 24-bit images (though I honestly only recommend doing so if you really need to). Another use—one I rely on heavily—is utilizing the native "neon" effect to create simple animations within the level.

I generally use the background as a true backdrop, except when I need movement in the layers but not in the "background" itself. Configuring `bgspeed` changes the background's speed (as the name implies), but by using `fglayer`, you gain more control—meaning you can have moving layers while the background remains static (or vice versa) if you swap the background for an `fglayer`.

`fglayer` is extremely useful and offers a great deal of control. The only thing you can't do right now is set X and Y speeds for the background (`bgspeed`/`vbgspeed`) while disabling just one of them, though I know that is in the plans for the future.

I've shared some cool effects you can do by using fglayers here, take a look Backgrounds and inputing them into game

What about the area between in the "middle of the cube" It seems sometimes the player can walk between the two top and bottom. Other times the player is prevented I am sure I am doing something wrong.

The middle of the cube isn't walkable.

If an entity spawns within this area and has the "subject_to_wall" property, two things happen:
- If the wall's height is—unless I'm mistaken—less than 3000, the entity is moved to the top of the wall. In the image below, this corresponds to the teal-colored area.
- If the wall's height exceeds that limit, the entity is instantly removed. It isn't killed (its HP isn't reduced, and it doesn't play a "death" animation); it is obliterated.

That is why you don't see the top of the wall at the back of the scene; no entity is supposed to climb up there. They can only walk on the teal-colored areas.

Note that I am stacking two walls on top of each other to simulate a staircase. I could have done it differently—making the smaller wall exactly the width required for the smaller step, rather than stacking them. However, if you leave even the slightest gap between two walls—even just 1 pixel—the entity will fall between them, because the position is calculated based on the entity's exact pixel location.



In the WALLS tab, there is a setting called "show base only" that displays only the base of the walls. This makes it easier for you to identify the areas blocked by the walls.

(even though there might be some funky collision code that let's you climb a wall without jumping under specific conditions).

If memory serves, up to a certain point, you can move along a wall (climbing up and down) without jumping. But it comes down to almost pixel-perfect precision.