Ideas for Rules Gimmicks for Chatserver Play

[Robotech_Master]

I was just thinking about possible rules gimmicks for chatserver play, made necessary by the lack of visual contact.

For instance, a shorthand for making clear how many coins you have, and when you are spending them. In a "real life" game, you can look across the table, see how short on coins someone is, and know when he's about out, just in case you need to lend him some or something.

In a chatserver game, that would be harder. So my idea would be, in chatserver play, you

• start and end each statement with your current number of coins
• use a symbol, like #, to denote when you're "dropping a coin on the table"

So for instance, I might say:

<R_M> (25) It is a dark# and stormy# night#. (22)

Or perhaps if you're doing several lines at once, you can wait on the ending tally until you're done.

Also, in line with the "you can finish your thought after interrupt is called" rule, a player is allowed to type one line of text after it's called (to allow for being in the middle of typing something).

[Mike Holmes]

In IRC play, we've tried a few things to denote coin totals. The one I think that was most used, that I recall most clearly, was changing your nick to account for the total coins you have. So if on my turn I spend 8 of my 22 Coins, I go from:

Mike_Holmes_22

to

Mike_Holmes_14

Usually what people do is to finish up a turn, then go back and calculate their total expenditure, and then update their nickname.

On the subject of spending coins, we used one of a couple of methods. One is like you suggest, but we used numbers (so if somebody wanted to make a multiple level trait, they could type [3] or something in the line). This has the downside that you either have to put parens or brackets around the number, or risk people thinking that the number was part of the narration.

Another method people use is to, again, just wait until the turn is done, and go back and calculate expenditures. So they'd pass the turn to the next person, and while that person is starting their turn, they start writing out bullets like:

* Introduced Danny
*Added Fast Trait to Danny
*Had Danny Run to Lisa
Total 3 Coins

And then update their nick total.

The benefit of this is that you don't get slowed down narrating at all thinking about when you're paying for something, and where to denote it, and actually denoting it. The downsides are that it tends to lead to occasional overspending, and you have to type more. Faster, but more error prone and effort intensive. It also has the advantage that the record is often much clearer. If you denote expenditures in narration, it can tend to be unclear as to what you're actually paying for.

Like, let's say I write:

Danny, fast as always, runs to Lisa[1].

Is that one for the act to run to Lisa? Or is it a purchase of a Fast trait? Which one is color? There are two ways to get rid of this ambiguity. One is to list things after the fact, as mentioned. The second, if you want to do in line notation, is to denote certain things as being the thing purchased. So..

Danny, [Fast 1] as always, runs to Lisa.

The other advantage of the in-line notation is that a player can challenge immediately. In our example:

"Hey, you didn't pay to have Danny run to Lisa!"

Using the post-turn method, players can still challenge, but it may be a tad stale. It's possible that somebody may already have posted a follow on by the time the challenge happens.

Player C: "Danny kisses Lisa."
Player B: "Wait, Player A didn't pay to have Danny run to Lisa. Challenge! He's still on the boat!"

Sorta fortunately, the speed of IRC is such that such challenges can often still be timely (and the circumstances are rare enough anyhow), that this is not too much of a concern.


In actual practice, what we often saw was people developing their own notations as they went. Some would use one method, others another. That's why this is kinda hazy for me. We never had a single set of notations that everyone used. It may simply be easiest to propose all of this stuff, ask people to choose one, and just use it as consistently and conscienciously as possible to communicate what's going on.

I should also mention that the way we play IRC games off of the #indierpgs room has a particular nuance to it. We almost always use two rooms to play. One is the "OOC" room, for player talk, and the other is the "Nar" room for in-game narration. For Universalis, this means that you can narrate scenes in the nar window, while then indicating what you're paying for, and making challenges and clarifications and such in the OOC window. So, using this method, the question of which version is going to be less easy to read becomes clear; posting to OOC after narration is cleaner in sheer terms of reading ease.

That said, there's something to be said, again, for timely payment, and for inline indication of payment. Challenges aside, there's the question of interruption... is that color? Or is he paying for that? Do I let him get away with it?

There are other such considerations, as well. None of them are gamebreakers, however.


Lastly, on the interruption rule, yes, that's pretty much how we played it. I believe that it was technically one sentence (which follows the rule, technically). Which means, BTW, if you're going to interrupt, interrupt early. Otherwise that one line may contain a lot.

Abuse of run on sentences may have to be punished with Fee Challenges (but I've never seen such abuse).

Oh, also, I believe that we generally allowed folks to pull an interuption, if that one line turned out to change things such that they now don't want to interrupt. Like:

"Oh, he's running over there to kiss her? Not hit her? Oh, OK, cool, no interrupt, back to your turn."

There's just something about the speed of IRC play that makes this more important than in FTF play where I've never seen the need (not sure if I'd allow a "take back" in FTF play...).


I'm working off of your concerns, and that might be all of the modifications we did for IRC play. If I recall more, I'll post them. IRC play is generally "real time" enough that you don't need the sort of really substantial modifications for play that you see in asynchronous play like the Play by Wiki Post games we've attempted, or PBEM.

Mike

[David Artman]

Out of curiosity: How many chat clients support color text or bold/italics? And how hard/slow is it to format text as such when typing?

See where I'm going?
"Danny, fast as always, sprints down the battle lines and gives Lisa two Healing Vials he has saved from the retreat from the base. (Red + Red + Orange = 4 coins)

Using bold shows that there's a coin expenditure or, if black, "tags" someone as receiving a new Trait in the sentence (usually obvious, from context). So Danny is bold because he got Fast as a Trait in the narration, and Lisa is in bold because she gained two new possessions. But the base is not, because the removal of the two Vials doesn't create a Fact about the base (for instance, their removal does not create a fact that "there are no more Vials left there" or some-such).

The rainbow sequence--ROYGBIV--is the color-coding to set number of spent coins for each Fact:

COLOR	# COINS
Red	1
Orange	2
Yellow	3
Green	4 3
Blue	5 4
Indigo (Navy)	6 5
Violet (Purple)	7 6

[Is a maximum of 6 coins per individual Fact sufficient? I don't have a lot of Universalis experience to know how common it is for a single assertion to require 6 coins (not a single sentence, a single Fact in that sentence, as above).]

I found it pretty fast to do, here at The Forge's forums, because I just wrote out my assertion, then used double-clicked or click-dragged to select words/phrase and clicked the buttons to format. Typing time: about 15 seconds; format time: about 30 second. Could be MUCH faster if (a) the interface made choosing color easier or (b) you drop the use of bold and rely just on the colors to show coin use--although that means you can't use color for other functional purposes like, say, indicating a particular character's dialog or rendering negotiation conversation in a different color than actual narration.

Also, it should make it very easy to scroll up the chat history and spot all the Facts amidst the negotiations and color. (heh... The "Color" in Universalis' sense of the word doesn't ever get colored, in this method.)

Thoughts?
David

...AND Yellow sucks, so drop that from the sequence, against a light background; I have struck-out the problematic Yellow and re-valued the subsequent colors....

[Robotech_Master]

Some of those notation methods seem like they'd be either too complicated or require too much typing. [1] requires three separate keystrokes from two fingers, and bolding or changing color requires a chord at the start, and another at the end. If a lot of coins are getting thrown down, that's a lot of repositioning your hands midstream--which can be worrisome if you're worrying about getting interrupted in the middle of it.

Hitting a # symbol only requires one chord, and if you're doing multiple ones you can just hold the shift down and hit it more than once. It's nice and fast.

Danny, fast# as always, sprints# down the battle lines and gives Lisa two Healing Vials## he has saved from the retreat from the base.

[Mike Holmes]

Yeah, like I said, that's a downside. I wasn't advocating it, just saying that's what we did. Some just did numbers (sans brackets), but even if that saves a keystroke here or there, it still means looking for other numbers, so it might be easier to use your method.

My comments were really more about the differences between the in-text version, and the out of text version.

Anyhow, that said, most of this is moot anyhow, because, in fact, people tend to need to use a number greater than one pretty rarely. At least in our play. Much less than needing six colors we'd maybe occasionally need the second. Could just be for exceptions to say "more than one" where that could then be clarified elsewhere.

Mike