Danny:              Welcome mixers, corpies, judges and all around bakas to the Titans of Text podcast. We are your hosts Danny "Austerity" Nissenfeld..

Eric:               and Eric Oestrich

Danny:              and we have with us today the one and only Johnny, the veritable Aeacus of the text gaming world.

Danny:              Johnny comes to us from the epic cyberpunk roleplaying MOO Sindome. We're going to talk about the rise of Sindome. What makes it unique, what has contributed to its longevity and the ins and outs of fostering and maintaining an RPI style mud. So welcome to you Johnny.

Johnny:             Hey, thanks for having me guys.

Eric:               All right, so let's talk about life in the dome. Take us through Sindome and how it got its start up through today.

Johnny:             Well, the birth of Sindome sort of starts with an unsatisfied experience on another game. Back in the day, gosh, maybe 97 or 96, I started playing cybersphere. I had gotten into chat rooms online and one of the chat rooms I was in, uh, was sort of trying to do roleplaying and I had done a lot of tabletop back in high school. I sort of missed having that sort of connection and so I was trying to find something to reinvigorate that. I had kind of grown frustrated with the plethora of fantasy stuff that was out there, and somehow I found myself on cybersphere. It was pretty exciting at first, something new, the cyberware aspect of it, the corporate malfeasance, I hadn't sort of formed my, philosophical thinking on things yet at that point, but I think sort of it emerged over the years. But with Sindome, we were frustrated with the lack of support for roleplaying on cybersphere.

Johnny:             It was more hack and slash it was very consequential and those who had the power just obliterated people who they didn't like. You could invest a lot of time in crafting your character only to have somebody just wipe it out because they're trolling basically. And the admins weren't really doing much because well, we felt that they had various reasons. Some people felt that there was the favoritism angle that a lot of people tend to gravitate towards with muds. Some of them went off and they started their own game. This was primarily Bane and his brother at the time that was, that was his name on Sindome and they started it up. They didn't really know what they were doing and they didn't really have a direction, but they wanted to do cyberpunk better and they wanted to make roleplaying the primary focus.

Johnny:             Unfortunately there was some sort of disagreement between Bane and his brother and there was a big falling out and well I guess people weren't exactly mature and his brother deleted a large amount of stuff that had been done in the past couple of months and so they found themselves kind of taking a step back and there was a whole lot of trust issues going around at the time. I got brought on through a friend of theirs who heard that I had some programming skills. I didn't have any experience with MOO, so I got some direction from Dakin and Ogun back in the day. They've had spots on other places, lambda and whatnot. And so they were able to teach me some of the core basics of how MOO object programming works. And over the course of the next year I was sort of given more responsibility bit by bit as others weren't able to step up.

Johnny:             This eventually got to the point where Bane, I believe he was unemployed or something happened and he wasn't going to be able to be hosting the server at home because he couldn't pay for his Internet. I happened to be enlisted in the marines at the time and I was the webmaster cause we still had those back then of the 29 palms base website. And we had a directive from the headquarters of Marine Corps to get everybody online. So I had extra servers and hardware and whatnot that was kind of sitting around, uh, just to be there as cold standby. And so I sort of put this to use as a host for Sindome because I was the steward and sort of the host person because I had the ball, I sort of ran with it. I took charge where there were absences in leadership and started making decisions for the direction of the game, sort of giving us some focus. We didn't always agree with what the direction should be and there were, there were other staff that nominally had equal rank, but because I was arch at the time that my word would be the final word.

Johnny:             Since then I've tried to change how I do things. In 2009, I decided to relinquish the sort of dictatorial control of things. We implemented a voting system where you can have up to three votes. I have a tiebreaker vote that only comes into play if there is a tie, but individual admins, they can, they can earn up to three votes. If you are directly contributing day to day inside of a 30 day window, you get a vote of contribution and that's open to anyone who is a higher than a support GM. So they get a vote of contribution. Once they're an admin for two years, they get a vote of experience. And if they ever attain a bilited title, like a head GM, head builder had coder and there's a couple of other ones, uh, you also get a vote of responsibility because you are responsible for determining direction of things.

Johnny:             So you have to have a say from that angle. So they get up at three votes and we vote on the direction of the game. We vote on banning people. We vote on rules, changes we vote on, on significant feature changes. Like when I think we voted when we implemented the cap on how much experience you could earn so that more democratic than it would be otherwise. It's still not something where we let the players vote because there's whole lot of people that would show up, but just want to ruin things if we did that I think. I'd say the next big step in our evolution came a couple of years later I had learned how to do things in node and our old website probably hadn't changed since 1998. It had grown a few new features here and there, but it was a pretty standard static html site, backed by PERL and had a few PHP elements here and there.

Johnny:             So I converted everything over to node. Our website at this point, well in 2012, uh, became a node app, um, that's backed by static files that are actually published by the MOO itself. So our MOO is our CRM for our website content, but at the same time, the MOO is not directly the database backing the website. So traffic on the website really can't affect the performance of the MOO itself. I wrote the web client and between the web client and the significant SEO changes that we made to the site as part of doing the whole relaunch, we started to see a big uptick in our growth. Our SEO ranking took us to the home page of search results when you were searching for cyberpunk RPG at the time. And at this point we've been Sindome for 22 years. Oh, it'd be 22 years, I think in September.

Johnny:             Um, we, we've sort of have a, a cap on how far we can go right now though. Somewhere around 20, 35 we expect to start running into datetime issues because we are only 32 bit and we're using Unix epoch time. So hopefully we move off MOO maybe to javascript or somebody figures out how to give a 64 bit numbers and MOO.

Danny:              It sounds going from 32 to 64 bits, it sounds pretty daunting given how much code you guys have got around.

Johnny:             Yeah, there's a lot of it these days. I have forgotten probably 50% of what I've written over the years that we'll find somebody. I'll mention, you know, oh, why don't we implement this? And somebody will start working on it and then inevitably somebody does a search to find that thing that somebody is working on and we'll see the thing they're working on and something somebody else created before that and maybe even something somebody else created before that and they all have some level of completed functionality.

Johnny:             There's so much to do that we have to focus where people want us to focus,where they're, they're telling us where they're directing us and sometimes they're not. They're speaking out of both sides of their mouth where they're telling us one thing and their actions are showing us another. The other part of that is that we need to work on things that bring us joy. Administering the mud is really unthankful when you have a player base that is kind of established and demanding. There's a lot of things you're not going to be able to change to do things your way because things are established because the community is set up in a certain way, but then you're going to have all, you're going to have push from people at the same time and you get a lot of people that come at you upset when they get lost. Oh my God. People get so passionate. People get very emotionally wrapped up in their characters and when something unfortunate happens to them, they can take it really hard. And since Sindome is sort of a series of unfortunate events, some people don't react well to that and they flame out, they have a short character life and they go away, send them. Really isn't for everybody. It is a harsh world. It's not often filled with positive events that can kind of be hard on gamers sometimes.

Eric:               All right, so we've, we've mentioned that syndrome is a MOO and is an RPI. Could you give us a brief description of what makes a MOO different from a traditional mud and what it means to be RPI?

Johnny:             Sure. I can, I can sort of approach it from what I understand, I've, I've never really built any other kind of of mud environment. There's a C kernel that is compiled and this provides you with the, the new executable. Um, and you start this up with a database of some kind and we talk about a database. It's a, it's a file in a, in a particular format for the MOO. And so you can start with a minimal database that has pretty much no objects, no ability to do much of anything except use a single command called .program. Um, and it'll let you create from scratch what you want to create. You could also start from established databases like Lambda MOO, I thought there's a Gamma, there's a gamma MOO. There's also other forms of the MOO kernel where they've compiled different kinds of features and there's one that's called stunt that provides a level of functionality probably significantly better than what we're running.

Johnny:             We're running I believe on lambda MOO 1.8.3 which is something we got way back in 1997 and we've built on it from there. There's been a few things that have been ported in, um, here and there and we've compiled additional features into the MOO ourselves. Um, but for the most part we're still that old Lambda MOO. And so it's a self contained database that has an object hierarchy. Everything inherits from one object or in another, and the parent objects provide functionality that that is expressed through the instances of those objects. And then the object can become a parent for another object. It's not, that's not like classes and instantiation of those classes. You can't have that parent class in certain contexts according to the programming language. It doesn't really work that way and move. You have to artificially implement those sorts of limitations yourself to check and see if an object has children objects or just see if one of the object's flags is fertile.

Johnny:             That's what the MOO provides for that sort of thing. Um, everything is done through this object model. Players are objects, the NPCs are objects and, and the commands are, are functions on these objects that have certain kinds of, prepositions that are able to be used with them. And of course these commands are verbs as they're called in MOO parlance. They can call other verbs. And so this builds on that model and you end up with libraries of utility objects that provide various forms of functionality. We do all the programming for MOO from within the MOO in real time as the game is persistent and going on. So, uh, we sort of use the analogy that Sindome is a semi truck that's rolling down the freeway at like 80 miles an hour, and we're changing tires on it in the process.

Danny:              So it's a, it's mad max fury road then.

Johnny:             Definitely, and sometimes it feels that way because you break the wrong thing and, and you start getting errors and, and alert channels and the players start complaining. And there's been times where the problems have been so bad that I've kicked everybody off so that there's less noise stopping me from getting to the problem and fixing it.

Danny:              Of course. Uh, and so how do you, how do you make MOO so there's a lot of code. You're adding a lot of, a lot of mechanics and other things, and in the code in the data with verbs and adjectives and other MOO things. So how do you make that work for you in your more roleplay focused game design?

Johnny:             We've got some interesting mechanics. Um, probably the one that throws people the most because they don't even, they may not even realize it if they're not reading the messages that are coming up and warning them. When you say something in a room in most places you would assume that the people in that room will see what you said but that is not at all how it works in syndrome. If the people that you want to talk to aren't paying attention to you and are actively paying attention to other people, if you don't particularly address them, they may not hear what you said. So people get kind of, I dunno, it's, it's certain personality types maybe that um, they need to understand that somebody is going to hear them when they say something aand this can really bother them sometimes.

Johnny:             When we first implemented it way back in like 1999 or so, we already had a small established community and there was a lot of push back against it back then and it took a lot of education to, and we sort of refined our help docs around it. Okay. A lot. Yeah. At the end of the day, if you don't overthink it, it works just fine. If you use the to command to talk to somebody, it automatically handles the addressing and all that for you. They will see what you said. But it's when people want to use things like poses and emotes that uh, they're not sure whether somebody is going to definitely hear them, but we have ways that you can raise your voice and then it's expressed in bold and things like that where we really try and give you a lot of different ways to communicate with people.

Johnny:             There's phones, there's radios, there's a brain implant that lets you send thoughts to the whole city. There's, there's 24/7 advertising in the world of syndrome. There's brain ads, there's TV ads, there's ads on the computers. It's a very corporate world. It's all, it's all for the, the, the RP, right? You've got this perception system whether or not you're going to see things, whether or not you're going to hear things, um, sounds can carry outside of the current location. Disguise is, is a really big to-do. We've got a growing system of, of disguise stuff. We just recently added makeup and wigs to that. The other part is we, we try and pull back a little bit on, uh, the mechanical aspect of things. We encourage our players, you know, not to just outright kill somebody, but to give them a moment after they beat the crap out of them to, to, uh, give them a moment to have the RP to explain why they just assaulted them to give them something to go on for the revenge aspect if they're going to live and know who killed them.

Johnny:             We require a history that requires certain bits of information, but we don't require the player to have that before they can start actually role playing with other characters in the game. They can sort of figure out their character inthose first few hours and the first day, the fact that we give people heart palpitations when they're being chased or the fact that they have legitimate fear for their character after they log off and they're not sure if they locked the door to their apartment. It's an OCD joke. Did I lock my apartment door?

Danny:              That does sound pretty exciting. So you want to foster all this rp between the players, and with the world itself. Uh, what, what sort of mechanisms in, in the MOO itself, uh, does the staff have that they can leverage to foster these ongoing stories among the players?

Johnny:             Probably the most important system we have is our notes system. Um, we encourage the players to leave us notes and these notes are only visible by the player and the GMs. No other player can see them. Our staff have directions around what sort of interactions require them to leave notes from their point of view. And these notes are only visible by other admin. There's a lot of communication between the staff as far as what PR, what plot direction somebody may be on or whether or not someone has had a run of bad experiences and you know, they're due for a bit of positive that we can more directly give them. Um, because they're, a lot of stuff is determined by the system. Um, whether or not they're going to be successful in combat, get away, things like that but there is a lot of room for the GMs to make determinations as far as, whether they're going to give somebody a chance when they've made a mistake to another, another character, whether they get warnings, um, what the consequences are for betrayal, whether or not somebody is going to get hired or fired, uh, at, at jobs because, uh, employment is an aspect of, your character's life in Sindome employment and lodging and just sort of living your day to day life are our regular normal. The other bits. Um, we see a lot of what goes on throughout the game through extensive channels. Anytime somebody makes a phone call, we know what numbers calling, what number, who's talking. Um, we can see if somebodys shouting in the background on that phone call, radios every, every thought that goes across the, the what we call the secure identification ship network or sick for short. It provides both identity and the ability to communicate directly to other people for a nominal fee. And so these can be seen by the staff and we have the ability to send out messages on that same network from completely fake characters.

Johnny:             Uh, these things are automatically triggered to happen on their own end. We make them happen more directly and we can choose to, uh, have the system come up with the name of the person that's saying something or what it is they're saying and give them a random name. And through these various means, uh, they're, they're able to keep tabs on what's going on. And then the other big part is that Sindome does hand puppeting of our non-player characters. Not all of them, but not every interaction. You often deal with a bar tender, you deal with a merchant, you a complete delivery tasks, things like that. Um, those are going to be automated. But if you walk up to a character and you ask it a question, we're going to see that on a channel. And if somebody is in a capacity to puppet that character or if you have made a previous request to interact with a puppet, a GM, we'll, we'll sort of jump behind that NPC and be that character.

Speaker 1:          And we have information what we call facts. I'm on every NPC so that the gms have the information they need in order to portray the characters the same way. Now I have to admit this is imperfect. Not every GM plays the same characters the same way and sometimes one GM will shoot down an idea that another GM has previously indicated might be a good idea. This incongruity is not something we are proud of. It's not our best aspect it's something we are constantly working to eliminate the pain points of. And so that's why the notes and, and the facts and just general communication are so important. And to continue that point of communication, we don't just monitor the, the game from while we're connected to the game.

Johnny:             All our channels are also connected to our slack system. We have a for-pay slack system that a lot of stuff gets. He gets into. And because we, because it's a for-pay slack system, we can search it. We have an archive for all, all time as far as we're concerned. So we can see what happened last week, last month in certain channels and understand what's going on in real time. We've also got bi-directional functionality and that we can type a command in slack on a channel and a message will go to that channel in the MOO. So if I'm with my family at the park and a GM needs to ask a question about something they can do so and I can respond and everybody stays in better communication because of this.

Danny:              So speaking of eliminating pain points for your mud, uh, we're going to take a short break so I can relay a few words on behalf of one of our many sponsors for the podcast. The MUD Coders Guild. Are you or would you like to run your own mud? Are you looking for better advice than "Why Bother"? Point Your Web browser at slack.muddcoders.com. The MUD Coders Guild: when you ask why we will bother.

Danny:              Okay. Uh, you know, speaking also another segway about advice on running muds. Do you have any on growing your player base and maintaining and fostering a sense of community between them?

Johnny:             My, my other half, some might call my better half Slither. He's focused a lot on community support. We've recently done some pretty extensive revisions to our help. Um, brought everything in line with the sort of standard in our helps, reviewed all the documents. We make youtube videos that walk players through various aspects of playing the game, creating their character, that sort of thing. And we've learned that these have become very popular. He's even made some videos for MOO programming. So if anyone out there is interested in one day coding on Sindome, you can look up the MOO programming videos. The town halls are a big deal. Twice a year we hold a meeting with the player base where we go over, um, the details of the community. Since 2017 we've operated as an incorporated social club and so we hold regular meetings, we inform them of the status of the club.

Johnny:             We'll inform them of the budget of the new features that have been added, significant bug fixes. And then we open it up for discussion from a questions from the community. Uh, this'll probably be a three hour, three, four hour long process. And we do this twice a year. We'll have another one up probably in June. This is a big time for players to get their questions answered. Uh, we also hold office hours occasionally where players can just, you know, get some one on one time with somebody like Slither and get their questions heard in a more private setting so that, so that the admin can, can speak with them at a sort of different level. We take feedback about issues all the time. We have an extensive bug system and we're always trying to work on what the community wants us to work on.

Johnny:             If players are saying, hey, we want to do more stuff with the rigging skill, we'll do more work with the rigging skill. The issue is trying to figure out where the majority of the focus needs to be. The biggest thing is listening to the players. You're not always going to be able to give them what they're looking for to, to implement things that they want or change policies completely how they would like. But if you're being honest and truly listening, it shows you tell them your reasons. You help them understand your point of view because there's a really opaque wall around your actions and the consequences that ends up being on the players. A lot of times they have to have to blame somebody because you got to have some bad guy and so the person who ends up being the one they interact with the most ends up taking that.

Johnny:             You got to make things a little easier at the beginning. If the, if the learning curve is too steep you're going to find that people are gonna fall off real fast. If you give them little bits at a time, they can, they sort of have to take the, to take their steps and what not. It works better. Simple little things can trip people up to how they have to name their character or whether something is broken in the entry process. Having unit tests around some of your core functionality, is pretty key. I think there was a time where we went for like a month without the ability for players to sign up and we didn't even know. So obviously that's going to hurt your ability to grow, but just be there for your players. Sometimes I just chit chat on the OOC chat channel and that's probably the most interaction I might have that day because I'm just so busy with other stuff. I think it just shows the community that you're there, that you're part of the community and and you're, you're in the, in there with them on things.

Johnny:             At least that's how I do it because I don't play the game. Some of our staff, most of our staff, do play the game because I've been told repeatedly, even though I would like if our staff didn't play the game, I think it would be healthier for the staff-community relationship that our staff, they need to have the ability to play the game too because it is such a fun game for people and that's part of why they want to contribute to this thing. They want to give back to what they have fun with. So if you take out the ability for them to have fun, then you may not have as many or as good as people. And it's already hard enough to keep staff on something like this anyways because it can be very thankless, which is why we have support GMs. Support GM is something where a player, um, decides that they want to help out for a little bit.

Johnny:             And for, I think it's a three month term, maybe three, maybe three, six months, I forgot. They are a GM who helps out with a lot of the immediate contact points. So that's checking grid mails, making sure NPCs have resources that they need to have. Just sort of helping to connect the dots between the game masters who we have a few of and the players we have a lot of. And because there is a short term thing, they're gonna recycle back in as a player, we put restrictions on what they can do as far as their player all while they're an admin. And then even after they go back, there's restrictions on them doing perma-kills for a period of time, because they have a certain level of knowledge.

Eric:               All right. So are there, are there any ways that you, make Sindome more accessible to differently abled communities?

Johnny:             Surprisingly, yes. Back in, in 2009, we had our first blind player, sort of show up and say, Hey, I'm, I'm blind. Is there anything that I can do to make this a little better experience for me? And that's why we didn't have anything. So we sort of figured out, with that individual, what were some things that we could, we could do. We added, uh, the ability for a player to put a symbol before words in a description that somebody can look at. Because if you look at one of the syndrome descriptions, you'll see words that highlight in blue in the middle of the description and those are things that you can interact with you, you might be able to examine them and see commands, things like that.

Johnny:             And so it was important for somebody who's blind who can't see that color to have a symbol, so that their screen reader could be set up to read that word in a different way. I forget if it uses like a slightly different pitch or what the deal is. Nut having that highlight hint, um, helps them find those words in little descriptions. Um, the other, we also have an option that will strip extra ASCII symbols from things. Our brain implant network has support for some simple Ascii artwork. We've gone through phases with at one point people used to get kind of extensive with it, but now we've sort of peeled it back so that you can't really do it anymore in part because of the blind people. We want to make sure we're supporting people as best we can.

Johnny:             And so you can strip out the ASCII and this'll give you a simple formatting to a lot of presentations of stuff where we might structure inside of a box or, or doilies and decorative, bits. We've also added combat labels to our messages. We have rather a descriptive combat messages for all the attacks and they come in colors. And of course if you can see the color, you can know it's a hit, you can know it's a mess. You can know it's a critical. Um, and so we've added labels before these that you can toggle on so that you can just see that you were hit, that they missed and it helps it move along a little bit. We try not to do that sort of gamified presentation in a lot of places. We try and just stick to sentences and paragraphs of things because we want it to be read more than played.

Johnny:             Uh, that's, that's something we're always sort of a drilling into people. You're here to roleplay, not to game. If you want to know all the metrics about, everything, you're kind of playing the wrong game.

Eric:               All right. So that kind of segues into our final question. Um, so is there any closing advice for all of the roleplay intensive MUDS out there?

Johnny:             You got to spend more time on your rules than other modes, you're going to have to restrict various aspects of things and you have to handle the abuse cases a little differently because sometimes what is going to be abuse in one context is going to be a tool needed for RP in another. And if you put coded restrictions around whether somebody could kill somebody for instance, well then it's going to take admin intervention in order to programmatically kill them when it's determined that that's the right thing to do and it's going to be very hard for you to hand manage all those situations.

Johnny:             You deal with something like a MUSH where it's very command light and you're having to sort of adjudicate every action you rely on the players to either self police or you have to do a lot of manual intervention. Obviously we can't be doing that when we have 60 people connected at a time. So we have to sort of pick and choose where we put our direct actions. So we've started to automate some things and at the same time we try and limit how much we automate because that takes out sort of the special sauce of what makes a roleplaying intensive mud special. If everybody gets the same message every time they do something that's very mechanical, it feels more like a game than it feels more like a role playing experience. So that's, that's in part why you want to have the puppets of the GMs and, and, and you want to vary things up like that.

Johnny:             So you want to be careful how much you automate, give your players extensive abilities to customize their character present. Presenting themselves through the description is one thing. Our descriptions have many layers. Uh, but now we've, we've started to take that into how they enter rooms. So we have this thing called short descriptions. It sort of boils down how somebody looks, gives them cool descriptors like trendy or vintage and stylish, things like that shows sort of a light state.

Johnny:             People love perfume. You can smell things in Sindome. You can smell horrible things and they can make you vomit too. It's kind of fun that way. The notes, I can't recommend the note system enough. Just being able to communicate between your staff and your players to understand what the player means to do is very important in RPI and be willing to go beyond where your code is. Look at what the players are talking about doing with it and think about ways you can take your code in those directions. There's a, there's a lot of subterfuge in Sindome, a lot of what, well, what is important isn't said because it's implied and the more you can support that sort of vagueness that gray area of life, the more your players are going to surprise you with what they do with it.

Danny:              I'd like to thank you for coming out, for joining us on the podcast. I think a lot of good stuff has been said and there's a lot of good stuff for people that are running their own MUDs out there.

Johnny:             Thank you. It's been good having a conversation with you guys. If anyone wants to ever chat with me, I'm on the MUD Coders Guild slack and feel free to hit me up for advice anytime.