[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pbmserv-dev] A three-player connection game



Randall Bart observes:
> >Given a cycle, choose any point on the cycle (it doesn't matter where), 
> >and as
> >you traverse it, count the number of times it crosses each edge:
> >Let x = (# of times the path hits the right edge and appears at the left)
> >       - (# of times it hits left and appears at right),
> >Let y = (# of times it hits the top and appears at the bottom)
> >       - (# of times it hits the bottom and appears at the top).
> 
> Here I would define a third variable z=y-x.  Each variable is a function of 
> the other two:  x=y-z, and y=x+z.  There appears to be an asymmetry here, 
> because the variable after z is not x but -x.  Each variable in turn is the 
> prior one minus the one before:  -x=z-y, -y=-x-z, -z=-y-(-x), x=-z-(-y), 
> y=x-(-z).  Someone check my algebra, but I think I have defined a symmetric 
> pattern.

I was going to mention that adding a third linearly dependent variable 
or a third axis to the graph shows that the three players are in 
identical positions.  But, uh, I didn't.

> I don't think it's relatively prime.  I think (3,6) should be 
> possible.  Maybe I am wrong.  IANA topologist.  Writing the code which 
> detects and analyzes loops will be a bitch.

Gimme a while on that proof.  I pulled that out of something I recall 
from a topology class that seemed to indicate the torus cycles are 
nicely mapped to the rational numbers [(x,y)->x/y] plus the symbol 
'infinity' [(1,0)].

> Are you writing the code to detect this?

Um, not at the moment.  But all you would need to do is assign each 
connected group a base point, and each other point in that group gets an 
edge-crossing number relative to that base point.  Either before each 
move, or remembering them as the game develops, whichever is more 
convenient.

> >The parity method ensures that
> >every time this situation comes up, each player was involved anyway.
> 
> Is that a sure thing?  I think that only applies to loops of the same 
> order.  Are there situations where one move creates both a level 1 loop and 
> level 2 loop?  Level 1 and level 3?  Level 2 and level 3?

Okay, I'll prove this one for the parity method, since you prefer it and 
it's the easy case.  A move completing more than one loop at once must 
do so by connecting to three pieces of the same color not already 
directly connected.

  A .
 . - B
  C .

The orientation and order doesn't really matter.  If the spot in
question (hyphen) happens to be on the edge, translate the whole board
to avoid special cases.  Also, this is only the multiple loop case if
each of those three adjacent pieces connects to paths that go off and
cross some edges and connect to the other paths (so there's some other
existing branch point somewhere).  Now, we can find the edge-crossing 
numbers of the path A->B (that doesn't go through our new piece): 
(x1,y1).  And the path B->C gives (x2,y2); C->A gives (x3,y3).  No, 
wait.  C->A is the path C->B = (-x2,-y2) followed by the path B->A = 
(-x1,-y1).  That is,
x3 = -x1 + -x2    x1+x2+x3 = 0
y3 = -y1 + -y2    y1+y2+y3 = 0
There's some backtracking involved in the composite path, but it cancels 
itself out whether it's included or not.  Now if one of the ordered 
pairs is the non-loop (0,0), the other two are identical.  If two of 
them have the same parities, the remaining one has two even numbers, but 
the only such loop around is that darn (0,0) again.  And the way we 
defined the parity checks, the sum of any two different classes gives a 
loop in the third class.

Right?

> Are you writing the code to detect this?

So this is what I get for joining pbmserv-dev.  Fine.  I'll do it if I 
get three things:

1. The info (and permission?) on how to create and test games.
  1a. It has to involve a language I know; the likely ones being C, C++, 
      and Perl.
2. Examples of how other connection games (particularly projex, I think)
   are implemented.
3. At least two other players willing to try this.

I don't want to step on any toes concerning the existing Torus Porus, 
but I think that (a) the 'half-twisted' board could change things a bit, 
and (b) Chameleon-style moves could make an interesting alternative to 
forced alternation.  Actually, if I do put anything together, it'll 
probably support both -chameleon and -alternate.

Thanks all for the responses.
schep