Posts made by Jaunt

I'll forward your thoughts to Jeshin, as I'm not a server admin myself.

@ThugHeaven said:

Did this die or something?

Nope. It didn't die. There were just some serious server-side issues that took the site down for a few days. OR decided to use that as an excuse to take some time to re-engineer the website and forums. It should be back up this weekend.

@Thenomain said:

One of my more vocal/angry/forceful posts apparently (I am inferring) caused a regular poster to quit, so I am no longer going to share my opinion on the Optional Realities boards.

This also means I'm not going to be reading the articles. It was one of the articles that I flipped my shit over, due to how poorly thought-out and limited it was. I imagine my response was the kind of response that causes people to not want to engage with.

I suspected that my assessment of the articles was going to remain on the 50/50 (solid 'C') range for what I would expect in content; the quality of writing was about what I'd expect for a fan 'zine so eh who cares about that. The good articles were good. It's up to you, the reader, to decide if it's worth finding content that interests you.

Best of luck, OR.

Just to be clear over here, because we posted as much on OR, Leah didn't leave OR because of anything you said. I'm not going to discuss a private issue, more than to say it had to do with OR's moderating of off-topic threads, and her feelings towards the policy.

Obviously, like I've said in the past, it's totally true that the quality and accessibility of the articles is going to vary author to author. For instance, I put a lot of thought into the three articles that I've written for OR, but they are largely specific to people interested in designing their own game and thus not all of them are universal. That's okay, in my opinion.

OR is an ambitious hobbyist effort (while some of us are writers, none of us are game journalists -- except for @Brody), that primarily gets used for two reasons: conversation between developers that wouldn't often communicate otherwise, and player feedback and discussion about various games that help paint more specific pictures of those games for folks who might be considering playing them. A lot of players in our community weren't aware of how many games there are that are similar to their main game, and it's a great thing to be able to refer them to a new game when they need a break from their current play-space. It can only help with player retention in the community -- or, at least, that's the idea.

I don't think you really ruffled any feathers over at OR, though. You were a little aggressive sometimes, but mostly reasonable. No flame wars started over what you posted. I wouldn't worry about you having a negative impact on OR at all: you didn't.

My personal involvement with the running of OR and its articles is pretty much over at this point, if only because I needed more time for the development of my current projects. Running the October contest was sort of my last big involvement on the staff side of OR for a while. That said, I'll still write articles from time to time, and I still participate in the conversation there. It's a good community of people that are doing things. In an era of MU* stagnation, there's something to be said for that.

@Kireek

I have no idea who you are, or what you're talking about. I get that you're talking about me, and Project Redshift, but what don't I value in terms of transparency? I'm ... actually, like, one of the biggest proponent of transparency in ethics culture on Optional Realities, to the point where even my fellow Redshift team thinks that I'm too pro transparency.

I'm curious as to how you think my/our (probably my, as the designer of the game systems for the engine) policies on ethics/transparency might negatively impact my design of the Evennia-based engine that we've built. If you've thoughtful concerns, things that I haven't considered, that might be helpful to me. If you've concerns built on misconception or something along those lines, I'd love to have the chance to set you at ease.

Beyond that, there wasn't a whole lot on OR in October that I felt was particularly of interest to MSB in terms of articles ... but I do think some folks here might find our three winning short Interactive Fiction games interesting, from October's monthly creative contest:

http://optionalrealities.com/forums/index.php?topic=339.0

To note is that @Griatch walked away with the top prize in last month's contest.

@Derp said:

I mean, think of your most commonly used things. Pose, Say, Emit. The only things they do, literally, is change how the thing sent to the room you're in starts, and of course they can trigger certain side-effects with advanced foo (that no one ever uses). But even if you have a button for all three of those, seriously, how would it even be used? Do you hit the button and then type what you want to send, and hit enter? Do you type what you want to send and then hit the button to do it? Even the 'get' thing earlier, if you know what you're wanting to get, why do you need a button that does it?

I wouldn't create a button for to-room roleplaying tools. I do think that they can be made more intuitive (for instance, by removing the need for the commands themselves and using a symbol like @ or the like to parse, so that the "command" is as close to just writing prose as possible).

More important, I think, is to create rewarding, immersive tutorials to teach players how to use the commands they need to use most frequently. The rest of the gaming world has caught onto this, but our approach to tutorials has been cave-man at best.

As far as 'get' goes, if you wanted to, you could create UI that would allow you to click on an object or character and see a dropdown menu of different ways that you could interact with that object. If there weren't any additional scripts on objects, picking them up COULD be as easy as clicking on them. And clicking on objects to take them is definitely something that all gamers understand.

None of these ideas (besides tutorials) are great for every game, but if you can step back and not make any assumptions on how things should be for your game (in terms of commands and interface), then I think you'll find a lot of little things that could be done to help make them more accessible to new players.

@HelloProject said:

There are probably more intuitive and time saving ways to do building period

Most definitely. I think, ultimately, a fully realized web-based interface for building and scripting and other softcodey things would probably be the best, most intuitive approach for MU*s. Some engines have such things (some older versions of SMAUG, for instance), but most old OLC systems have become out-dated over the years ... as the genre's become more insular and isolated, there's been less motivation for creating and maintaining accessible OLC.

It's still just as important as it was like 20 years ago to bring in new developers, though.

Simple and intuitive aren't the same things. While there are definitely things that could be designed more simply for MU*s (which could be either a good or a bad thing, depending), designing commands that are more intuitive is a definite positive.

It's the whole learning curve thing. I don't think that you need to sacrifice functionality for ease of learning. I just think that, often-times with our engines, functionality could be a lot more intuitive than it currently is.

For instance, while I don't find @dig to be a hard-to-use command (especially with macros/aliases), I can't say that it's very intuitive at all.

I think that the prompt idea is interesting. If you could make a prompt system that was optional (for instance, only used if you typed "@dig" by itself), and was designed to actually help teach you how to use the @dig command (by showing you the new sum output for each step, highlighting the additions or some such), then I think you'd be onto something.

The prompt would be slower, but very easy to understand and use, and it would teach you the faster, less hand-holding way to accomplish the same thing. To me, that's intuitive.

@HelloProject

What you're suggesting is actually the purpose of another really cool project (that's on a 9-month hiatus due to 9-month reasons right now):

http://www.futuremud.com/

I know that the goal is to create an engine that is super easy to get moving and requires minimal amount of programming knowledge to use.

Evennia, while it does require programming knowledge, does make things easier with its clean code, interface, support community, excellent documentation, and its use of Python. It's pretty easy to get Evennia running out of the box. As more contribs are open-sourced, eventually plug-and-play modules will hopefully make it pretty quick to get a fully functional game going. I know that we aim to do this for Evennia with our modules once we've got a basic, usable, adaptable engine and modules prepared.

Hopefully in the next year, folks will have some great new options to start a game with less obstacles.

So, those sorts of projects that you're wanting do exist. They're just still developing. They could be used to create a MUSH-like or RPI-like or any other sort of game, ultimately. The idea is flexibility and modularity, for both projects.

@Griatch said:

@Jaunt I like the concept of the command-less emote with @ in it. Is this just a random example idea or something you are actually planning/have made for Redshift?
.
Griatch
(who recently made a contrib emote system for Evennia but used the "emote" Command and didn't consider making it as a "no-match" system command. Cool idea!)

Our idea for Redshift is to try to parse all possible output for to-the-room roleplaying tools using @ wherever possible, yeah. We have a stock RPI-ish system similar to your recent Evennia contrib in place currently, for the purposes of testing. Our goal is to have our fully realized system in place for our engine/game DEMO in the Spring. : )

@HelloProject said:

Once one gets used to the hobby itself, and perhaps gets a taste for wanting to do something more complex, if they do at all, then they can move onto learning an established thing like Penn. But again, as long as it costs money to make a MU*, I think that's going to remain off-putting.

Well, I don't think that streamlined design needs to be any less complex in terms of functionality. In fact, REDSHIFT's really rather super complex in terms of what's possible. My goal with it is to make it easy to learn the basic commands (roleplaying tools, navigation, combat, etc) so that there is a more organic learning curve for new players. It's not about removing complex options, but rather making them easier to use.

As far as hosting goes, it's actually really super cheap. @Jeshin pays about $200/year for REDSHIFT's server and three different websites with full forums and other features. The real cost for creating a MU* is in time -- specifically the developers'.

@Derp said:

Sometimes, coding for the LCD is not the most viable option, and expecting players to put some investment into learning the system and the command structure does, in fact, end up being your best option, even if it's not perfectly intuitive for a newbie or is somewhat complex.

Absolutely. If you're doing WoD (or D&D, or some other established system) then there's a benefit to sticking with their system. Anyone who learns WoD will be able to understand the mechanics of your game.

I personally prefer creating my own combat systems from scratch, because I feel like I can create things that were designed to work specifically for my game. When I've tried to adapt WoD or D&D for MU*s before, it can sometimes feel like I'm trying to shoehorn a square peg through a round hole.

But I'm also not necessarily talking about that. I'll give a few examples of some things that I think could be more intuitive:

Pose/Emote: While I think that "emote" is probably a more intuitive command for new players (since its used in chat rooms and other places, and everyone knows what emoji is currently) ... it still feels a little un-intuitive to me in the way that it's often executed. Is there any reason that, if I were to design a game from scratch, I couldn't do this:

The winter wind howls as it tears through the camp, blowing snow about wildly in its bitter dance. Around the campfire, those gathered to listen in to the storyteller's yarn huddle closer to the flickering flames, struggling to stay warm even as the fire weathers the start of a frozen night. A young babe begins to cry, pressing its red nose to @mother's breast. "Come, little one", @ says with warmth in his old, learned voice. "Do not weep so. The Ice Spirits are hungry, but they cannot hurt you here. The magic of the Tale keeps them at bay. Let me tell you a story ..."

As @ transitions into the start of his story, he pulls @hood up over his head and throws a handful of some strange powder into the fire. Suddenly, the waning flames leap into the air, coming to life in a burst of color: red, blue, purple, green. The fire dies down a moment later, but stands taller and stronger against the whipping winter wind than before.

In the above cases, instead of creating different types of command qualifiers for emoting/saying/talking, I'm basically letting people write prose freely, and just letting them use @ for when they need to target themselves, an object, or another character. A modern engine will see @ and parse, knowing that we're now talking about an emote. It can even parse secondary words like tell/whisper/shout/say/etc, so that you don't need seven different commands about talking. One command that's smart enough to figure out what affects to apply to your character's speech can be enough.

What about status commands? To look at your score sheet, or see what affects might be on your character? To look at your account information? To see how many players are online?

What about using simple GUI menu interfaces that can plug in to MUSHclient or a webclient? It doesn't have to mean anything fancy, but even a simple health bar and menu buttons can go a long way towards making the interface a little easier to get for new players. Many new players claim to be turned off by ASCII prompts and ASCII representation of things. Why do we still rely on ASCII when webclients and MUSHclient can do GUI rather easily nowadays?

What about tying the backend of your help files in-game to an actual help wiki with organized hyperlinks, using more very simple GUI?

What about web-based OLC (some engines do it) to help with building and remove the need for developers to understand strange building tool/soft-code syntax?

I like to think about something that I refer to as "player command upkeep". Can I look at my game's commands, watch players/testers, and say, "Hmm. They're having to use the 'scan' command every few seconds while they're out in the wilderness. Is that too much?" ... or, "Wow, they have to type seven commands just to empty out their backpack, organize the items on a shelf, and then fill their backpack up with water bottles. Why so much spam?"

So, what can we streamline? Combat's its own, separate sort of thing. It's the most common interfaces and commands that I think are most worth looking at. Consistency in syntax style across all social commands. What's the simplest approach to emoting/posing that still allows for the same breadth of versatility?

Why have players use '*' or '~' or '%' to target other objects/characters in emotes/etc, when they're used to using '@' nowadays in social media?

I'm pretty much throwing a ton of random thoughts out there, but they're just a sampling of the sorts of things that I think about a lot. I've played and designed MU*s for so long (as have many of you) that it's really easy to take for granted that something should work a certain way just because it's always worked that way before.

If you're starting from scratch, or near scratch, I've definitely found it worth it to keep your end goal/aesthetics in mind, but be open to considering each command and whether or not it could be streamlined and made more intuitive for new players.

That doesn't mean designing for the Lowest Common Denominator (I don't think I'd call new players that anyways, they're just inexperienced; each one of them could be a gold mine of potential). It just means challenging myself to spend some time really thinking about how the interface could be better, easier to learn, more intuitive, and all without sacrificing versatility and function.

Ultimately, I'd rather make vets learn new syntaxes if it means new players will be able to catch onto those syntaxes easily. Vets have played enough different types of MU*s that adapting to new syntaxes is much, much easier for them than it is for new players.

@HelloProject said:

This reminds me of how YouTube and Facebook are horrifyingly bloated sites now, rather than focusing on being simple and functional. They're complicated and more difficult to understand than ever.

Yeah, I definitely think that innovation needs to be geared towards making things easier to design for newcomers, easier to learn to play for newcomers, more aesthetically sleek and appealing (to attract more newcomers), and any feature enhancements need to be more intuitive to use than legacy commands. It's relatively easy for MU* veterans to learn new syntax (especially if they're intuitive). Legacy engines rely on some pretty non-intuitive mechanics and commands to manipulate things, and that's definitely a hurdle for new players who aren't used to text interfaces.

Basically, innovation needs to not be bloating. It needs to be streamlining, first and foremost. That's a big reason that I've enjoyed working with Evennia for REDSHIFT, even though I was far more familiar with the OpenRPI engine that I helped to build. OpenRPI might be familiar (for RPI players) and have superior features already built into it, but all of its progress has been built on top of derivations of derivations dating all the way back to DIKU.

Working from the ground up is more work, but has a lot of advantages. It's pretty easy to take old ideas and implement them more intuitively, while tying in more standard features with newer features in ways that actually make sense. Sure, I can't create a new game with Evennia in two months (not yet, at least, until more development plug-ins stack up) ... but I can create a game that is better, more stable, easier to learn, and doesn't have random chunks of legacy engines that are just code trash now.

@Thenomain said:

I don't know what games you've been on, but I've never heard stagnation being encouraged by saying "the old ways work just fine"**. I think that the Cult of the New is almost as dangerous as the Cult of the Old. The stereotypical young person sees the stereotypical old person as unwilling to change because new things are scary. The stereotypical old person sees the stereotypical young person as ignorant and with no regard to things that are that way for a reason.

They're both right.

Keeping things the way they are is correct because we understand how it works.

Ignoring the way things are is correct because it's the only way to understand how new things work.

I think anyone who clings to either one of these ideas is misguided, because we need both order and chaos, tradition and innovation. Whether or not people realize it, tradition is the foundation from which innovation grows.

You've hit onto the important something about innovation here. New (re: inexperienced) people with new (re: untested) ideas are more likely to fail in their initial endeavors, while old (re: experienced) people maintaining the status quo (re: their personal preference) are more likely to reach an expected outcome with their project.

But, the best case scenario in my mind is this:

New (re: inexperienced) people with new (re: untested) ideas are taken under the wing of old (re: experienced) people maintaining the status quo (re: their personal preference). The new folks get experience that helps inform them of how to have ideas that are actual innovations that can succeed, and the old folks learn from the new folks what of their design philosophies are good, what are simply tradition for the sake of tradition (or ease), and how they might shift their perspectives to make their games more appealing to a younger, more inexperienced group of players.

In short, it's the experienced folks who should drive for innovation, using their experience to guide them around the pitfalls of treading new ground. And if they can teach what they've learned about the hobby to newer members of our community, then those newer members will eventually push that innovation even further -- and, in the process of evolution, hopefully what we do finds a way to be more accessible, and we learn how to tell better collaborative stories.

But what us vets have to learn from new players or would-be developers is important, too; they come to us with (relatively) few preconceived notions on what our games are and what they should be. They don't even know how they work, at first. They're the ones best poised, in many ways, to show us what sort of innovations might be necessary to retain more players. And, in a hobby where the goal is so rarely profit, players (and what players bring to our games with their roleplay and activity) are sort of our currency.

ETA: Only somewhat related, it's the youth that generally has more free time to play, and more friends willing to spend their free time to try out something new. For most of us, as we get older, our circle of friends narrows and cements itself, and our responsibilities grow to the point where we just don't have the free-time to play as much as we used to.

@surreality said:

Anytown by Night has been done, and a number of players just port their character from one to the next whether they fit or not. That makes me sad, because one of the truly amazing things about this hobby is the chance to make new things and tell new stories. I just felt no need to pick a place for people to tell different permutations of that story again.

It's the same problem in all mediums, really. Broadway, television, film, games -- they all struggle to tell new stories instead of rehashing old ones. It's challenging, and easier for players to just do what they've done (and enjoyed) before. Especially players who are looking for a slice-of-life sort of game fall into this trap often. I don't think it's purposeful for them, half of the time.

While it's somewhat inevitable for a lot of players, I do think that you can help mitigate the problem by giving them unique situations to react to, original personal challenges to overcome, and potential hooks for behavior/perspective-changing events. In my experience, some players are just going to ignore that so that they can sandbox and live out wish-fulfillment, but others will take the bait and find a new way forward with their rehashed concept.

I tend to like to create games that are pretty grim. One great thing about that (for me), is that it makes my games less attractive to people who want to roleplay happy, successful, super-awesome versions of themselves. There are better games for them to do that on.

ETA: And what you're doing, creating an environment that's not been done to death, is a great first step. I always like to think about 'surprise', too. When players aren't being surprised, then they're basically just walking through a story in their head for which they already know the ending. That's one aspect of a GM approach that can work wonders; you can kick players off of their straight, well-paved road, and then let them explore the surrounding woods. Who knows what they might find in there?

@surreality

You can always go the fun route of introducing an STD "plot" to deal with the starlets. It's LOL every time.

@HelloProject said:

@Jaunt There is one thing I'm curious about, in my limited experience with RPIs.

Like, I'm not sure if the theme of an RPI generally experiences growth? I'm not saying they don't, this is an actual question. Like, if you could introduce some new technology to the theme, work your way up to starting a faction that addresses a problem that wasn't previously a focus for any factions (Assuming that a particular game has factions, of course). Or even the overall death of a faction once it's run its course and outlived its narrative usefulness.

Is it possible for RPIs to function in such a way, or are they generally more static and focused on preserving the theme, but allowing players to grow/rise in ranks/have political intrigue within the established climate of the game?

It depends on the game, largely. IMO, the good ones are more than just a sandbox. I've ran two RPIs that approached the issue differently:

• SOI Northlands/Mines of Moria. Back in the golden era of Shadows of Isildur, new regions were opened up frequently to allow for new meta-plots and more player options. It worked really well when SOI was very popular, and far less well when its numbers dropped. The typical progression was that new regions would open up, and eventually, player/staff meta-plot would lead to their closure so that new regions could open up once more; sometimes that closure could be the culmination of some cataclysmic event, and sometimes it could be a more subtle/nuanced ending to that area's story. Sometimes, it was abrupt and jarring. Different admins ran different regions independently, so the game actually varied broadly between regions in terms of themes (and quality).

• Atonement, which is probably what I'm best known for in the RPI Community. I wanted to create a game and story that was a little more like a television show, with "seasons" (that I called campaigns). Each season would change and expand the scope of the over-all story to keep things fresh, but they all tied into telling one story that was designed to have a beginning, middle, and end -- all driven by players.

Season One: It started off with characters waking up from cryo-sleep aboard a derelict colony ship floating in space, with amnesia. It wasn't long before they realized they weren't alone (introduce the "Genetic Terrors" or "Our Zombies Are Unique"). The majority of the first season involved the characters trying to survive (and largely failing), being manipulated by the Terror's Queen, and trying to learn more about who they are and what they are doing out in space.

Season Two: The characters managed to take control of the ship and crash-landed on the Moon, where they found that, while Earth was unhabitable, humanity had survived (if barely) on a partially terraformed Luna. The survivors integrated with a wasteland society living in "Grungetown". Of course, they brought the Genetic Terrors with them, and ultimately, the Moon was overrun and the last bastion of survivors left on a repaired colony ship with hopes of finding other humans elsewhere in the solar system.

Season Three: After searching a nearby space station they believed might house a thriving human society, they found nothing but more answers and more questions, and finally realized that they truly were the last of the human race. In fact, the Genetic Terrors had already been there, and once again they pitched a battle for survival against their pursuers. They ultimately escaped.

Season Four: They landed on Mars after finding evidence that there was a human colony there, too. All they found were dust and eerie remnants of a colony that had fallen into decadence, and had chosen to stop trying to live rather than find a way off of Mars. Digging and exploring further, they learned that what they'd thought was some sort of supernatural phenomenon was actually the appearance of windows into an alternate universe, caused by an energy source experiment gone wrong on Mars. In this other universe, they saw living versions of themselves and the MANY characters that had died throughout the course of the game. While their "alternates" weren't always doing well, overall it was clear that the alternate universe had defeated the Genetic Terrors and survived. For many characters, they saw a world where they were happy. They also learned that humans engineered the "Genetic Terrors" as a sort of weapon, and that it had backfired on them. They were, themselves, responsible for their own downfall.

In the end, the Genetic Terrors hunted them down to Mars, and the players had to choose: do we try to break through the "windows" and escape into the alternate universe (would there be a season five)? Or do we fight (and most likely, die) to keep the Genetic Terrors from invading the alternate universe?

They chose to hide the alternate universe and fight, and Atonement ended with the death of the last remnants of man-kind in an epic space battle. Characters received glimpses of their alternate lives, and their sacrifice to protect a better version of their world was their "Atonement" (wah wah).

Only one of the four seasons featured any staff-created clans or NPC leadership at all. Players created their own clans/factions. In fact, one of the coolest things about the first season was watching hundreds of characters with amnesia and no idea what was going on, and then beaming with pride as they began to establish order and create a strange, but believable society on board the derelict ship --- 100% through roleplay.

Atonement was very popular and lasted for a little over three years. It didn't close because of burn-out or lack of player interest, but because its story was over. Some TV shows last for too many seasons, and their story suffers for it. I was actually rather happy with this campaign/season approach, as it allowed us to continually change things up -- but also tell a tight, focused, awesome story.

Having said all of that ... there are also RPIs that are just sandboxes. Immersive sandboxes, often-times, but not a lot changes on them. Some players actually prefer the "slice of life" approach to things, which is totally cool -- but that's just not me, or the sort of game that I like to make.

@HelloProject said:

If you just collect some sticks and build a skyscraper in a day, it breaks my suspension of disbelief super hard.

Yeah, absolutely. It's all about good design vs bad design for both types of game.

Large building projects in RPIs can be designed to just be "type this thing a couple of times and you'll have a fort in a day". They can also be designed so that you have to work with a group of other characters to build your new area, require roleplay from the characters as they build (not hard to softcode this pre-requisite in most of the engines), put a cap on the amount of work that can be done in a single "day" so that it takes a believable amount of time to finish the project, and (depending on the setting) create scripted obstacles that might randomly get in the way of building. You can make the materials necessary for building require players to work together (and therefor, roleplay together) to be able to go out and get those materials. You can make those sorts of things collaborative by design.

@Thenomain said:

@surreality said:

Using WoD as an example, if you are making a game in the Arctic designed for werewolves hunting down The Thing, and it says so on the tin, you are generally going to say no to the player who wants to come in and play (etc. etc.)

This shouldn't be a rule. It should be a definition of playing an RPG. You follow theme and setting. If you don't want to follow theme and setting, please find your entertainment elsewhere.

It's a little easier to manage this with RPIs than the MUSHes I've run, in my experience, because more of the "micro-management" is hard-coded. For instance, to build a building in an RPI requires you gathering the necessary resources and crafting the building (the individual rooms, the furniture that goes inside, etc). If my game doesn't have skyscrapers, then I just don't create crafts to build skyscrapers.

If my game doesn't have elves, then they just aren't a selectable race when you're creating your character application.

So there's definitely a little bit more policing that needs to happen with MUSHes due to their communal-building aspect. Still, I always feel compelled to use a light hand with such. It's a fine line to walk between the following, and some games/admins do it better than others:

• "No, you can't play a female dwarf in my 1970s NYC period noir game, because dwarves don't exist in that world and it's completely inappropriate."

Should be common sense, but players will be players.

• "No, you can't play a Vietnamese immigrant baker in my 1970s NYC period noir game, because that character would have no reason to get involved in the meta-plot of Italian gangs vs Irish gangs vs the NYPD."

Well, who'm I to say whether or not that character couldn't find an interesting hook into the story? I suppose I'm in charge, but that seems too narrow-minded to me.

@HelloProject said:

There's a thin line between unnecessary theme policing and quality control.

@Thenomain said:

as what tends to happen when people are more concerned with enforcing rules than using the rules to enable gameplay.

Yep. It's one of the big reasons that I'm opposed to over-policing "theme" and other peoples' roleplay. Micro-managing players is a slippery slope to No-Fun-for-Anyone Town.

Policy should create options for players and not reduce options for players. That can also mean making sure that staff aren't playing the leadership characters in a game, so that players can drive that bus themselves.

It can mean a whole lot of things.

@Ganymede

I don't disagree with the importance of what you're saying. I just think you can go a step further. I also don't think policies need to be labyrinthine.

"You cannot play PCs" is pretty straight-forward. It might be a bit of a blunt solution, but it definitely works.

There are certainly other ways to go about it as well.

@Ganymede said:

@Groth said:

If those policies hadn't been written down I think it would have been harder for her to build that trust and harder to ensure that the members of staff she brought in would stay true to her vision.

Even if those policies had been written down, I would not have continued to play on the game if the rules were not consistently enforced. Even in the absence of those policies, I would have continued to play on the game because of my opinion of stiffly conduct. My coming to the game had nothing to do with the staff policies at all.

I suppose, after our discussion, that if I had a point, it is that the conduct and character of your staff will speak louder than what policies are publicly listed.

I think that you're right. I also think that enforcing and encouraging strong policy helps to teach newb admins good ethics while staffing. Creating an atmosphere of accountability and ethical behavior can rub off on folks that work for/with you. New admins tend to emulate the behavior that they are taught by the veterans that lead them, and nothing says, "This is what's acceptable and this is what's not" better than having strong policy.

At least, that's where I come from. It takes following through on that policy to make it work, but I do think that it is an important inclusion.

@Three-Eyed-Crow said:

Could you run a LotR pay-for-play game without giving the Tolkien estate/Tolkien Enterprises a cut?

Yeah, even if SOI's engine allowed it to be a commercial product (it doesn't), the licensing rights to create a for-profit Tolkien game put it beyond reasonable reach. World of Darkness and other existing IPs face the same issue.

It has to be original if it's going to be professional, in almost all cases. There is the rare exception; IRE's most recent game, Midkemia, is based on existing IP. They just happen to have so much money (from pay-to-win microtransactions) that they could afford the rights. That's not going to be the case (or the most cost effective way to create about a professional MU*) for the vast majority of us.