To be honest, I don't see the difference between "philosophies of game design" and straight up "game design". Worrying whether or not your game's code is automated enough is one of those things that I consider poisonous to game-playing, not beneficial to it. (Comment directly for the benefit of @Jeshin and @crayon.)
A Mush is a role-playing less intensive game (an RPLI).
j/k
@thenomain They're the same vein of people that argue about whether or not waterfall or agile would make a certain project go faster. The answer is: The project would already be done if you stopped arguing over which software design paradigm worked better and actually designed software.
@Thenomain
To me it's a university. That whole OR thread has been somewhat odd to read.
@Derp said:
@Ninjakitten said:
@surreality said:
These terms are for the codebases, they are the names of the codebases, not 'philosophies of game design'.
This is why I would like there to be a good, preferably not codebase-synonymous name for the general philosophy-of-game-design I favour.
So, like, player-driven storytelling community?
It's a start. I wouldn't call a game a community though, even though it'd be one. But player-driven storytelling is a start. MUD people might not like it, but then they already took roleplay-intensive for some of their kind. 
@surreality said:
I dunno... STG? (Story-Telling-Game)
...STM*? (Story-Telling-M-whichever-the-fuck)?
...STRP?
...hell, just call them STRIPEs, for Story-Telling-Intensive-Role-Playing-Experience and call it a day.
...ahahaha. I actually kind of like that.
Just to be clear here...
@surreality said:
I... have to shake my head.
These terms are for the codebases, they are the names of the codebases, not 'philosophies of game design'.
I don't call a black and white spotted cat a Holstein just because of their color patterns, either, and it's for a reason.
I actually agree entirely with you. I'm not trying to define what a MUSH is. When I say that the type of code doesn't matter so much as the design philosophy behind the game, what I meant was that it's a more important distinction for what we were discussing in the context as far as defining a scope of interest and focus in the OR community, and I get the feeling this has been getting taken out of context or misunderstood. As far as I'm concerned, it's a term for the base engine/codebase style and little else. There are some common approaches and some culture that's built around the codebase, but none of that is really integral.
But seriously...
Clearly Mush is a server code base.
What distinguishes it from other servers derived or inspired by TinyMud is the language used to program it online.
So Mush is also a programming language.
However, since you could program a Mush to implement any sort of RPG, I don't think there's much you can say about Mush game design.
This cannot possibly be considered 'out of context' when it is a straight-forward assertion concerning the development of Haven:
@crayon said:
[Haven's] design takes a lot of prototypically "MUSH" approaches
What is a "prototypically Mush approach"?
Something being a common trend or approach in MUSHes doesn't necessarily make it definitive of the genre any more than using 'levels' would be definitive of roleplaying games.
That said, most MUDs have built up a culture of roleplay around preexisting MMORPG style gameplay, and idealize a sort of "organic" approach where roleplay is something that occurs in a happenstance fashion. In a lot of ways it's clumsy and inefficient, but it's interesting in its own right.
On the other hand, many MUSHes involve a great deal more collaboration and organization of roleplay. This often allows for a lot more potential where storytelling is concerned, and focuses on player-driven stories.
While neither of these qualities is definitive of either genre, and at times both MUDs and MUSHes borrow ideas that have evolved from each other, or have gone through some degree of convergence, I think that player-driven storytelling is something that's significantly more common in MUSHes than it is in MUDs, in no small part because of a lot of the tabletop inspiration behind a sizable percentage of the MUSHes out there. Haven, for example, mirrors this in many ways with its Storyrunner system which encourages that sort of roleplay.
I'm not saying nor would I say that that makes the game a MUSH, but I do think it's an interesting development, and something I'd really like to see more of.
@crayon said:
Something being a common trend or approach in MUSHes doesn't necessarily make it definitive of the genre any more than using 'levels' would be definitive of roleplaying games.
A level-based role-playing game says quite a lot about it, so this is a bad comparison.
There must be something outside the code-base, else there would not be so much misunderstanding. Something cultural. Something persistent.
I think that player-driven storytelling is something that's significantly more common in MUSHes than it is in MUDs, in no small part because of a lot of the tabletop inspiration behind a sizable percentage of the MUSHes out there
Yeah, something like that. Maybe there's more to a code-base than simply the code.
(cough)Muck(cough)
@Thenomain said:
Yeah, something like that. Maybe there's more to a code-base than simply the code.
Absolutely. I wouldn't call it definitive, though. There are plenty of cultural trends in code-bases that have contributed to their becoming both engines and, in a sense, their own genres. I definitely think this creates a lot of misunderstanding and confusion, but this is basically why I'm more interested, personally, in categorizing games based on their design approaches and philosophies and the sort of gameplay culture they're trying to build than by their codebase itself. While the codebase may or even oftentimes says a fair bit about the game, it doesn't always and it doesn't necessarily. If that makes any sense?
I'd rather talk about a "Storytelling Game" or a "Hack-and-Slash Game" etc. than the MUD/MUSH classifications because while the latter can say something about the game the former doesn't really leave a whole lot of room for confusion.
@crayon said:
@Thenomain said:
Yeah, something like that. Maybe there's more to a code-base than simply the code.
Absolutely. I wouldn't call it definitive, though. There are plenty of cultural trends in code-bases that have contributed to their becoming both engines and, in a sense, their own genres. I definitely think this creates a lot of misunderstanding and confusion, but this is basically why I'm more interested, personally, in categorizing games based on their design approaches and philosophies and the sort of gameplay culture they're trying to build than by their codebase itself. While the codebase may or even oftentimes says a fair bit about the game, it doesn't always and it doesn't necessarily. If that makes any sense?
I'd rather talk about a "Storytelling Game" or a "Hack-and-Slash Game" etc. than the MUD/MUSH classifications because while the latter can say something about the game the former doesn't really leave a whole lot of room for confusion.
But then how do you distinguish a 'Roleplay Intensive Game' from something like that? If a MUSH is about having a player-driven storytelling culture, that's ... as roleplay intensive as it comes. Part of this thread's existence is to figure out what divides what a lot of us do from what you're looking for, and time and again, it seems like you're wanting 'a little something other', but we have no idea what this 'other' is because those sorts of games seem, to us, to meet all of the criteria that you present.
So what is this mysterious philosophy? This design that you speak of? What separates these two beasts?
Note I never asked people to give a definitive answer.
I'm very happy with the plurality that a Mush can be only a code-base, but also that a Musher is not interested in MMO-style gaming unless that Musher is also a Firanite.
Someone in some other thread made the very simple statement that to a Musher, role-play is the only thing. This is 100% true, even though it's very obviously not.
I've never really viewed a code base as determining the overall design philosophy of the game. I've been in MUSHes that have little to nothing to do with each other in terms of design philosophy or culture. I've been in MOOs that have almost nothing to do with the typical MOO, and seem more like the average MUSH.
Typically when I login to a MUCK, they're actually designed to function like MUSHes code-wise, which leads me to wonder why the hell they didn't just make a MUSH to begin with. I've also been in MUCKs that weren't designed to be like MUSHes (IE: Actually playable).
MUDs are all over the place. RPI MUDs tend to be my favorite, on the rare chance that I play one. I had no idea it was used to describe code, as Thenomain explained up there. All I know is that RPI MUDs usually mean it's all RP all the time on the entire grid. But I tend to be way behind on MUD trends and MUD culture in general (Except DBZ MUD culture, which is permanently stagnant).
Also I've found no discernible difference between a MUX and a MUSH, other than a few minor code things.
@Thenomain said:
Someone in some other thread made the very simple statement that to a Musher, role-play is the only thing. This is 100% true, even though it's very obviously not.
I don't feel comfortable about making blanket statements about Mushers. However I think it's reasonable to say that as a rule of thumb, the purpose of a MUSH is roleplaying and everything inside a MUSH is intended to in some fashion facilitate roleplay.
In that sense it's not the presence of automated systems that is important, it's the role of those automated systems that are important. RfK almost had enough automated systems to qualify as an independent computer game but all of that was to create more things to roleplay about. I never played on Firan but from what I'm reading in this thread it seems their systems filled the same purpose.
So far this looks very similar to the descriptions I've read about RPI's. The main distinction seems to be that in MUSHes the premise is that we're all players trying to tell interesting stories together while in RPI's we're meant to be characters living in a shared world. In MUSH OOC communication is encouraged because we're meant to be cooperating to have fun together while in RPI's OOC communication is discouraged because everything is meant to be handled IC through the automated systems.
I'd also like to point out that a lot of MUSH'ers also play MMO's, a lot. I know on most every MUSH I've ever been on there is at least one community of people playing EverQuest (1 and 2), WoW, TSW, Guild Wars, etc.
As for what makes a MUSH, it's the code. Plain and simple.
I can't code on MOO or MUCK, but I'd take a fair chance at coding at most of the MUSH derivatives. I wouldn't know where to begin on DIKU since I only built on Wheel of Time RP-MUDs in the early and mid 90's and never was a main coder.
As for design elements, anything CAN BE anything, that's how code works. We take the nuts and the bolts and we strap more on to make it what we want. Anything from Consnet Super Heroes to Dresdenverse to WoD to My Little Fucking Pony Sex.
So really, what makes a MUSH? Codebase. Knowing that these commands are going to work, because they are hardcode. It's not impossible to make a game no longer a MUSH by ripping out the code and putting in other things I guess.
What makes a MUSH?
@emit
That's it for me. If it's got @emit, page, @dig, and such... then it's a MUSH. Because Code.
."Automated games" are where interacting with the code IS the game play.
On a MU* if you played cards with a cards object, that might be the verge of automated play. If it could do solitaire it would be automated play.
Roleplay and storytelling, despite the genre of computer and consol games called RPGs, is related to players interacting with each other. Making choices to fit your own ideas of your character in a computer game with no other players is an emergent play style, though it exercises the same skills. However, you can do that with any activity eg "Here is the cunning yet powerful barbarian warrior, defeating the dishes."
For me, I think the big difference between MUDs and MUSHes (besides the obvious things like code, command, etc) is the level of gratification one can get on one versus the other:
MUDs: Pretty much instant gratification. There are mobs to kill and progress is more obvious. You level up as you play which makes a sense of accomplishment easier to obtain.
MUSHes: It takes a lot more work to feel like you're getting somewhere. First you have to find players to RP with and then you actually have to get scenes in, unless it's a game that awards XP even if you don't get IC. XP can be slow to obtain, making progress slow.
"Just leave me alone. I'm not myself. I'm falling apart, and I don't want you here." - ― Daniel Keyes, Flowers for Algernon
@Apu
Implies that XP is gratification. I can't tell you how many times I've ended up with more XP than I cared to spend and it was far out of sync with my own character progress. Most of them, for sure.
“If you wish to make an apple pie from scratch, you must first invent the universe.”
― Carl Sagan, Cosmos
@Thenomain said:
@Apu
Implies that XP is gratification. I can't tell you how many times I've ended up with more XP than I cared to spend and it was far out of sync with my own character progress. Most of them, for sure.
I think that to a lot of people getting XP is gratifying although I can't say why. Maybe they see it as a reward for all the time they spend on a game or something.
To be honest, I don't see the difference between "philosophies of game design" and straight up "game design". Worrying whether or not your game's code is automated enough is one of those things that I consider poisonous to game-playing, not beneficial to it. (Comment directly for the benefit of @Jeshin and @crayon.)
