You and I both have gone off the handle trying to explain to people that without modifiers, nWoD is nothing. Situational modifiers are the blood to the attribute + stat muscular structure.
Mind you, I'm sad that this thread has been mired back down into WoD-Centric discussion.
@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.
I’ll get to the rest later, but every coder must be willing to pick up someone else’s code. It’s a truism.
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.
Linear vs. Scaled advancement costs.
Neither is bad. They each do their thing.
I know conversation has gone a bit beyond this, but I think this was important enough to say in just some quick bullet-points.
So let me see if I can boil that down to something more generic:
And to summarize @Pyrephox's post:
Going backwards and trying to make the most of people's responses to my vague beginnings:
Going to pause on that last one.
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.
I deeply believe:
This is a lot easier to say than do.
Looking at it this way, patterns are starting to emerge, which is good.
I apparently did get drunk enough last night to not clearly know what I was doing, so I accidentally deleted only the starting post, thinking it would nuke the whole thread. By the time I realized this, enough other people had responded that I figured I'd leave my shame up for everyone to see.
Alcohol saves civilization.
--
The purpose of the thread was to see what people saw as shortcomings in using tabletop RPGs as the basis for a Mu*, and what they'd look into in overcoming it.
The complaint that we're trying to shove a square peg into a round hole came up multiple times in both the Social Systems thread and the Min-Maxing thread, so the logical question that follows is: Okay, what do we cut or add to that square peg?
This is what I meant, yes:
@bored said in Repurposing a Tabletop RPG for MU* Play:
If I'm understanding correctly what you're asking, I think before you even start going into individual systems, you'd want to identify the relevant elements of play that differ between TT and MU. I'd argue that these are so wildly, often fundamentally different that we're not even close to playing the same games, which of course highlights the oddity of using the same systems.
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.
@misadventure said in Repurposing a Tabletop RPG for MU* Play:
Maybe give an example of a part of a game that in particular doesn't translate well so is often ignored or altered?
I specifically do not want to talk about specifics up front, because I feel it would poison the conversation for people who want jumping-off points.
@bored sums it up. Most of the time it's Aspects, which is also Fate's strongest or second-strongest mechanic. (I can't decide if I like the skill pyramid more. I think I do. Though how Dresden Files handled fate points and stunts still enamors me for its elegance.)
And saying "Fate is Fudge with bells and whistles" is like saying "a car is just four wheels with bells and whistles". Fudge is a system upon which you might be able to build a game. Fate is a game system.
I have more hills to die on than Rome. 
@ganymede said in Game Design: Avoiding Min-Maxing:
WoD 2E fixes this by making costs linear.
Thus making it trivial to dominate a stat pool.
I know you know this, but I'm using this for everyone as a way to say: Do not look at just one part of a system as a way to fix a problem with a system. The second thing nWoD did was reduce the XP gain. By four fifths.
And more or less doubled the number gained per session.
So what got changed wasn't the number of xp spent, but the entire xp gain and spend system.
@lithium said in Repurposing a Tabletop RPG for MU* Play:
@thenomain Easy to understand rules for conflict resolution, or at least something that people can point at and go: Rules say this.
And the Rule is the Rule.
Except the rules are made for small-group gameplay.
I honestly thought this was a viable discussion after another thread banged on about how TT RPGs were not meant for Mu*s. This is true. This is a problem. And yet, even starting this discussion is more trouble than it's worth.
I will be deleting this thread shortly, because if I have to fight just to get people to talk about what's in the topic title, it's not worth it.
I'm not interested in what already works. I'm interested in what doesn't, and how to fix it.
So, y'know, fuck it.
I'm really not asking about the coding side of things. This thread was borne about because people were talking about how tabletop games are not designed for Mu*. "Have a sheet" is a given. "Roll dice" is a given.
What do we need to do to make sure that people have things to do, that people are involved, how do we take what is a small-group game session and make it available to a larger number of people, with and without GMs?
It's a game design question. What game design considerations are involved?
I am practically drunk right now.
I am doing this for two reasons:
What do you need to consider in turning a tabletop RPG into a Mu*?
@roz said in Game Design: Avoiding Min-Maxing:
@surreality I'm sure. My big objection in this particular argument isn't really about the system. It's about the attitude of "blame the newbie for not knowing the 'common sense knowledge' that WoD vets have."
I once exploded at staff who were being smug at me on Dark Metal (surprise, I know, right?) because I wasn't doing something right, and was being more-or-less punished for it.
I told them that it's staff's responsibility to make sure that the game is being played in the way that staff wants it to be played.
That was over a decade before. I only think it's more true today.
Okay, what would people say are the things required for tabletop RPGs in order to get them ready for online play?
WoD included, but seeing that people want to try things like City of Mist, by no means is it the only one.
Yes, each game has its own list of specifics, but what in general do we need to look into? (Fun Fact: The Arx skill system is originally based on 7th Sea and and Legend of the Five Rings, so don't tell me it's not possible.)
@saosmash said in Game Design: Avoiding Min-Maxing:
Every time we have one of these conversations, these are exactly the attitudes that confirm why I tried WoD twice and now never shall again.
Sometimes it's hard living down sharing a space with other fans, isn't it.
So in the traditional communication cycle, which is a cycle, the "feedback" step is used to discover and hopefully correct errors in communications.
I'm just throwing this out here. You know. No reason.
@sockmonkey said in Game Design: Avoiding Min-Maxing:
Should there be +census for attribute and skills so players get a sense of what the actually playerbase spread is?
This is best for non-newbies. This is a good tool for people once they get a sense of a game, tho, and can be used to help newbies via their experience.
(Which is the #1 Best Way To Help Newbies.)