Posts made by surreality

@Groth said:

@surreality said:

There are also usually limits to the kind of storylines players are permitted to run, vs. what storylines only staff can run. This usually has to do with very high-powered antagonists or metaplot (the larger actions at work in the world that are staff-directed, and proceed over a very long period of time).

A number of players never get involved in plots at all. They're more there for the 'improv' aspect of character immersion.

The hard part for MUSH's in my experience has always been the question of world coherency. How do you ensure that all the players feel like they're taking part of the same world even though they all play at different times and with different people?

Some MUSH's like the Exalted MUSH have traditionally taken the approach that they don't particularly worry about it, letting players run almost any plot they want and hand-waving most inconsistencies. Other MUSHes like RfK put a high priority on consistency and sharply limit what sort of plots can be run without the involvement of Staff. I've yet to come across a great solution to give players wide freedoms while making sure that the world stays coherent.

I'm more in the 'strict limits on what can be run' camp, but that's also because it works for the kind of game I'm presently building. You also have to provide creative tools for players to work within those limits, and provide solid examples they can either emulate or compare and contrast with. Most games I've been on, if they allow PrPs, strictly limit what can be run without staff oversight or approval.

Those strict limits also need to apply across the board for any of this to be relevant -- to building policy, background policy, character types allowed, it may mean certain merits are not in play or must be redefined, and so on. I'm building a game in a small town rural setting, for instance. There will be no Hollywood starlets or skyscrapers or gleaming castle-mansions and megayachts there, because they make precisely zero sense in the setting and it will be a cold day in hell before any of them are approved for the grid.

It's a bigger thing than just restricting potential plots to accomplish 'coherent setting'.

@Jaunt said:

@surreality said:

First, it's generally not an "I" creating a game. This may be assumed but it's worth noting it shouldn't necessarily be. I'm doing a fairly absurd amount of work putting one together now, but I am absolutely not doing it alone. (It's also worth noting that the people who are also contributing their time and energy to the project are folks I've met here for the most part, all of whom have contributed in equally important ways, from my perspective, just for the asking and some volunteered. Others provided advice and tutorials that helped get everything started.)

This is actually pretty big, and it's something that shouldn't be discounted.

That's pretty cool. I've always tended to create games, even MUSH, with a singular partner, not because I dislike working with a larger team, but because it's difficult to find folks who work at the same (crazed) pace that I do. I think that the idea of joint creation/responsibility is one of the cooler defining features of the MUSH community.

I'm pretty much in the same boat on the crazed pace. I'm just... hyper-detail-oriented to the level that most others can keep up pretty easily. (I need three more of me to document everything, I really do, just to get everything out of the brain and into an accessible format.)

The reason I say it's a fusion of both is that, after swapping in 'staff's' for I in the first statement, it tends to be the case. I wouldn't, for instance, put this much time and energy into creating a game I had no interest playing on at some point as well.

This is very true in the other genres of MU*s, too. Not always true, but very often. While it's probably a bit less of a problem with MUSHes because of their social and (usually) non-automated combat systems, I do think it causes problems in other genres (like RPIs): when administrators are also players, I have seen the two following problems eventually destroy many games:

1. They are more dedicated to playing than programming/designing/creating. This is probably less of an issue with MUSHes, since the content creation is more of a communal aspect of the game.

That's a problem on MUSH/MUX as well, or can be. The trick to solving either is hiring people with a sense of responsibility who won't shirk their duties.

2. Because they are so invested in their player characters, and they have the ability to do so, they cheat to get ahead. Cheating has always been a huge problem with MU*s, because there is an important trust-based relationship between player and admin. When that trust is destroyed, it very often ends up in an eventual player exodus, and it's really difficult to re-build.

This definitely happens in both, too -- but again, it has a lot to do with picking the right staff. One of the things I noticed on the MOO was, frankly, a lot of this. It would have been very easy for staff with certain permissions to adjust the damage rating of their weapons, tweak their stats, and so on, in ways that were entirely invisible and thus, people absolutely did it. Advancement was an 'invisible' process there, while it's typically more firmly recorded and noted in many modern MUXes. (Advancement is logged, and if what's logged doesn't match what's there, it becomes obvious enough.)

That's why staff on my games don't play PCs. We test PCs for gameplay purposes, and we observe others' play, and we GM --- but that's something that I always feel strongly about. Even the perception of cheating (even when it might not be true) can ruin the trust between players and administrators in other MU* sub-genres.

It can, and I've seen it happen. I don't think that's a good enough reason to forbid it, primarily because I refuse to allow one paranoid asshole shrieking about how 'cheating could be happening!' even when it's not ruin my experience on a game ever again. Games need staff that aren't burnt out and miserable. What they don't need are paranoid assholes. The former are essential, the latter are toxic in more ways than that. You just need to state up front how things work and be transparent about things, and allow people to make their own decision about whether to play there or not.

But, I also built tools to stop the spawning, or to freeze combat so that we could roleplay scenes together. There was automated player agency to keep players engaged, and there was the ability for scenes of nothing but roleplay, and there was the ability for the later, followed by the former.

This is something we didn't really have access to as an option; but we are talking about a game originally built in... 1993 I think?

If you use automated combat as a feature, and your game cares about roleplay, it's definitely worth it to add in tools to stop automated combat, stop spawning, so that you can engage your players with the same sort of in-depth roleplay that they'd get without those automated systems.

YES.

@surreality said:

The primary benefits I can see in the MUX approach are that a broader range of stories can be told in the same grid space, even if it takes work to provide the hooks to allow for this. It also means the players can find creative solutions at times to problems the code hasn't taken into account, and an automated system may not provide for.

True often, but I don't think it has to be true. RPIs also have dice-rolling mechanics for players to handle situations that automated code might not be able to take into account. And if GMs are good, they will be working to help players bring their plots to realization. I think that the main difference is that players get building tools on MUSHes, whereas on RPIs, players get in-character building crafts/scripts that GM Administrators support by helping those things come to realization, and player-developed plots require collaboration with a GM when something has to happen that goes beyond the player's toolset. It works very well when there is a great, active relationship between the staff and the player-base. It is obviously an annoying bottleneck for games that don't have an active staff.

The bottleneck happens in both, then, yep -- the 'I need a GM/ST!' moment is hard when folks aren't around or available.

It's probably more similar than you might imagine, though. What you describe about players needing staff aid for things that go beyond their toolset is the same -- it's the toolset itself that varies. Most WoD MUSHes lately don't allow build/create access at the player level, for instance, while other games do (or they allow one and not the other, etc.).

And that's why the big difference between the two genres goes back to philosophy, I think:
MUSHes are created more communally. There is less of a divide between staff and players.

It depends on the MUX, in part. Some do allow players to come up with plot -- not all do. It isn't a codebase-long trend, from what I've seen. (I started off on the MOO in 1996, and was on a MUX in... 1997 I think?) "Back in the day" I didn't see players with authority to run plots. I'm not sure when that shift went down to make it somewhat prevalent, but it was during the time I was hiding out on a game that just. didn't. care. (read: Shangrila) from some of the more toxic members of the MUX community. (Mostly, that 'Spider' person mentioned earlier. Long story goes here; tl;dr: she hounds a lot of people right out of the hobby, sometimes for years, sometimes permanently.)

There are also usually limits to the kind of storylines players are permitted to run, vs. what storylines only staff can run. This usually has to do with very high-powered antagonists or metaplot (the larger actions at work in the world that are staff-directed, and proceed over a very long period of time).

A number of players never get involved in plots at all. They're more there for the 'improv' aspect of character immersion.

RPIs put a lot more responsibility on their staff to create content, including content that will immerse players when they're not expecting it.
It's an important distinction, but not a massive one.

There's more pressure to do it, perhaps -- but I think there are different ways to do it, which is partly what I was getting at. WoD is an interesting example in part because it has some actual social mechanics, despite being a game designed for more intrigue-based play rather than adventure-based play. The new(ish) conditions system allows for a lot with this. (I'm biting my tongue since I'm holding back on something spoiler-y on a project or I would go on at more length about some examples of this and how it can be a factor.)

The primary difference I see between the two processes on the creation front isn't the volume of content -- it's the type of content. I find I need to provide more content when it isn't coded than when it is, either to explain the rules for how a thing works, or provide enough options and story hooks to keep going.

(There's more I would add, but... lots of work today. )

@Jaunt said:

MUSHes are really about creating co-operative interactive fiction (through roleplay). They use soft-code to let players have the ability to do things that other games would only allow GMs to do. And so, because of that, there's less of a sense of "I created this game, I'm responsible for this game, and other people are players" and more of a sense of "I created this game so that I can play it with other people, and we're all responsible for it."

(Just addressing this bit first, 'cause there's a lot to say on each of these things and time is limited.)

From my perspective alone, this is one of those situations in which I'd say: "there are levels" and it's really a fusion of both.

First, it's generally not an "I" creating a game. This may be assumed but it's worth noting it shouldn't necessarily be. I'm doing a fairly absurd amount of work putting one together now, but I am absolutely not doing it alone. (It's also worth noting that the people who are also contributing their time and energy to the project are folks I've met here for the most part, all of whom have contributed in equally important ways, from my perspective, just for the asking and some volunteered. Others provided advice and tutorials that helped get everything started.)

This is actually pretty big, and it's something that shouldn't be discounted.

The reason I say it's a fusion of both is that, after swapping in 'staff's' for I in the first statement, it tends to be the case. I wouldn't, for instance, put this much time and energy into creating a game I had no interest playing on at some point as well.

Here's why: when it comes to world-building, to do it well, you have to love those basic building block ideas enough to give them enough meat on their bones to provide story hooks in abundance, even the ones that have no appeal to you at all.

I can offer a direct comparison here on this specific point.

The MOO @il-volpe and I both worked on many moons ago, Ghostwheel, was heavily automated. I was a builder there, which meant I could create small areas on grid with their own flock of roaming monsters and the like. I'll call it 'Zombie Swamp' for simplicity. It took about a week to create and populate the first area I put together, since it required only a basic concept to really get the point across, and some fairly decent descriptions for the places and the creatures in them to convey all the thematic elements that were required. There was stuff to do enough to keep folks busy and enjoying themselves with that. Minimal research was required, and it wasn't too tough.

The MUX I'm working on has no roaming monsters to hack away at and keep folks busy. If I was building 'Zombie Swamp' there (which I'm not, sorry to disappoint, y'all!) the things I'd need to do to keep Zombie Swamp an interesting space to play would be entirely different. More research would be involved to offer up relevant story action hooks. Different kinds of code -- ambiance emits and similar -- might be needed. More attention might need to be paid to the descriptions of the areas to give people things to improv with. More information would be needed to provide story-runners with the tools they need if they want to have a horde of zombies swoop down on the players and essentially let the players do the 'go to Zombie Swamp and kill zombies' thing that's automatic in the MOO version and requires no input from anything but the game itself to do as a solitary activity.

Essentially, I need to do different kinds of work to keep the MUX and MOO versions of Zombie Swamp interesting to players. The MOO version more or less tells its own story. The MUX version requires multiple people to tell a story in it.

Each of these approaches has its own benefits and drawbacks. The MOO version's story, to me, was considerably more limited, because attempts to tell any story other than hunting zombies there was severely impeded by constant invasions of respawning zombies. On the MUX version, people can more readily experience other stories in that space -- but they can't do so without a story-runner handy to run the zombies if they want to hunt zombies. To have anything worth doing there, they need information about the zombies if someone is willing and able to run them for others, but they also need a pile of alternate story hooks worth exploring.

One of the reasons I bring this up is perhaps not immediately obvious, but it's important: it's harder to yell at the automated code for something than it is to yell at a person. Code doesn't give a crap. A person (staff or player) running a scene is immediately accessible for yelling at or arguing with, even if the result -- a bad roll of the dice/turn of whatever randomizer is in play -- would have the same results in both scenarios.

From my perspective, the more authority one takes on, the more responsibility one takes on. Though all have some measure of responsibility, it is far from equal.

Players have the responsibility to accept the outcome of dice rolls and the rules of the game without code enforcing it automatically, thus giving them no option not to. They still don't have the option not to per the rules unless it's a consent-based game, but there's no coded 'force' applied to ensure "fair play". Players, essentially, have the responsibility to play fair, but other than 'behave like something other than a shrieking howler monkey or nasty jackass', there's not a lot more to it than that on the player level.

Story-runners, regardless of whether it's a staff member or player serving in that role, need a better grasp of the rules than the players necessarily need to have, because they are taking the place of the automated mechanics. They also have the responsibility to apply those mechanics as fairly and impartially as the code would (as much as any human can; some argue this is impossible), with no preference given to their friends and no disadvantage to others.

Staff... that's another post for another day with less data entry to do.

The primary benefits I can see in the MOO approach are that it's possible to do something as a solitary effort if one wishes, and that you don't need someone else around who knows how to run a scene involving something other than improvisational interactive fiction to do that specific thing: hunting zombies.

The primary benefits I can see in the MUX approach are that a broader range of stories can be told in the same grid space, even if it takes work to provide the hooks to allow for this. It also means the players can find creative solutions at times to problems the code hasn't taken into account, and an automated system may not provide for.

Transparency is a double-edged sword, when it comes to stuff like this, simply because people get retailiatory. Ideally, visible to just staff would be great in case something needs to be checked out -- but even more ideally, no one ever having to check.

I'm doing a rumors-thing wiki-side. Because it's wiki, anyone will be able to see (by checking page history) who added something or changed something else. That's 'totally transparent' if someone knows how/where to look. My take on it: we'll see how this works out, one way or the other.

@Tat said:

Yeah, THIS sort of thing is what makes wikis super powerful and super awesome. Semantic wiki is pretty damn great because you can then also manipulate those by clicking on a header and seeing, for example, everyone who's taken that skill in order by points or something like that. It automates a ridiculous number of things if you're smart about how you do templates.

This is pretty much what I'm thinking. I was able to get the basics of it all done with basic templates, so I'm interested in seeing what else is possible now.

I'm wondering if it'd be possible to have something like a 'chatbox' imbedded at the bottom of a 'room log' or something along those lines, or on the bottom of whatever the structure was for the 'building the scene' pages. Then, small OOC commentary can go back and forth.

But... yeah. It's a lot of stuff to consider. It seems viable, though. Randomizers would need work, which is never easy. I never had an issue with the transparency issue re: sheets, either, but some folks are super cagey about it. I can see perhaps wanting to keep certain RP subjects more private cough but other than that it seems like something that shouldn't be impossible a hurdle to get past.

Also, OMFG.

...the template-fu really is so much easier with SMW, though I'm tweaking the blazes out of it for formatting still. Holy mother of cats. Thank you, @Roz. I have a lot of recoding to do, but yegods. Converting All The Things will not be terribly quick but damn. DAMN. The properties and ability to store things there rather than in-template is

I'm gonna try to add a section for it eventually along with some stuff to facilitate cutscene writing based on just what tools we have now; but yeah... I would love to see this done.

It's definitely something I want to work on. I'm crash-testing constantly on stuff -- and have that fragile hope some of it could potentially work. SQL integration stuff would be a big thing, definitely, and it is beyond me -- but examples of that would be potentially enough for folks to set up the integration they want or need (if any) with their codebase.

...now if there was a way to create a 'play from the wiki' or wiki-based game engine that links around to all the things when/as needed? AWWWWWWYEAH. So many of the things we talk about wanting from a MU* -- links, instant access to data, graphics, color, etc. -- would be entirely possible.

But that's ten thousand miles beyond me. The things that could be accomplished with that could potentially be amazing. It strikes me as something that is likely possible, though.

I suspect people have tried, because somewhere in the pile of extensions I saw something about a dice-roller.

It'd be an entirely viable option for play-by-post/play-by-email style games, and I'm surprised that isn't something I see everywhere already. One of the main stumbling blocks is that everything is visible, and privacy would be an issue. If something involving bot edits could be tweaked, there's hope at least, but still. Otherwise it'd more be a cultural issue of people getting used to things all being 'public' in some fashion, like open sheet/etc. People play through google docs and on forums plenty -- adding edits to a page in a special 'scenes in progress' namespace that could later be moved to a private logs or public logs namespace if the visibility issue could be sorted would be pretty much amazing and not much different from that. Again, it's the whole visibility thing that's the largest stumbling block.

There are chatbox extensions, though I'm not sure how well any of them work; it'd be an option for something more real-time if so.

If I am ever poking at the original system thing again, I might try this in the more 'play by post' (play by edit?) format. I was able to get the basics (and the basics aren't very basic) of a +sheet together, and with original systems, every element on the sheet is clickable so you can see exactly what the power/stat/whatever does. (Not possible with copyrighted game systems, alas, unless it's something HR'd or just a reference to the book and page -- but even that can be a major help.)

I am definitely smug. But I get drubbed for it pretty often, too.

@Jaunt said:

I'm smug. Check. (a lot of folks here, including yourself, are)

It is worth pointing out that those of us (and I make no pretense regarding my own smugitude) around here who pull smug and survive are the ones who earned there way there -- here.

Even people with entirely legitimate cred and skill to back up their smug in an objective setting... tend not to fare very well. It's the same in any given community.

You gotta earn it, man. It's just a thing... everywhere.

@Roz In my dream world, there would be a way to set up a 'wiki in a box' similar to the way they used to have the Mux-in-a-minute sort of thing. A collection of settings appropriate for most games with info on how to tweak them, all the useful template bits set up for entering data easily...

There's the creative foo foo, which we disagree about, but man... if everybody didn't more or less have to re-invent the wheel every time on the basic elements we all need? Serious time-saver. Having a wiki at all is a pretty huge leap forward from ye olden days of angelfire -- -- but there's just so much more people could do so easily with them sometimes and I rarely see people using it much. Drives me crazy.

Just thinking about one of the convos that spawned this thread -- the Lights Out idjits -- they like anyone else could grab a set of openly-contributed stuff to just run with and tweak as needed/desired. It doesn't strike me as being too impossible to create a base setup and then batches of specifics for whatever setting -- like a 'if you're running a nWoD game, here's what you need' pile of files, etc. to add to a basic pile of 'here's a glossary of standard <game server> commands', and similar resources, etc.

@Roz I was so hoping there was a viable answer other than SMW, that's why I've been curious! (A lot of the template/dpl tools I'm working on I keep hoping to share with other places that want to snag them if they prove useful, and I know a lot of people are gunshy about setting SMW up, me included. Looks like it's time to bite that particular bullet, though.)

I was surprised to find that notation within the templates does actually work, provided there's none of the function symbols in the line; I'm surprised I haven't seen that done even just to break sections apart on longer templates. It's possible to get the help documentation right in the template to read along as someone fills it out, or edits it raw, but that's a two-edged sword: all the details for how-to can be there and include all the relevant info, but when it looks like a ton of text that can be massively daunting and make things appear more difficult rather than anything else.

I have a wacky pipe dream regarding some method of being able to enter things like new powers/merits/whatever through wiki templates and shove them over to the MUX, but that... well, while it would be helpful it would apparently be nightmarish to set up. (Only slightly less nightmarish with forms to prevent typo errors in some cases for necessary category distinctions or attribute names that have to remain consistent.)

I only know of about... 4-5 people, I think? that have even dipped their toes there much if at all, and that's including you and me in that total, believe it or not. I know of folks who have done mux/wiki sql things more often than digging into the parser foo, which is weird to me, but true enough in my experience. (Weird to me because I use templates for everything to an almost absurd degree for the speed factor and dpl potential and both of those things seem completely worth the time to set it up and do the whole day or so of reading to handle making a super basic template like the one above.)

I've also seen the cavalcade of WTF that the hybrid template/wiki code layout preloads generate in players, even if the functionality is neat. It was a lot of WTF. Bingo@Reno made a really neat page hybrid setup, and a lot of people have just grabbed their old ones from elsewhere and pasted them over because they were having trouble understanding how to work with it -- which is sad, because wow a lot of work went into that thing, and it's very neat.

BTW -- which forms setup or extension do you use? Because oh ye gods and little fishes, I know no matter how many instructions I include in-template, it's not going to help after a point.

@Roz I was wondering where that confusion was coming from, since you were talking about wanting to keep the data uniform.

A lot of the layouts people do that are 'fancy' cannot work the same way without a useless excess of code to display properly.

'Fancy' means you know CSS, and that's the long and short of it. That's twenty miles from knowing how to deal with parser functions. It's the difference between being able to use ANSI and 256COLOR expertly on a MUX, and writing softcode.

You can set up a blank preload for any of the fancy things -- but it's not a template, even if it lives in that namespace. It's the better option by far for anyone who wants to use that style of layout than an actual template would be.

@Roz Uhm... no.

That's a blank preload of a layout. It works off of an entirely different method of 'fill in the blanks' than an actual template.

These are templates. They work with parameters and parser functions are required to make them work properly if the data it's looking for isn't present. They are considerably more complex when it comes to make the data appear correctly on the page.

If you want all pages to look relatively uniform, you use an actual template. That template then has a preload you hook up to an inputbox, or people can cut and paste the preformatted list of parameters onto their page from the template page and fill it out.

You can hybridize the two, but people sadly tend to look at that and get woefully confused nine times out of ten; wiki code itself is difficult for a lot of people and the hybrids are especially confusing. Proper templates, conversely, are so extraordinarily simple to fill out as it is literally a case of 'fill in the blanks' since they're a list like this:

{{ Data
| title = display title
| type = Category
| text = text
| hr = no
| custom = no
}}

To sum up: sorry, but you're factually wrong on this one. Templates and blank layouts are not the same animal, even if people use the template namespace often enough for preloads constructed in this fashion. That's actually not really what it's for or what a template is in wiki terms.

@Thenomain said:

I think people are using 'templates' in a different way than what Mediawiki means, @Roz.

^ That, indeed. It's why I go with 'layout' instead, since what people use for character pages is not the same thing as a template.

Proper templates could arguably be made from any given layout, but that would involve a considerable amount of work in many cases, and some limitations in others that most folks would rather not deal with.

There's a real easy way to do it that doesn't even show up on the page, really.

<!-- Layout design adapted from X@Game's Wiki. (link) -->

or:

<div style="display: none;">Layout design adapted from X@Game's Wiki. (link)</div>

Well, almost anything is fine assuming 'there are no asshats'. We probably wouldn't need a system at all if we could count on that one. (So much wistful sigh.)

A 'system' for this needs not just game mechanics, but game mechanics and game policy working together, since both are functional parts of 'the rules' for this environment. It's not terribly different from the kind of rules that aren't in the book but that are present at any gaming table, like, 'Don't scream at other players or you won't be asked back,' or whatever that table's acceptable standards of behavior are. A lot of the stuff people get away with on MU*s would never pass muster at a table without someone getting dice bounced off their foreheads.

I may be misreading the general notion; I'm not super familiar with the specific reference, which is definitely a thing.

I don't know if I would necessarily place the marker at PvP and approaching a game in that way, though I think it gets to a larger issue.

Namely, 'what is this game about/for?'

The answer to that is going to vary from game to game and player to player. To some folks, it's absolutely about that -- but if you don't want your game to be about that, you also need to say so up front to avoid players who want that from the games they're playing.

I'm not real fond of the 'the first thing I consider when I meet someone is how to remove that character from play' mindset, obviously.

Recently, I (and so many others) ran into a player who proudly stated they were there for their own fun and if their fun stepped on anyone else's face, fuck them, they were going to do whatever they wanted and if somebody didn't like it, they could suck it up because they were playing wrong because -insert their personal interpretation of what the game is for/about and insisting it's a universal fact for all here-. If someone not wanting to do what they wanted cropped up, it was time to apply whatever IC and OOC force was necessary to get their way.

This is a glaring example -- and it's easy to point to that and say: that is a toxic presence on the game. (Yeah, now you know why I needed that info about sitebans... cough) Not everyone is that overt about their bullshit, though.

There's ways of having fun with PvP -- but it needs to more be CvC + Pw/wP. (PC vs PC + Player working with Player.)