Players 4
Length 20-30 mins
Equipment Required one standard piecepack
Designer Mark A. Biggar
Version 1.1
Version Date 2004-07
License Copyright 2002, 2003, 2004 Mark A. Biggar under the GNU free doc license


Every year on the summer solstice the male yeti in the Himalayas have a contest to determine which one will be the head of the pack for the next year. This contest consists of a game of “King of the Hill” combined with a snowball fight. A yeti wins by being the sole occupant of the mountain peak for a full round of the game. Avoid the snowballs and don't fall off the cliffs.

This game uses a multi-level board of stacked tiles as the mountain and a Roborally like programmed movement system.

Following is the board, with the numbers showing the thickness in stacked tiles and the thick lines showing the cliffs.





Design Notes

  1. This game is based on some of the ideas from my essay on Programmed Movement in piecepack Games.
2. I had originally thought to do a Battlebots game, but eventually came up with the wacky idea of yeti playing "King of the Hill" during a snowball fight.
3. Having two types of attack on your opponents adds some interesting tactics to the game.
4. the 3-D board was the hardest part of the design.

Reviews & Comments

Session Report from RonHaleEvans

OK, here are a few points about Everest:

  1. I like the fact that the tick marks on the coins are relative to the board and not to the player, as you state in the rules. In Roborally the direction cards are actually relative to the _robot_, so it's hard to keep them straight. This way is much easier and less frustrating. However...
2. That means it's really easy to move around and get to the top quickly. Tim Schutz and I played a 2-player game last night, and I won on the second turn. I got to the top on the first turn; Tim miscalculated and couldn't stop me. He managed to get to the top on the third action of his second turn, but by then it was too late.
3. There was some question about whether he would make it to the top or whether I would knock him back with a snowball first. We couldn't find the rule about how to resolve action conflicts. It turned out I would have won either way; even if he had made it to the top, that was the last thing he could do on his second turn. In any case, the rule about resolving action conflicts needs to be emphasised, maybe broken out into its own section for easy reference, instead of being buried in the "Executing the plans" section.
4. Other things that need to be emphasised and clarified: "steps" are 1-high, cliffs are 2-high; you can push another yeti up a step but not up a cliff; under "Yeti Movement", you should reiterate that a yeti that falls off the board goes back home but does not heal; under "Roaring", in the phrase, "it must also make a die roll and acts accordingly", "it" refers to the other yeti.
5. Questions: Can Yeti A at the top of a step hit Yeti B, one square away at the bottom, with a snowball? What about a cliff? What if Yeti B is more than one square away?
6. Under "Making a Plan for your Yeti", you state, "a coin showing the ace-5 [this is unclear, BTW--Ron] specifies that the yeti will move that many steps in the direction shown by the tick mark." This is incorrect: the yeti will move that many _movement points_ in that direction; for example, if the yeti is next to a step, it will move only two squares because 1 MP is expended climbing the step. Or am I missing something?
7. In general, the board is so small that "30-40 min" is an overestimate for game length. Once we figured out the rules, it took us probably 5-10 minutes to play. This may be because it doesn't work as a two-player game, but I'm afraid that even in a four-player game, three people might be tied up in fighting while one person gets a clear shot to the top and wins on the second turn or shortly thereafter.
8. It would be helpful if you could clarify where to put the yeti in two- and three-player games; we put ours diagonally opposite each other to start, which may be one reason I had a clear shot.
9. Since there's a chance that a yeti will automatically roar back when roared at, there's a possibility of "roar cascades", in which yeti roar back and forth several times in succession (I think). The rules need to be clearer about what happens in this case.
10. Perhaps placing obstacles on the board (such as unused coins in games with less than 4 players, which need them more anyway) might slow things down a bit and make things tougher to figure out for the players.

Overall, I enjoyed this game, even though I hate Roborally. I think having the tick marks be relative to the board rather than indicating which way the yeti turns helps a lot. However, it may make things too easy on the players, so the board might need to get more complicated.

Keep up the good work!

Quoted from piecepack mailing list message #580

Designers response: Most all of the issues Ron brought up were addressed in the ruleset rewrite done prior to putting the ruleset up on the BigBoard, but I'll address them again here.

  1. It's hard to make the instructions relative to the pawns when they don't have a front side to be relative to. :)
2. I have sense decided that the game doesn't work well with only 2 or even 3 players so the current ruleset says that it only plays with 4. In addition I changed the winning conditions so that a yeti must start and end a full round alone on the summit, so you can stop a win simply by ending a round on the summit with the leader.
3. The ruleset now has a reasonable method for conflict resolution.
4. These are clarified in the ruleset rewrite.
5. Yes, yes and no. Fixed in new ruleset.
6. Ron is correct, the number on the coin is the number of MP's, not spaces moved.
7. With 4 players the game does go on as long as stated.
8. See point 2 above.
9. Fixed in new ruleset.
10. I think that the board is too small for additional obstacles.

Thanks for your comments -- Mark A. Biggar


BGG page: http://www.boardgamegeek.com/game/21353

CategoryGame ThemeMiscellaneousCategory RaceStrategicCategory MechanicProgrammedActionsCategory MechanicMovementPointsCategory