Places Code Pros and Cons
-
@Misadventure asked over in Too Much:
Do you happen to have or recall a list of the pros and cons for the setups (for places code) you looked at?
There was actually a big discussion about this a few years back in this other thread, but I'll summarize where I ended up.
TL;DR; - no system is perfect. The main variable is what you think is the main purpose for a places system. For me it's organizational - where is everyone? The spam reduction aspects always caused more hassle than help for me. YMMV. If you see "reducing spam" as the main goal, you might go in a completely different direction.
This is mostly a data dump, but everyone feel free to share other thoughts and other places code alternatives you've seen.
Traditional Pros/Cons
In old-school systems, a player joins a place and uses a special command (usually
tt) that emits only to people at that place.- Keeps chatter to the place, reducing spam for people at other places.
- Requires you to double-pose if you are doing something at the place that would logically also be noticed to the rest of the room. People often forget to do this, reducing opportunities for engagement across places.
- Requires special commands to pose at the place, leading to a lot of messed up poses.
- Getting a cohesive log requires splicing together logs from all the different places.
- GMs can't see what's going down in other places, making it difficult to utilize places in a GMed scene.
Ares Pros/Cons
In Ares, you pose as normal and everyone can see your pose. There's just an informational tag around it, like:
[+ At Table in the Corner +] Faraday falls off her chair.
- Posing is normal; the place name is just extra information.
- In MU clients, it highlights chatter at your place to get your attention. (in web portal you would have to set up a browser highlight manually)
- Everyone can see everything. This is good for logging and GM-ing, but obviously does nothing to reduce spam.
- You can use places more dynamically, such as organizing military teams who are in slightly different areas but can still see/hear each other.
Hybrid Pros/Cons
I also considered a hybrid system where it would use normal pose commands, but still only emit to people at the place.
- It's easy to pose at your place, but posing to the general room then requires special commands. I found this really counter-intuitive.
- Otherwise it's basically the same pros/cons as traditional.
Miscellaneous Considerations
As someone mentioned in the other thread, in traditional/hybrid, you could conceivably allow GMs to join multiple places to monitor things. That just causes some added complexity and potentially confusion (where is their PC really?)
In Ares' web portal, the scene pose output isn't customized per character, and you could conceivably have multiple characters in the same scene browser. This makes filtering output very challenging.
-
@faraday said in Places Code Pros and Cons:
In Ares' web portal, the scene pose output isn't customized per character, and you could conceivably have multiple characters in the same scene browser. This makes filtering output very challenging.
So I was thinking about this before. Let me preface this by saying: I don't actually like the Places system. None of them that I've ever seen. I don't really use them and I think that they ultimately end up with a lot of lost information because it just never makes it into the main scene, and people don't think about that or don't care.
That out of the way -- I think that a system like this could be conceivable for Ares. It could use a similar sort of system to the way Scenes is set up, for the web portal -- a series of tabs, maybe along the top of a scene, one for each of the available places, in the same way that scenes are available on the side.
I don't know how much heavy lifting it would take code-wise to make it feasible, but you could just pose in the place-tab the same way that you do the scene-tab to have it go to the one that it needs to go to.
My two bits. I'll leave the actual feasibility of implementation up to the people who have a clue what they are talking about and know what it would take.
-
I do like places code on games as it allows one to have private rp while in a larger scene and to still be part of that scene. It also can increase a build without increasing the number rooms. Such as one can have a place that is a a kitchen as part of a house build and etc.
Playing on liberation recently without places which is something I am not used to has given me more a look at the pluses of no places and there is one really big plus.
It can lead to a more social everyone is welcome to pose and participate in the roleplaying happening kind of setting. This words best when in small to moderate sized scenes, but in really large scenes I think the cutting back on spam is more valuable.
Liberation does have a spotlight system where one can make a scene on the grid private. Yellow scenes are can join if invited and they can see your ooc talk. Red scenes are invite only and they cannot see your ooc talk. One is allowed to ask to join a yellow scene, but cannot ask to join a red scene.
This works pretty well although I am def way too shy to ask to join a yellow scene and if I see people are in a yellow scene I just walk on by and don't bother to ask!
I like the spotlight system and I admit that times no places has encouraged rp, but still I would like places especially for big scenes.
-
I am a huge fan with the places code that was traditionally installed in things like MIAM.
It is a great way to simulate having a small, private conversation in a larger scene. It allows more activity in a larger group where one person may be leading a meeting, and others are in their places chatting amongst themselves. It keeps the level of chatter down while allowing folks to basically do more RP amongst themselves. I think that's a good thing.
I'd like to think it can be expanded in a way to facilitate GMing, but I haven't thought how we could use existing code to do so.
-
In a small rp, place code is sometimes bad for inclusivity as people already at a place may continue to rp at their table without reaching out "in the main room" as much to new arrivals. Hopefully they will invite the new arrival over, but doesn't always happen.
In a huge rp, place code is sometimes good for inclusivity because you can find people to talk to at "purple fainting couch" or whatever instead of being totally lost among 19 other players, and you can rp without spamming the entire thing (or being spammed by every other thing).
IMO place code is a pain in the ass and huge scenes without place code are a worse pain in the ass.
-
The main complaint I have about places code with traditional mux things and huge scenes is that often times, things said in places are directly relevant to the scene. So you get a lot of people remembering a lot of things said in the scene -- except they n ever make it to the main room, so the log is just this bare bones boring-ass nothing burger whereas all the important conversation happened on the purple fainting couches.
If it would auto-compile all of the places stuff into a final version of the log it'd be the bee's knees, but that's never how I've seen it used, so a lot of really important and/or useful information just disappears into the ether, even though people were expecting it to be saved.
I bet there's a way to make it happen. Coders are smart.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
-
@derp said in Places Code Pros and Cons:
I bet there's a way to make it happen. Coders are smart.
I mean, we may be smart but we can't do much with data that isn't there.
A client log is only as complete as the messages that come to the client. If you're filtering out places talk on the server side and never sending it to the clients, client-side logs can never be complete. You would need some kind of server-side auto-logger. Ares has that, obviously, but many other servers don't as a matter of course.Even with Ares, so many of the scene commands are tied into the scene and not your version of the scene that it would require a huge rearchitecting to try to do per-player filtering. Especially given the alt/GM factors. I just don't see places code being used enough to make it worth the effort, honestly.
-
I was more thinking like the MUX logger object things that just capture the poses in the room in sequentially numbered attributes and then spits out a formatted log at the end. Since it's captured at the room level, what gets sent to the clients is a totally different monster.
Note: this isn't me saying like, oh this should totally be a thing. I'm not. I don't actually like the code and I think it has a host of downsides. Just trying to work through how it could work in theory as a problem-solving practice.
Racism isn't Tinkerbell. It doesn't need you to believe in it for it to exist.
-
@derp said in Places Code Pros and Cons:
I was more thinking like the MUX logger object things that just capture the poses in the room in sequentially numbered attributes and then spits out a formatted log at the end.
Right, that's what I meant by "server-side auto logger." It could be baked into the server hardcode (as in Ares), but it could also be softcode on the other systems. It's just that some (many? most? I don't even know any more) games don't have that, so it's an academic exercise at best.
-
I've never been a fan of places code (or, rather, the 'table talk' commands) because reaching out to the rest of the room required posing twice: once for the 'place', once for the rest of the room. If it was designed to allow someone to section off part of their pose to display publicly, that might help some.
Or a 'spy' command so someone could watch what was happening in one of the other places without communicating directly.
Or the 'table talk' commands could randomly choose a few lines to emit (ambition suggests that 'places' that are closer in proximity would see more of what's happening, but that's a whole other layer of code and planning) - or act like 'mumble', where some parts of a pose are blotted out and the rest displayed to the room as if people were catching a glimpse of something.
-
I'm far more a fan of: "K guys, I'm running a party scene in a very large location. Here's location A, location B, location C, they're close enough to get to and wander in and out of but far enough away from each other that your character wouldn't notice something on the other side of the room. We're just going to agree nobody's going to be screaming bloody murder at this scene cause 20 person scenes aren't the place for that. And go have a one-off breakaway scene using this as backdrop if you wanna." It allows people to meet randomly which is the only real reason for a 20-person party scene and to forge new character ties, but it also allows folks to have a quieter scene where they aren't getting lost. And if the GM does want stuff the whole room can react to, they just sit in those rooms and skim for people falling off tables so they can emit that to every room.
He/Him
-
As a GM, I prefer scenes of no more than 5. If I need a big event, I’ll split the scenes up, knit the events together, and then announce the aftermath.
-
Most muds I played would obscure things said at other places so you'd see something like...
Pulling out her hair-tie, the shoopy shoop at a table in the corner says something.
Or...
Pulling out her hair-tie, the shoopy shoop at a table in the corner says, "... stinky... de... Pie hole..."
And it'd usually be colored differently too. This way eliminated the need to emote twice separately, once for the room and once for the place.
I do like the balance of creativity that a scene takes when you have to emote twice, though.
-
@hobos said in Places Code Pros and Cons:
Pulling out her hair-tie, the shoopy shoop at a table in the corner says, "... stinky... de... Pie hole..."
Those kinds of algorithms have never worked well in my experience. You end up with nonsensical bits highlighted, like:
At the bar, Bob looks at John with narrowed eyes. "You looking at me, punk?" He yelled, "GET OUT! Now, while you have the chance."
comes through as
At the bar, Bob .... with ... He ... at ... while ...
If you wanted any sort of reasonable context, people had to double pose. But they wouldn't, so it was just lost.
At the end of the day, there are a number of potential rationales behind having places code:
- (Organizational) Defining the location to a more granular degree.
- (Organizational) Telling who's where to aid people in breaking up into smaller groups.
- (Focus) Highlighting talk in your place so you can react more easily to stuff that concerns you.
- (Focus) Reducing spam by hiding chatter at other places around the room.
- (Immersion) Obscuring chatter that you probably wouldn't ICly be able to hear.
- (Story) Highlighting where chatter is happening so someone reading the log later can identify the flow of different conversations.
How much you value these aspects will drive what kind of system you prefer. I care nothing about immersion and a lot about story, so that explains my hatred of the automatic "..." systems. Everyone's going to have a different take.
-
I've never seen any system like that. It always distinguishes between action and speech in what I've played, so you'd see something like:
At the bar, Bob looks at John with narrowed eyes. "Y... t me, pu..?" He yelled, "G...O..! Now, ... .... .... ch...."
Or whatever. And if people really wanted to yell, they wouldn't use tabletalk for it, usually.
Anyway, reading your layout of rationales, I think that's very well said.
It's very interesting to me that you would distinguish immersion and story. I've never thought of them as very separate concepts before, but now that I see that, it's enlightening. They're not the same thing. Most systems tend to prioritize one over the other to some degree, even while trying to have both, like being bilingual -- there's going to a first language in most cases.
