[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [piecepack] Re: piecepack design workshop #2: Stations v1.2 by Michael Schoessow
- To: <piecepack@yahoogroups.com>
- Subject: Re: [piecepack] Re: piecepack design workshop #2: Stations v1.2 by Michael Schoessow
- From: "Mike Schoessow" <mikeschoessow@...>
- Date: Thu, 20 Oct 2005 18:36:29 -0700
- References: <dj89qe+j24d@...>
Hi Brett,
Thanks for all the constructive comments. Comments like this, by players who do not know the designer and who are playing the game independently by the rules as posted are extremely helpful. See below for my replies.
----- Original Message -----
From: Brett Myers
To: piecepack@yahoogroups.com
Sent: Thursday, October 20, 2005 7:32 AM
Subject: [piecepack] Re: piecepack design workshop #2: Stations v1.2 by Michael Schoessow
Hi Mike
>>>I think it would be helpful to have a picture showing how there
>>>could
>>>be two disconnected networks. From the starting board
>>>position, it
>>>wasn't immediately obvious to us, only near the end of the game
>>>when
>>>we could seal off a pocket of roads in the middle due to earlier
>>>shifts did this rule make sense.
>>You do understand that a move that splits the network into two
>>separate sections is not allowed, right? I assume your comment
>>reflects the fact that, during much of the game, there are no
>>opportunities to make a such a move, even if it was legal.
>We understood that splitting the network was illegal - it was mainly
>a problem in visualization, I think. At first read-through of the
>rules, we couldn't picture a situation where one would be able to
>split the network, with the constant path around the outside. It
>became obvious later, in play. I think Mark was suggesting a
>diagram of a negative example in the rules, just to clarify that
>bit.
>>>It seemed as though a first-player advantage would be mitigated
>>>by the
>>>second player making the last move, which could be devastating
>>>(as in
>>>our game making every path doubled for me) with the first
>>>player not
>>>having a chance to respond and repair their network.
>>Yes, I am a bit worried about a first player advantage, but as
>>you note, there can also be a last player advantage. The way the
>>rules are presently written, each player takes an equal number of
>>turns in a game, so the player who went second does always get the
>>last move.
>>How do you feel about the number of "slide only" moves in the
>>end game? Did three seem a good number to you? Do you have an
>>opinion on number of end-game moves versus the powerfulness of the
>>last move? Perhaps I could add a rule concerning what can be
>>accomplished on the final slide, although I generally hate rules
>>that are obvious "fixes", especially if it's not yet clear that
>>anything needs fixing.
>To be honest, I didn't really like the slide only moves at the end.
>It felt sort of counterintuitive, after spending the majority of the
>game cleverly constructing my network, rationing a few of my
>precious slides to try and block my opponent when possible, to then
>spend three turns actively attacking each other or desperately
>repairing my now-ruined network. Of course, that may be part of the
>appeal for some.
My recollection is that I added the three slide-only moves per player at the end because I thought they might lessen the last-move advantage. Certainly the last player has a chance to spoil the other player's scoring possibilities when he can make the last slide, but it seemed to me that this was not as potentially devastating as making the last slide and then ALSO adding the last coin on the same turn, so I decided that a "buffer period" of sliding-only would even things out a bit. I agree with your implication that the "three sliding-only moves per player at the end-game" lacks elegance. After reading your comment an idea has occured to me. I could get rid of the three sliding-only moves and then add a rule that says the player who moves last in the game may either place a coin or slide a tile but not both. How does that sound?
>>>I didn't try any variants, but I would be in favor of having the
>>>standard game be the old Variant 2, where all coins are worth
>>>1, and
>>>plan to try that version out next.
>>If you do try that I would be extremely interested in how you
>>thought it compared to the version you tried, since I haven't yet
>>decided for sure which version I want to make the standard version.
>We didn't go over any of the official variants when we played, but a
>couple of ideas did spring to mind that I would like to try out.
>1. A player may not slide a tile that holds his opponent's station
>(pawn or coin). This may add some tactical opportunities for
>station placement, and would provide a strategic use for the null
>coin beyond simple bluff-placement.
When I was designing the game, I assumed that this rule would restrict tile sliding too much, but seeing you mention it now, I'm having second thoughts. In the early stages of the game there will not be many coins placed so it wouldn't restrict things much. Then, as the game progressed, the increasing restriction could be a good thing, because by reducing the chaos caused by the sliding moves it could increase the potential for strategic play. I'm definitely going to think about this more.
>2. On his turn, player may either slide a tile or build a station -
>never both. This variant would need a game-end trigger - I'd
>suggest the final round is triggered when one player has placed his
>last station. Both players may then take one final turn before
>scores are computed. I would like to try this variant with the
>above variant.
I did think about this one, but my intension was to design a quick game and I really liked the forced convergence of the "place a coin each turn and when they're all placed the game is over" system.
>Granted, these are a fairly radical departure from your original
>rule-set, but that's the spirit of the PiecePack!
Absolutely.
>Finally, I have some observations about the clarity of the rules.
Regarding your rules observations below, it appears that you are playing according to the rules as they presently appear in the rules-in-progress file for this group. There's nothing wrong or unexpected about that but, over the past 2-3 weeks, others in the group have pointed out that my space counting scheme was, shall we say, unique :-) I plan to change it to one in which corner spaces are counted when going around corners, as suggested by a number of people (OK, all the people who tried the game). Each space moved through is counted. This makes it the same as in Alien City, for which there didn't seem to be any confusion. I plan to re-do the figure and add at least one additional figure to make things more clear.
>1. The rules say that a station can only be accessed from the two
>adjacent sides of its tile corner, but the diagram in the lower left
>of Figure 1 only counts 3 spaces to access, which would put the
>access point on the diagonal space.
>2. On a similar note, the counting of spaces only recognizes the
>diagonal "intersection" space when crossing directly over it. The
>center diagram counts 4 spaces to access, skipping the diagonal
>space, while the rightmost diagram counts 5 spaces to access,
>including the intersection space. Shouldn't we count 12 spaces of
>distance around an unblocked tile perimeter (2 per side, plus the 4
>corners)?
>3. Can a player slide a tile in such a way that it pushes another
>tile?
Nope.
>For example, referring to the diagram in the upper left of
>Figure 1, can a player slide the lower tile upward, pushing the
>already-adjacent tile 1/2 width as well?
Nope.
>I hope I've been clear and not too pushy in my suggestions!
>Thanks for an interesting game,
Thanks for the suggestions and insight. The design workshop has worked exceptionally well in the case of Stations and I feel that it has significantly improved the game and the instructions.
-Mike
>Brett