I’m setting up some layers, and I’m trying to think of what to call this one.
I would use this layer for certain objects (usually invisible) that will block the player/enemies/npcs/etc, but will not block projectiles. I would typically be putting these blockers around ledges so that the player can’t just walk off a ledge, as an invisible wall, but I want things like projectiles to pass through it because it would look weird if a fireball hit a wall of nothing.
I may have more pass through it than just projectiles; off the top of my head I doubt I would want flying enemies to blocked by it, if I wind up adding those to my game. And I may use it in other places beyond just ledges, if I ever come across a situation where I want to block people from walking somewhere. So I’d like something a bit more universal sounding than “ledge block,” but nothing comes to mind.
Just be aware that most gamers hate them. They seem artificial. Personally, I like being able to go anywhere. Maybe add a few death barriers to prevent players from soft locking themselves, but most players hate those too, so make them far out of bounds. There are usually more elegant solutions.
personally, I’d just let my players walk off a cliff. I’d put a death barrier at the bottom to force the player to die, but I wouldn’t prevent you from jumping.
In our game we implemented battlefield type out of bounds. We blur the screen and a timer shows if you do not return to game ar a within 10 seconds you die. Problem is you can run pretty far in 10 seconds so we need invisible walls too
I’ve used the word “Fence” for something that blocks walking, but can be seen and shot through (I imagine it as a chain-link fence). When I came back to it months later, I still knew exactly what my cowFence layer did.
I’ve found it helps to be very specific about what it blocks. MobFence would confuse me about whether it also stopped players. WalkFence is almost good, except sounds like levitation might pass it. NavFence (borrowing from kdgalla) is pretty good, except “nav” sounds like maybe it only interacts with the Unity Nav system. I’d probably go with the ugly plyrAndMobFence.
This is exactly why I’m trying to come up with a good name. I learned in my last project that some names become less clear when you’ve forgotten about them a few months later. And what you said about Nav is exactly what I was thinking.
Fence is good, I might have to use that. I still seem to think though that a fence should block projectiles though, especially since chain link fences aren’t a think is this setting, but wood slat fences would be.
At the moment, I have named this layer “WalkBlock.” It hits most of the check boxes and as a bonus it sounds fun.
I get where you are coming form on that, but it REALLY comes down to the style of game. There are plenty of examples where people would HATE the game if they could just walk right off any edge.
The less platforming is important to your game, the more you’d want invisible walls on your ledges. In this game you won’t be able to jump or climb at all, only walk. It would be extremely frustrating to accidentally fall of a ledge and die or lose progress.
I just throw in a set of definitions in a .txt file somewhere. While self documenting code is all well and good, sometimes its easier to just write yourself a reminder.
In our game we have a rigidbody on the player called Anchor, this ghosts the player and makes sure he can not move were not possible (VR game). So we call our layer AnchorCollidable.
On the documentation part in the struct/enum that holds your layers you can comment the layers. This is one of few places we have comments in our code
Historically self-documenting code became popular because that didn’t work. No one read the notes, often not even the in-line comments. This was back when BASIC programs used AA and AB for variable names with only so-so name-completion even if you were allowed longer. Things like const float PLAY_TEST_TWEAK=0.023f; x+=PLAY_TEST_TWEAK; got attention when x+=0.023f; // a tweak through playtesting didn’t. Plus, written out comments depend on coders’ technical writing skill, which is usually poor.
