Repurposing a Tabletop RPG for MU* Play

[The Sands]

@thenomain My first K.I.S.S. is mostly as a kindness to your coders. Having to build a CG system where there are 10 million exceptions is horrible. If, as an example, people can buy Disciplines outside their Bloodline, then make it all Disciplines. Don't create Strange Discipline-4 which is only available to Bloodline 17 unless every single Bloodline has a Discipline that only they can buy (at which point your coder will be able to commit to building a system that allows them to specify that a Discipline is special and can only be bought by one Bloodline). Having to add in code for just one single Bloodline that does something different from every other one sucks.

My second K.I.S.S. could arguably make things more complex. Now you have to write up rules for what it means when a person is intimidated, but at least now people will all know what is expected of them when that occurs. You won't get people just shrugging it off with no effect because they are so badass and you won't get people demanding that the other character has to do something unreasonable because they won the roll.

[surreality]

@thenomain said in Repurposing a Tabletop RPG for MU* Play:

And yet, we do. We love it. We want more of it. People over and over say, "I would love to play <rpg system> online!" that we should identify the challenges and methods of overcoming them so we don't end up with more WoD Tabletop Shoehorn Madness.

I'm going to say the dreaded words, Theno. I'm sorry. But I gotta, because... it depends.

I sincerely believe that sometimes it's not the system people want, but the game world. Again, WoD proves this in its own case: the tabletop system and the LARP system are very different; people enjoy both and many times the same people enjoy both.

That isn't actually about the system at that point -- it's about the world and it's general vibe that was made, because the system isn't the actual draw, as it's different in both.

You can even narrow this down further, because it isn't just setting and flavor (even if these things are bigger than I think they're given credit for in many cases). Look at what the game allows players to do. Not the mechanics of how they do it, but what it allows them to do. This is also a major draw for many.

For example, again, take the WoD setting. "I get to be a monster that eats people" is a draw for some folks. "I get to turn into a <something else>!" and "I can do magic!" and "I can be that human that discovers all of this stuff is real!" are the draws. If you set up a game that doesn't allow for their specific personal draw, those people are going to lose interest.

For plenty of us, "Be someone who has to contend with the realities of that different world and the challenges in it" is what we genuinely believe and what we'd intuitively answer. This makes it sound like that means everything is fine as it is on its face -- and it's true to a point, but what those challenges are and which people are interested in splits dramatically, and it's essentially the same as the '...but not... ' or '...but not without... ' elephants in the room that are being overlooked, and shouldn't be.

(Also, glad you didn't delete this post. It's a conversation I know I've tried to have here before and it's one I think is valuable for all of us to consider.)

[Thenomain]

@the-sands

My general coder response to that is: You worry what's best for the game, let me worry about how possible it is.

Yes, games without coders are harder to do, but it's entirely possible to run a game without detailed cgen rules if the sheet is easy enough for staff to glance and check off.

So really, make the game good for the players first, staff second, code last. And if the concern is making it so that it's easy to understand, then it will be easier to code, too, when someone gets to it.

--

edit: @surreality, You take more words to agree with people than anyone I know.

[surreality]

@thenomain said in Repurposing a Tabletop RPG for MU* Play:

The problem with "adapt to the players", while perhaps the most spot-on advice, is a lot of a Catch-22. Most people designing games aren't game designers, and by the time a game is up and running you can only hope you've set it up right, or that the systems you didn't create yet—or systems that you alter mid-gameplay—will be accepted by the players.

Double-post to add: I think you see more of this than you might think. It just isn't happening in the game once it's up and running as much.

That's another change in itself; a LARP that runs every 2-3 months has lots of downtime to make changes in a way a MUX can't, and even a weekly or biweekly is somewhat limited in that respect.

Some changes can be implemented mid-stream on a MUX, but it often doesn't go well. What we're more likely to see -- and I think we genuinely do see -- is people trying new approaches and new systems in limited fashion on various games, and the ones that work or work well, others will try to pick up and adapt and use as well on the games that follow them.

Even just looking at the stuff I know we were all working on off and on here and there over time, Reno1 had lessons for Eldrich; Eldrich had lessons for BITN; BITN will have lessons for their next projects, and so on. Each and every one of those games tried some new things, and we learned from them. People are keeping the ones that worked and trying to find solutions for the problems that weren't resolved, and dropping the things that didn't work.

It's similar to the LARP process, but the progress is harder to see because it occurs on a longer timeline and more cross-hobby than within the context of a single game.

For instance, there's stuff I want to use that are similar to WoD. There's stuff I want to borrow from @faraday's setup. There's probably other similarities to things I've read or heard about here about other systems, too, whether I realize it or not. There's concepts I want to steal from Shang in a preference-style setup. There's totally out there different stuff that I have yammered about for years that I think will work nicely -- but I will be the first one to tell you that I sure as heck don't know. The current project is, in part, a crash test of some of those ideas, and I make no bones about it. I got to crash test some of the ideas I had while on BITN, and some of them worked, some needed refinement to work properly, others seemed to be completely ignored, and that's all useful information for development going forward. (None of the stuff that was stuff I tossed into that mix failed spectacularly, but that would have been incredibly useful information, too; I was just the wiki witch, though.)

Basically, I think we're going through that same process -- it's just not as obvious or visible unless you step back to take a really long view. (Seeing that isn't easy because so many people want things now now now now now and too many people rush, or try to rush other people, but that's life in general.)

[The Sands]

@thenomain said in Repurposing a Tabletop RPG for MU* Play:

My general coder response to that is: You worry what's best for the game, let me worry about how possible it is.

The danger with that is if someone else has to maintain your code after you're gone. Lots of exceptions can make that difficult.

Honestly though, while I emphasized issues with coding I think it is only a small portion of the problem. Nearly always when you start doing things like saying 'well, this Bloodline is special and the only people who get access to the supa-sektrit Discipline it's because in the back of your brain you don't want everyone running around with it and the reason for that is because deep down you know it is unbalanced or broken (again, this doesn't really apply in a situation where you decide every single Bloodline gets an exclusive Discipline. In that case you are probably more interested in making sure each Bloodline feels unique).

Even speshul Disciplines aren't really the issue, however. The area you get into big trouble is when, as happens with WoD, you have one system by which the Vampires build their magical items, a second system by which the Werewolves build their magical items, and a third system by which Mages build their magical items. I'm not really referring to the specific rolls or conditions that have to be met to create the items but simply the mechanism that determines 'this is a 1 point magic item' and 'this is a 2 point magic item'.

When you do that you end up with one group that makes items far stronger than another, usually. Now this can be all right if that's the plan (e.g. You want Mages making more powerful magic items because that's their thang) but that usually isn't what happens. Instead the group that makes the strongest item is whatever group has the poorest written rules and there's no intent to who actually makes the strongest items. Instead, if you want mages to make stronger items then just give them some extra points to work with or something, but use the same system.

This is good for a variety of reasons. A) it is way easier to code since you only need to write the code once. B) It's one system with modifications so it balances against itself. Trying to balance three disparate systems against one another is a nightmare. C) Players who move from one sphere to another don't have to completely relearn the system.

Are these things 'simple'? No, not really. In fact I wrote up a magical item system for Fear and Loathing that people pretty much both Feared and Loathed and I'm sorry about that. I thought it was the best way to keep things balanced but I really was never able to find that sweet spot of design that people seemed to enjoy while providing what I thought was a good balance.

So instead I would call the principle K.I.C.K. (for Keep It Consistent, Knucklehead). If I had to 'redesign' WoD for a MU* I would probably do something like pick Vampire and then make the other spheres work in more or less similar fashion. Roughly the same number of 'Disciplines' for each sphere and the abilities of the respective 'Disciplines' would probably equate across the board (meaning that if the Mages have the ability to gain Roteskill on their rolls because of one of their 'Disciplines' then the Vampires would probably have some 'Discipline' that provides roughly the same thing. It doesn't mean everything is exactly identical. Werewolves don't need to steal Rage from humans. Mages don't frenzy. However there should be enough similarity that while someone in the Vampire sphere might wish they had some ability that only Mages get there won't be any feeling that 'Well, yeah, of course she threw 30 dice. She's a Sin-Eater'.

[Thenomain]

@the-sands

I’ll get to the rest later, but every coder must be willing to pick up someone else’s code. It’s a truism.

[Thenomain]

@the-sands said in Repurposing a Tabletop RPG for MU* Play:

Even speshul Disciplines aren't really the issue, however. The area you get into big trouble is when, as happens with WoD, you have one system by which the Vampires build their magical items, a second system by which the Werewolves build their magical items, and a third system by which Mages build their magical items. I'm not really referring to the specific rolls or conditions that have to be met to create the items but simply the mechanism that determines 'this is a 1 point magic item' and 'this is a 2 point magic item'.

None of this has to do with code. It will affect who can code it and how much time it will take but, here, think of it this way:

Code is nothing more than automating business/system rules.

This is also a truism. Code, like any machine, is there to automate a process. It's a tool, and like any tool its purpose is to serve the goal, not visa-versa.

You do want the right tool for the right job—TinyMu* coding larf larf—but at the very worst is the question: Is there a tool for this job, or will I have to create one?

Let's take some WoD game's (RfK's?) action point system. It did not need one single line of code to be a good system. It was a good system because it was a good system, and it someone stopped and said, "Is this going to be hard?", then it would not have been tried, and that would've been a sad thing.

I recently mildly chastised someone for not using my existing and complete, powerful, and almost easy to use Chronicles of Darkness system for their game. I said, "If this isn't the right tool for them, then let them discover their own needs on their own, that's fine." In fact, that's great. It's not like we absolutely need turn-around time of days or weeks. Months or years is fine, because this is something we do because we want to enjoy it.

So you want to do things that are best for the game first. Period. For some people that's going to be what code tools are available, for others they're going to start at "OTT" and go from there.

This is an extremely important topic for me because we need more games. If we're going to allow someone to look at a system they think is right for the game and say, "I don't have a coder, so nevermind," then they have unrealistic expectations on what it needs to get a game running.

1. Wiki
2. Roll code
3. Sheet code
4. Profit!

[The Sands]

@thenomain Ok. So I think I've still been operating about 5 degrees off the mark and now I've got a better idea what you're asking. I thought you had been asking what to consider modifying when converting a TT game to a MU*.

If, instead, what you are looking for is a way to package up a game and its rules so that people can quickly deploy their own game I've been thinking about this with Mocker and this is what I would do:

First, generate the system so that existing data items can easily be 'removed'. For example, if you are setting up a CoD codebase then make a couple of flags for the spheres. If someone wants to set up a game without Prometheans then they turn off the flag that allows Prometheans. No one can make a Promethean in CG, none of the Promethean commands show up when someone types +help. Flags can also be set for lower levels such as disallowing a particular Bloodline or Discipline because it is very common to have a game where Prometheans are allowed but Unfleshed aren't.

Store the data in SQL. Digging through data objects sucks. Provide php scripts so that staff can view and modify the existing data. Even without the scripts tools like MySQL workbench make editing the data so much easier it's ridiculous.

Of course since you are providing PHP scripts you'll need to setup a web server and since you're doing that you might as well provide a wiki. If you're installing a wiki you might as well install some basic templates such as a character template, a log template, and a house rules template.

I don't ask for much for my nickle, do I?

Is this the kind of thing you were looking for?

[Thenomain]

@the-sands

No, you got it right the first time. I'm asking what people need to consider as they are converting a TT ruleset to a Mu*.

What my long treatise was about is how code design isn't critical in this phase, and that you could make it non-critical for almost every phase.

[surreality]

@the-sands Though we speak very different languages (I am Not A Coder so 90% of what you're talking about sails right over my head -- half the time I would likely grok the principles but don't know the terms) a lot of what you're talking about is likely very similar to a lot of the stuff I'm looking at trying to do through mediawiki integration whatnots; it just uses a wiki-family as the means of integration and web forms instead of having people run any server-side scripts. (Though it's a bit of a tangent, please don't underestimate how intimidating command line fu is to anybody who doesn't do it on the daily. It isn't that people can't or aren't willing to learn some basics, it's that The Fear of Breaking Things You Don't Know How To Fix Again is very real, and is a real hurdle to a lot of folks.)

Basically, my one bit of generic advice would be this: what you're talking about probably sounds like the user (game runner, not player in this instance) interface is easier than what we have now (and it is), but it's still probably going to be a little more daunting to non-coders than you realize. In part, because just talking in code terms that people aren't familiar with is going to leave a lot of folks feeling lost from the jump.

This, too, gets daunting as fuck. Let's not even collectively pretend otherwise.

Writing documentation is a skill. Most documentation is written for people who already have some notion of what they're doing; I'm slogging through a few hundred lines of that kind of thing a day and googling my ass off because I'm a determined bitch, but I still get the throat-catch of 'I have no idea what they're talking about and even less idea what I'm doing, I'mma break shit'.

Writing documentation for a novice anything is a lot more like teaching than just taking notes, and that's a skill, too. (A fairly advanced one, too, because it involves a lot of examining internal assumptions and externalizing them as simple explanations without overloading someone with extraneous details. I think the entire forum is well aware of how bad at this I am personally, ahem. <cough> This is partly why I'm doing a web-interface for things: it helps cut down my novel-length treatises on why we won't be creating pages in the main namespace in surrwikiworld and so on, or at least set those aside as 'extended notation' that people don't need to slog through, and goes with something that's relatively intuitive for most modern internet users -- filling out a web form with drop down menus and whatnot.)

This is hard, so please don't take what I'm saying as mean-spirited or meant to be harsh in any way. Just... be prepared to provide simple explanations for folks of what all the code terms mean -- and I mean down to 'what is a php script' because not everyone who wants to start a game knows that or has someone handy and willing to help who knows that.

[Ganymede]

@bored said in Repurposing a Tabletop RPG for MU* Play:

To be clear, I'm not saying it's a doomed endeavor or anything. I just think we need to dig deep and realize we've basically built new games on the mangled corpses of their original incarnations. Repeating basic WoD-isms in every 'new' system is probably the quickest way to assure we have all the same problems, right?

And people wonder why I pushed the schedule out almost a year for what looks like a Chronicles of Darkness game. I whole-heartedly concur with this. And I think if people actually read the Chronicles of Darkness core book closely, it becomes clear that it is meant to give you a structure for your game rather than fill in every little nook and cranny.

Some games are easily to mold into something new. WoD 2E is pretty easy; FUDGE/FATE is even easier. Harder games may have systems as simple as the Storyteller System, like L5R, but there are massive hurdles to do so, including, but not limited to, the need for constant GM judgment calls, the waffle-nature of the Honor and Glory systems, and so on. For D&D 5E, WH40K, and Battletech, there's the map.

So, the title is really good: you need to re-purpose your RPG if you are going to turn it into a MUSH. Innovators like Faraday and Apos (and crew) basically made their own systems, and good on them to do so.