Re: Seats

On Dec 30, 2004, at 7:29 PM, Roger Crew wrote:

> First of all, record keeping is NEVER going to be certain.
> You never really know who's standing behind the workstation looking
> over whoever's shoulder and giving advice.

Granted. I don't think any game system where the players can't 
physically see one another can avoid this. I don't foresee it being a 
huge problem, so long as we take the attitude the the story game 
records tell are more a suggestion of their players' relative 
abilities, and not a tournament-legal ladder. Furthermore, this 
information will be tempered by the reputation system (at least that's 
my hope).

> Note that you're already sweeping under the rug a whole pile of similar
> issues for the case of multiplayer games being won by alliances.

Mmmmaybe; it depends on what you mean by alliances. In-game shared wins 
among multiple players are actually accounted for in the current 
system, though there is no differentiation between an explicit team 
victory and some players who happened to place together at the end.

> Anyway, there are (at least) two easy solutions for version 1.0:
>
> (1) the game scores for "jmac;wrog" or somesuch canonical
>     concatenation of our JIDs.  This way, you get separate ratings for
>     every combination of people who've ever played a role together, and
>     there's no point in trying to break it down further than that.

Interesting idea.

> (2) the game scores for you since you were the FIRST person assigned
>     to the role; a nice, simple, arbitrary rule that does the Right
>     Thing in many cases.
>
>     In this world it's implicit that if I take over from you or play
>     along with you or whatever, you still get credit for whatever I
>     do, and if I have a problem with that, nobody's holding a gun to
>     my head saying I have to join in the first place.

That too, says the big fan of simplicity...

I was going to wring my hands a lot here about how this would mean no 
penalty for running away from a table on purpose (something I really 
want to discourage), but I think again the reputation system can work 
here, especially if you can change your stance against each player 
within a role, even for players no longer present when the game ends. 
So if our Mr. Hyde has a habit of bolting from tables when he's losing 
the game, then he'll collect a lot of 0s and -1s from his fellow 
players, even after games when a nicer person (or bot) fills his spot. 
(Aside: I'm starting to like the idea of not even bothering to record 
quits with the bookkeeper, trusting that other players will be 
sufficiently torqued off by purposeful-looking quits to damage the 
offender's reputation score appropriately.)

> For the longer term, you might as well let players decide for
> themselves who they want their games to be scored for.  E.g., one
> thought for version 1.1 would be to let players/teams declare a
> recording alias explicitly, as in,

Yes... I can actually see how record-aliases dovetail with the 
team/group concept, an interesting one which I have never really 
thought about before. But yeah: post-1.0.

> In particular, since connections won't always time out reliably -- or
> you'll get recalcitrant bozos holding onto a connection even though
> they're not doing anything -- you need SOME way, for the other
> (active/seated) players of a game in progress to free up a role, i.e.,
> to express SOME kind of consensus that the player(s) currently in that
> role is (are) taking too long, thus opening it up for someone else to
> take it over.

Yeah, kick-ability in general will have to be a feature later. Under 
the hood, the referee is the only MUC participant with admin powers, 
and has the actual ability to kick players out (and maybe even lock the 
table against them). But as for how players can influence this 
behavior, I'm not sure... sounds like it will need another subsystem.

> Given that, there also needs to be some kind of approval/veto over any
> replacement player(s).

See my previous list post, about using readiness for this. (Which I 
admit to writing and posting before I read this message all the way 
through, hence the "I just thought of this!" when, er, you sort of 
thought of it a week ago...)

> I certainly have no problem with keeping these Simple and Stupid
> for version 1.0, but you need SOMETHING.  E.g.,
>
> (*) any (seated) player in the game can clear any role

What do you mean by "clear"?

> (*) any player can join a vacant role of a game in progress
>     upon the approval of (or invitation from)
>     SOME (seated) player in the game

See previous post again. I'd rather that all players would have to 
approve of the newcomer, since, to me, a change in players constitutes 
a change in the game's setup, and every player should have to sign off 
on it, just as with the pre-game table configuration. I think we can 
re-use the very same approval mechanism that the game-start process 
uses.

>>   * There'd need to be a way to determine which actual players are
>>   allowed to "speak" for the role.
>
> Generally, there'll be no distinguishing players in a role.
> EVERY player in that role speaks for it, i.e., the referee
> accepts actions on behalf of that role from any of them.

This is the simplest answer, but I'm scared of race conditions where 
the different players in a single role issue several completely 
different turn-taking requests to the referee simultaneously. And a 
first-come, first-served policy would not work without further caveats. 
Let's say Alice and Bob are sharing a role, in a game where each player 
can do two things on their turn, out of a list of 10 possible actions, 
with the ruleset API defining a separate function for each action type. 
Alice wants to do move piece 2 twice, and Bob wants to do move piece 1 
and then have it attack piece 5. They both click things very quickly 
and at the same time. As things fall out, the referee gets game.move(2) 
from Alice, then game.move(1) from Bob, then game.move(2) from Alice 
and then game.attack(1,5) from Bob. What should the ref do?

One possible workaround: A design recommendation that ruleset APIs make 
all of a player's activity in a single turn expressible with a single 
function call. But are there times when this is not feasible? (I dunno, 
just thinking out loud...)

Or: The referee keeps a FCFS policy, and will only continue listening 
to game.* requests from the first-come player for the remainder of that 
turn. In the above example, Bob would get two apologetic RPC fault 
messages returned to him, while Alice's moves are both registered.

> If you're going to have "standing/seated" bits to generally
> distinguish observers from participants, then use those as well
> (i.e., only seated players in a given role can perform substantive
> actions however the game designer defines these).

Hmm, you're suggesting that a player can belong to a role, but remain 
standing? That's interesting... what if only one player per role is 
allowed to be seated?

>>   These may all be worthy features, but I don't feel they're necessary
>>   for the first pass... (I guess you could counter-argue that
>>   record-keeping isn't necessary to play games either, but I am, alas,
>>   married to that feature. :) )
>
> I'll readily admit I care a lot more about being able to finish a game
> than being able to record it.

Understood, and you are definitely in the majority. I don't think 
anyone else cares about recordkeeping nearly as much as I do. I think 
that it will result in some really cool value adds (cough) to the 
system, but it will take time to show its merit. In the meantime, I 
certainly appreciate everyone reminding me about more immediate 
features that I'm overlooking.

--
   Jason McIntosh             jmac <at> jmac.org
Somerville, MA, USA       http://www.jmac.org

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt