Actually, I seem to remember that if a summary is set for a room, it will be displayed when you click the room in the area room list, but since providing this is the exception rather than the rule, this isnât always obvious.
How does one set a summary for a room? I donât see it in the help set room attributes or a text field for it in the edit room tab.
Unfortunately, I donât either, but Iâve never owned a public area, either. Iâm assuming either that kind of thing becomes visible once you own a public area, or you have to ask a moderator or builder to set that up. I can only see the results, unfortunately (Check out the White Hearth Inn or The Plum for examples of places with summaries).
I could not find examples of this in either of these areas. The only locations in their area contents lists that have a summary are the sub-areas, such as the second floor and basement of The Plum.
Interesting. I hadnât dug around in the area itself; Iâm mainly thinking of whatâs visible from elsewhere. Maybe itâs set at the area level, somehow.
The light text indicates a sub-area, which does have a desc field for the area locations list. The rooms, in grey text, do not have such a field as far as I can tell.
This particular confusion is part of why I think we ought to separate out sub-areas from rooms. They are mechanically distinct in that you cannot go to an area, so clicking on them should probably do something different (as it already does).
Yes, thatâs true of areas. But rooms have no such field, and that is what the confusion stemmed from. That said, I donât think a short description is the best use of this interaction in either case.
To reiterate, these are the changes that I think would be most flexible:
-
I think areas should be in a separate list (to prevent this confusion) and display their full description page when clicked, as if one were standing in a room in that area.
-
I think rooms should be sorted such that rooms with immediately accessible (and visible) exits are displayed on top in light text, while rooms with no such exit, but within the same area, showed lower in grey text.
-
Upon clicking, it could display the roomâs full description page, including a prominent âGo to this roomâ button up top.
-
Pan the area map to the roomâs location within as the default position for anyone using the nesting tabs to figuratively zoom out.
I agree with some of this.
Not sure Iâm keen on fully replacing the existing area list, but having some more travel-mode options would be useful. Caught myself more than once trying to click on room names to travel around - clarifying which exits exist from the vantage of current room and allowing people to exclusively use only those links might not be a bad thing.
As far as separating sub-areas from rooms however, I disagree with splitting the two. The feature is intended to be a list of all rooms contained within an area, even if some of those rooms are grouped up as a sub-area. Not really all that different from folders and files on a computer. An area list is nothing more than saying these things live in this area and the white vs grey tells you if its a parented sub-area or simply a room.
I feel that this feature should be left alone. Room names of non-subarea rooms are often self explanatory or capable of being adjusted with better room name choices if theyâre not explanatory enough in the first place - if they are part of a more complex sub-area, its simple to put them into one for the sake of gaining a sub-area short desc when appropriate.
The one issue we need to fix with this particular system is that we need about/rules field inheritance from parent areas, something I still need to bring up to Accipiter.
â
However, as far as the topic of splitting things is concerned - I do feel it would be good to split off any nearby exits to a nearby locations sub-section displayed above the rest of the area list. My thoughts for this are that it would make for easy travel should we allow exits to be accessed this way.
Probably also want it to state the name of the room the exit leads to (instead of the usual exit info) with sub-area shown in parenthesis for the sake of notifying users when theyâve changed areas and may need to update their rules knowledge.
For example: â Stororkery Storefront **(Sub-area Place)**âș
â
Considering the idea, remote viewing of rooms may also be undesirable other than nearby locations for the sake of privacy. Area owners may desire privacy to inaccessible areas. if a user canât see an exit, itâs probably best not to let them view into the room they canât otherwise get into, regardless of them knowing it exists somewhere.
Question is, do we simply allow one-click travel or do we make people click twice to unnecessarily view the room first every time? Might get clunky with extra clicks all the time. Having remote room viewing might be best to keep to a small side button (eyeball or something?) or avoided entirely for the sake of simply having clickable travel to nearby locations. I know that functionality wise, Iâd prefer to have single click travel.
Unless weâre letting people see who is in remote rooms and introducing that loss of privacy along with it, Iâm not sure how much value we gain in remote room view - tackling that matter is its own can of worms however. Lots gained by allowing people to find out where people are without having to dash around frantically, but also some loss of privacy if people donât have lockable areas to go with privacy tagged rooms.
In that case, I think another way to do this would be to sort them above rooms, as we generally expect file browsers to do with folders. There really is no way to know the difference, aside from the text color, which means nothing to users who havenât experimented a lot with the interface or building tools and such, since itâs sort of niche and undocumented.
I dig a little bit deeper into what I think this could look like here:
But if areas remain a part of the same list category while adding a third mechanically-distinct list item, we will need a better signal than text color for whether an item describes an accessible room, an inaccessible room, or an area. Perhaps section headers could be inserted in the list for each of nearby locations, sub-areas, and other rooms.
I agree, traveling through the exit on-click and saving the look-through option for a separate button off to the side (like we have for character notes in the awake list) would be a wonderful way to minimize unnecessary clicking. Much better than opening a page and clicking a button up top. I imagine itâs a little less work to implement, too.
My question is whether we should be concerned about the change in behavior; people are currently accustomed to rooms in the area locations list doing nothing but auto-panning the map. How can we make that transition smoother? Or is this something thatâs not much of a concern?
I definitely lean in favor of simply omitting the present characters list when viewing a room remotely. Players already have access to the population of each room in the world, and it sounds like Accipiter intends to add a population heatmap to further advertise that information. I think thatâs a good enough gauge of whether itâs worth visiting a room to see what folks are up to without deprivatizing character locations.
The utility, however, in enabling players to remotely view rooms (and, ideally, areas and sub-areas too) is in permitting folks to explore the world of Wolfery without spamming rooms with intermittent âŠ
KhaterĂn arrived.
KhaterĂn left.
⊠messages. We can mute these and that helps, but I think that I do want to know when people arrive ⊠and intend on staying. So reducing this demographic of ephemeral traffic (people who are probably not interested in getting involved in any incidental scenes anyways), is ideal to that end. It also offers some privacy to folks who donât want to be noticed when all theyâre trying to do is figure out the lay of the land.
It would be good to know how much work Accipiter thinks a remote look function would be, whether or not users would be able to find that functionality if developed and whether or not they would use it instead of simply travelling around directly.
Itâs a nice thought that we could mitigate a small amount of the travel spam, but from my position as staff and having interacted with the rush of new users since launch, I do believe that most new users barely even recognize the area function at the top of the output window, let alone look at it for functionality sake.
It was a real struggle to get a significant amount of the new users to even recognize we had tools to identify areas, let alone rules in them - which lead to the creation of more tutorials and guides to help with education.
â
I feel like a vast majority of that wandering traffic is people actively trying to find people they know in places. If they canât see people in the room list by using remote look, then the adjustment wonât stop them from rushing around endlessly.
Weâre currently lacking a tool for viewing users currently in listed area rooms. We do have a room privacy area flag to utilize for creating anonymous spaces, but at some point in order to kill that particular type of traffic (where people rush through every room) we need a tool/command that allows people to see who is around in a space defined by the area owner which can be customized for the sake of mitigating travel spam in otherwise populated lanes.
At the risk of splitting the thread, ahehâŠ
What if we had a privacy setting that allowed players to display their location to âAllâ, âMutual Watchersâ (or a specialized handshake thing like a friend request) or âNoneâ? It could be displayed under their name/status in the awake list or similarly in their profile to those eligible to see it. No need to search for (most) of your friends if theyâre happy to just passively reveal their location to you.
(Though it occurs to me that join fulfills this just as well. Then I wonder why people go wandering about instead of just asking to be brought along.)
My guess would be â because itâs fun?
1 Like
(Usually because they donât know what theyâre looking for until they find it, I imagine.)
I feel my input in this thread can be benefitial 
I will mainly write why things work the way they do, and my thoughts behind their behavior. Can it be improved? YES! So, just because I had some intial thoughts, it doesnât mean they are the best thoughts.
Mixing of location types
We currently have 2 location types: room & (sub)area
As location goes, the two share similar traits; they have a name, a map position, a population.
This has mainly been the reason for mixing them in the list.
But I admit GUI wise, their difference is far from obvious. I have multiple times gotten the question why some ârooms are whiteâ. So, I am up for improving it!
Purpose of Area page
The area page was created for (roughly) the following purposes:
- Map giving a better sense of you being inside a world
- Map gives a sense of how where you are in relationship to other places.
- To encourage exploring as you can see places in the area
- Show population - to encourage visiting places to see âwhat is going onâ
And that is mainly why the list is created in the way that it is, with the sorting to focus on the most populated places to make it easy to see where things are going on.
Sorting by nearby rooms
@Khat, your suggestions are mainly aimed towards improving point 3 - exploration.
Having the exits in the Room page does indeed work against the exploration aspect of the Area page. Some sort of exit usage would be nice.
Problem
- No destination info available - Because how exits work, I currently donât reveal the destination for exits through the API. One reason why exits doesnât show their destination is because I donât plan for it to always have one single destination. With the coming (in the future) of scripts, exits may or may not take you to the âdefault destinationâ that you configure for the exit.
- Non-area destinations - Exits may lead to rooms not in the area. Or to rooms that belongs to a subarea of the current area.
- One way exists - Exits are one way. But this is a minor issue
Because of this (especially the first and last one), it is not as easy to map a location on the map that you click on, to an exit to use.
This can be mitigated with the idea of the exit linkage that I was talking about. By letting âlinksâ be their own entity that you can add to an area.
However, I would wish to find a way to avoid the âdouble workâ of adding both exits and links in order to bridge the info-gap between rooms and locations.
Room short desc
Maybe we should have short desks for rooms too that you can see when hovering a location pin?
Hmm, or maybe short desc should be a Location property instead of area/room property� Let me think about that
Seeing room desc while not in room
I prefer the idea that you have to be in a place to actually see its description. The same with characters descriptions. While being able to see a room without going there can be convenient, Iâd rather want inconvenient exploration instead 
Kind of like why people use lead/follow instead of summon/join.
Optional character location visibility
From a technical point, the âmutual watchersâ option is far from trivial to achieve, nor would I want it. Such a feature would start leak info about who is watching who, which is something Iâd rather avoid:
âHey! Why canât I see your room, but mrX can see it? You are watching him but not me?!â
However, it would be possible to make a âShow character location for allâ setting.
Did I miss something that you wish my feedback on?
1 Like
This approach makes sense from a categorical standpoint, and since there are some technical hurdles in the way, rooms and sub-areas lack any distinguishing factors in this context; so it sounds like this one belongs in the âlarge effort for insufficient gainâ bin. Maybe when we have access to some of the API changes you intend on making in preparation for Lua scripting and linkages and such, this could be re-approached.
I think this would be a nice little addition, if only to homogenize the listâs behavior. Probably not especially valuable, so whether or not that is simple to implement would definitely weigh heavily on my mind in your shoes.
lead/follow is wonderful, and things like it are definitely one of the factors contributing to the spatiality of MU*s in general. We donât, after all, generally ask our friends in wetspace to travel on our behalf to later offer a teleport, we simply come along with them!
Actually, this came up at some point but it seemed too small to write a whole thread for: Would it be practical to remove the party size cap and instead display group arrivals/departures in one line? Or is this a limitation of how such notices are delivered in the backend?
KhaterĂn arrives.
Buddy arrives together with KhaterĂn.
Chum arrives together with KhaterĂn.
Pal arrives together with KhaterĂn.
Friend arrives together with KhaterĂn.vs.
Regardless, I can see why you want to be careful about incentives and information accessibility. Just a few tweaks can interfere with Wolferyâs illusion of spatiality, especially given modern expectations for omnipresence in apps such as Discord where users can keep tabs on any number of channels at once.
I do think that, for lack of either travel-on-click or look-through features, the area page remains an obscure and inscrutable interface. I cannot, for example, find the Silver Crescent in Doânezo, and I donât know whether that is because the exit is hidden or if Iâve repeatedly walked right past it.
Exit links on the map could help with such things, along with some of the other improvements to the map weâve talked about already in the other thread. Perhaps being able to hide a room or sub-area from the locations list while still being attached to the overarching area could make this a little clearer; if the Silver Crescent is merely rumored in the area description, itâs more of a treasure hunt than a session of confused wandering.
Thatâs a good point; I hadnât considered that. I think an opt-in global setting like that is useful for its own reasons, seeing as folks are unlikely to accept an unsolicited join request from someone theyâve never spoken to before, but had they arrived on their own and initiated an organic scene I would call that the MUCK working as intended.
That doesnât as much address the steady stream of explorers passing by, but it sounds like that is less a problem and more an unavoidable consequence of spatiality. I usually leave arrival/departure toasts on even in high traffic areas, which is, at worst, an overstimulating nuisance that I can just turn off when I need to.
Maybe the toast notifications could be delayed for a few seconds and gagged if they depart within the grace period? Still have a notice in the log and such. That feels like a really comprehensive solution to a not very big deal, though, so 
.
It is partially a limitation.
Can a single grouped list be achieved? Yes
So, why hasnât it?
Simplicityâs sake.
By grouping, I would also need to consider how to do with:
- muted characters - only mute if all of them are muted?
- focus - if one of the followers are focused, what to do with focus colors?
- language - to contruct the travel message, I would need a more advanced syntax, such as the icu-syntax or similar, to support any type of language.
- ⊠and probably some more things
And also, I would need to do a bit of work on the backend. Not a big deal, but still.
So, I went with the simply way and sent a travel event for each! 
But yes. We need to improve Area.
One think you should look at is my suggestion of exit icons, and especially the sentence about giving them a semantical meaning. Maybe this idea can be part of the Area navigation thoughts as well.
The Silver Crescent? A place completely unreachable? Cool!
But⊠yeah. I totally see your point!
1 Like
This is my favorite sentence in this whole discussion, and I canât wait to see what sorts of stuff this makes posssible! 
2 Likes
Looks simple up front, but I imagine there are multiple commands all interacting in the background which arenât being accounted for in this summarization.
Exit travel/arrival/leave text is formatted in a specific way expecting that only the prefixed name will travel, so if we make any changes it will need to consider that.
The logic behind what we see feels to me like the follow and lead commands are processing their own arrival information in addition to the exit usage - trying to ball them all together would probably going to add extra complexity behind the scenes as well Iâm thinking? (accipiter would know best on this one).
There might be an easier way to reduce this down to exit use and then pawning off the follow arrival having them instead to talk to the leader and having the leader output a simplified departure/arrival line on behalf of all successful followers who otherwise silently arrive in the room with them? Iâm not entirely sure if this is as simple as Iâm thinking since the follower would probably have to contact the leader and then the leader would output text according to those responses - maybe even more difficult to juggle for departures than arrivals too? This might be too bulky programming-wise even this way. Dunno, just brainstorming a bit on the idea because it would be nice to clean up at some later date as time allows.
Either way, the overall gains for the extra work feels pretty small overall compared to some of the things we need developed other than small clean-up and polish jobs when we only have the one developer currently.
This could be simplified by doing it this way:
KhaterĂn arrives from the wooden stairs.
Buddy, Chum, Pal, and Friend arrive together with KhaterĂn.
The leader knows who theyâre leading and the server knows to gag the follower arrival messages. This way thereâs no extra processing needed and large parties do not spam the log (rendering larger parties a non-issue; I have hit the cap before)
1 Like