Add 'walls' property to inferred/coordinate-driven rooms

[NuSkooler]

This adds a walls property to rooms such that inferred/coordinate-driven rooms can be side-by-side yet still divided by a wall. Doors work as per normal.

The general template for this change was provided in Slack. So far my testing has not shown it to cause any issues or conflicts with the existing implementation.

Example usage:

- id: foo
  title: Foo
  coordinates: [0, -1, 0]
  description: Walls!
  walls: [ "east", "southeast" ]

[ratacat]

oh hell yeah NuSkooler!! This definitely needs to happen.

[azigler]

Similar to #95.

I like this idea but it's unfortunate that the walls are one directional. You have to add the wall to both rooms to create a truly impassable wall. That's rather verbose and error-prone. You could also achieve this with a bundle. As a result, I think we should reconsider this approach.

If you're using the default coordinate system to map your rooms, you currently need to leave empty grid blocks between rooms to represent walls. This results in a map that is bloated because you have individual rooms representing doorways and walls. This also makes the map extremely rigid. For example, let's say you have a building with an inside and outside. Halfway through constructing the interior of the building, you realize that you need to add more rooms inside. In the current setup using grid rooms to represent walls and doors, you would need to convert some exterior rooms into interior rooms and the building would take up more space on the exterior. This would be tedious to do without proper tooling.

Some MU* codebases employ a dig strategy to create non-coordinate maps. These maps are more like webs or trees of rooms that branch and overlap like nodes. This allows you to connect spaces without worrying about its placement and size on a grid. For the example above, you would be able to add the new interior rooms to the building without sacrificing or altering the exterior rooms. From a builder's perspective, you can worry more about the creativity of building a space without being impeded by the physical space it occupies. From a coder's perspective, however, it can be hard or impossible to enforce consistent rules about distance.

For example, in a coordinate system, you could realistically enforce an AoE earthquake spell that does damage to characters in adjacent rooms, radiating out from the caster and doing less damage the further the character is from the caster. However, this would be infeasible in a non-coordinate system. In a coordinate system, you could also allow characters to "phase" through walls until finding an adjacent open room that is x rooms aways. It also allows visualizations of the game world in a proportional way and enables advanced pathfinding across the entire map.

Since core is currently opinionated about using coordinates, I think the best solution for walls is to create tooling for building areas that will allow for easy "wall room" management of a Euclidian map. You could achieve this with CSV instead of YAML.

I discussed this on pinwheel#1 and the topic also broadly discussed in ranviermud#98.

[NuSkooler]

When I have a chance to look at this again, it seems like it would be fairly easy to programmatically apply a wall to "both sides". Personally, I don't think I necessarily agree with the other points above. I think this benefits a lot of users of Ranvier.

With that said, I'm not 100% sure walls should automatically apply to both sides though. Tooling of some sort is essentially necessary for anything more than a "hello world" map.

[azigler]

It would be programmatically straight-forward to add a wall to both rooms, but in the actual room definitions one room would have the wall defined but the other wouldn't, so it might be confusing to maintain. I don't disagree at all that your change would benefit a lot of Ranvier users, I just wonder if it should be achieved via metadata and a bundle. You could use a custom CommandParser to check for walls defined in a room's metadata, for example.

You're definitely right that tooling is essential for anything beyond a starting map!

[NuSkooler]

@azigler It's been quite a while but I'm playing with Ranvier quite a bit again.

The idea of a custom CommandParser is interesting. The issue I see there is the "custom" bit, however. What would work for me would not benefit others. I do agree maintaining walls on "both sides" isn't ideal, and can certainly see that "implied" walls may be weird (or not even supported depending on what the particular user is using for their tooling since there is no standard).

Welcoming ideas!

[nelsonsbrian]

I don't use the coord system and have created the tooling such as dig and buildwalk. I didn't really have a problem making a pathfinding to add the tooling of a 'buildwalk' that connect 2 rooms on an x,y plane together. I'm sure I can use that same logic to do a 'phase through walls' sort of ability. To make such an earthquake skill (which I'll probably have something like that), even without coords, doesn't seem too hard to recurse from target room in all directions.

The only place I use walls are for the map, which just end up being mostly auto defined based on the exits in the room. Like my map would show a wall on the east side if an exit wasn't present. And it would have a wall on the NE side of the room if there was no room that was traversable to the NE via E->N or N->E. So my map is sort of complex, but that's the only place I have to use walls.

For my game, I don't want core inferring walls/exits for me at all. However, there certainly can be games where you would want that for sure. I can only speak to what my game does.