My good friend Nate was kind enough to playtest 3 out of four of the pyramid games I posted yesterday (we didn’t play the party game), and the results shouldn’t be terribly surprising, but they were generally disastrous. In short, none are ready for prime time. (But on the upside, none were complete throw-aways either, and all have potential!) Here are my notes:

Action / Movement Programming — This suffered from the problem where the player has the advantage, so nobody wants to make themselves the second-to-last player. This meant there was little incentive to try and make the target shape. We did play with a pretty cool variant / modification where there are 9 “goal cards” (in a 3×3 grid), and any 4 cards in that group can be the goal. The rule about “modifying” the programmed cards was very confusing to Nate, and I had to clarify / re-explain it several times. There was also confusion about being able to modify pieces on the gameboard, and I think adding an action that would allow you to modify (swap?) existing pieces would probably help. None of this fixes the disincentivization to make the goal shapes. We talked about maybe not replacing the cards. Also, I just had the idea to maybe only take one of the cards instead of all of them, so most of the shape would still be there, but it would obviously need modifying. Maybe then you also get points at the end of the game for collecting “sets” of a single color card. We also played on a very large gameboard (not quite a full chess board, but it was with the triangular chess boards that are sometimes used for looney Pyramids), and I think we could have just played on a 4×4 grid, and it would have been a tighter and better game.

Action Point Allowance System — This game suffered from the rules allowing you to totally screw yourself. If you didn’t play a combination of either 1) two 2-pip pieces or 2) a 1-pip and a 3-pip, you were giving yourself a serious disadvantage later in the game. I think the rules should just specify you can play one of those combinations. Also, the player who played first had a huge advantage, not because they played first, but because as the rules are written, they also got to play last. I think making both players play only a 2-pip on their first turn might mitigate that problem. Another issue was that we played on a 3×3 grid, but never really used more than 4 towers. Another rule change I’m considering is to make the players fill the grid first, before playing higher levels on any tower… or possibly just to play on a 2×2 grid. (Or both.)

Area Control / Area Influence — Finally, as I’d hoped, this game seemingly has a lot of potential, but we ended up not playing it while we spent like 20 minutes discussing how the captures could work. (Rules as written do not specify capture rules, and I thought I’d just make something up quick about surrounding groups, and we’d see how it plays, but turns out there are too many different possibilities!) It would take me a long while to write all the things down that we discussed, but briefly, we talked about: Switching it to allow ONLY swaps of cards with pieces on them (then you could capture from a swap or a placement). Allowing piece movement to capture, with cards containing pieces of the opposite color “frozen” in their place, essentially “locking” neutral spaces on the gameboard as kind of a suicide move. Finally, if we allow swapping cards with pieces on them (which I think is a good idea), I think maybe it should only be allowed if they have the same (or possibly only if the opponent’s card has lesser) pip counts. Maybe that parenthetical should always be true, which would mean you could only move cards that have pieces on them, since by default all the cards start empty.

I don’t know when I’m going to get around to revising the rules as written, but hopefully in the not-too-distant future!

At least partially inspired by another BGG user’s lofty goal of 1 new pyramid game a month, around January 1st I had the even-more-ridiculously insane idea to make a goal of designing a new pyramid game for each game mechanic on Board Game Geek. There are 51 unique game mechanics on BGG, so that’s LESS than one a week. Totally do-able, right?!

Of course, I promptly forgot all about that idea, until I stumbled onto the first couple in my design notes earlier today. I spent some time subsequently flushing them out and writing a couple more, and so without further ado, here is a link to the in-progress results: pyramid games for every BGG mechanic.

So far (as of this blog post) there are only 4 rule-sets in a “completed” state. I have notes for two others, but they haven’t been written up yet, which means they may not even be playable. At least one of those not yet present require a custom game board (the one for Roll-and-Move).

This idea came, originally, hot on the heels of a renewed interest in pyramid games because I’d helped conceive and design these pyramid cards, a set of playing cards for icehouse/looney pyramids. (The card artwork, — ie, bulk of the work — was done by my sometimes collaborator August Brown.) At the time, I’d thought up a few different game ideas, but it turned out that none of them were really all that fun to play. A statement that may of course also be true about the ones in the link above. YMMV. Two of the designs listed below (and flushed out in the link above) use the cards. I think the ideas in the doc are better than the original pyramid card ideas, but they are still as-yet untested. Anyway, here are some brief summaries:

Acting mechanic — In this game, players take turns choosing a board game, and without revealing that game’s name, set up and play that game with looney pyramids. They cannot talk, and the other players must try and guess which game they are playing. Subsequent players cannot choose the a game that has been previously selected.

Action / Movement Programming mechanic — This game is a combination of seeing patterns in pyramids and using your hand to manipulate pieces on the gameboard. Game play happens in rounds where a “goal pattern” is decided, and players then simultaneously try and choose actions that will manipulate the board to create the “goal pattern” there.

Action Point Allowance System mechanic — This abstract strategy game is played with 4 action points per turn. (With the first player only allowed 2 points.) Some suitable small grid is chosen for the playing field, and each player takes a “stash” of icehouse pyramids and takes turns playing pieces onto the gameboard. At the end of the game, the board is scored and players win based on number of pips that are visible in their color.

Area Control / Area Influence mechanic — This 2-player go-like game is played on a board created with pyramid cards. Cards make up the gameboard, and pieces are placed to “secure” the territory. This is the game I’m most excited about / interested in playtesting.

I’ll post again about this project after I make more progress.

I had the pleasure of attending United Geeks of Gaming’s Game Designer Sessions event last night, and play testing the latest (third) iteration of a game whose working title has always been “workers”. I realized after a couple of games that the rules were a little “fuzzy”, seeing as how they’ve never been formally written down, and decided that some kind of documentation was in order… Hence this blog post. (Half rules formalization, half designer diary.)

Workers was initially conceived as a “born digital” board game with the central mechanic that there are a variable number of “resource pools” in the game, and every round each pool’s count of available resources is incremented by one. The name stems from it being a very light “worker placement” game, with the initial version allowing for only one action taken (worker placed) per turn. I’ll get into the various specific actions available when I go into details about each version of the game below.

The only other shared mechanic for all the versions of the game has been the turn / round mechanism. Each round a starting player is indicated, every player takes an action (or two) for their turn in clockwise order, and then the starting player indicator is passed to the next player (also in clockwise order).

Workers “One”
The initial version of this game remains the only one for which there is a (completed) digital prototype. I completed a very quick and dirty app to “prove out” the game mechanics in an evening or two of work and subsequently sent it to some of my TestFlight users for feedback and testing. The prototype was “successful” in that it convinced me more work was needed, but ultimately had quite a few design flaws, which I’ll detail in a minute.

As you may or may not be able to understand from the screenshot, there are 5 available pools of resource (yes, a hard-coded number, even though I knew from the beginning that I wanted it to be variable), as well as hard-coded two-players (with their resource counts on either side of the screen). In the center are all the available actions, and under the main resource pools (which double as buttons for taking the corresponding collection actions) are action buttons for selling each combination of two resource. This version has a selling mechanic whereby you can sell pairs of different-colored resources for the value shown on each pair. Between rounds, not only do the number of resources in each “pool” increment, but the point values for selling each combination are also incremented every round. When a player took a selling action they automatically sold all possible combinations of the two resources for the point value shown. (So if they had 3 green and 2 blue, and took the green/blue selling action when it was worth 5 points, the would end up with 10 points and 1 remaining green resource.) After a sale action, the value for that combination is reset to zero.

Available actions (one per turn):

• collect all of one resource pool
• sell a combination of resources

The game lasted a set number of rounds. (15 here, although I experimented with different values.)

Reasons this version is a failure:

• Replayability: essentially this game played the same no matter how many times you played it. This was pretty boring and led to an…
• Optimal strategy: it turns out, the best way to play this game is to keep collecting resources, whatever pool has the most, until the last two or three rounds of the game, then sell for the highest possible point combination. Boring and stupid. I could possibly mitigate this by capping either point values for selling, or total number of resources, either per player or per pool. Ultimately I never implemented either, and instead moved on to working on…

Workers II
The next version of the game was conceived to “solve” some of the design problems in the fist game by adding variability (via a game board), as well as removing the complex in-game scoring (the entire “selling” mechanic). I don’t remember whether removing in-game scoring was a goal in and of itself, or whether it was primarily meant to facilitate paper prototyping. I took this version to my first Game Designer Sessions meetup, (quite a number of months ago). The game was played at that time with decks of cards with different colored backs for each resource pool.

The “game board” consists of an empty grid at the beginning of the game. Grid dimensions (as well as “number of resource pools”, “starting player resources”, and “starting resources in each pool”) are meant to be variable for each game.

Scores weren’t known/calculated until the end of the game, when all the spots in the grid were filled with resources. I played with a couple of formulas for scoring (see below), but in general, I wanted the more groups and the larger the groups to have higher point values at the end.

Available actions (again, choose one):

• take a pool of resources
• play a single resource from your resources into the game board

Problem:

• One issue became evident right away, and that was lack of incentive to be the player who plays onto the game grid. After one play test, the player who sat back and hoarded resources was the clear victor. If I remember right, I believe we played a second game after the first and changed the “play on the board” action to take the resource from the pool rather than from your hand. Additionally, you got to take one resource from the pool into your hand as part of that action. I came up with another possible solution on the fly last night.

Workers III
The version I brought last night had basically one new mechanic: Every player started with a “x2” (times two) card face-up in front of them. There were two ways you could use this card, but when you did, you turned it face-down, and those actions were no longer available to you. I also play tested this version of the game with colored cubes for resources, which I felt was more visible (at a glance) than had been the case with using decks of cards, and had the added benefit of keeping the game board size considerably smaller. (I drew the game board out as well as “spots” for 4 resource pools on a single sheet of graph paper.)

Possible actions:

• take all of one pool of resources
• place a cube from your resources onto the game board
• use your “x2” action to increase the subsequent pool increment by one additional cube per turn (this could stack if multiple players did it)
• use your “x2” action to place a cube on top of a cube already on the game grid (increasing the size of that group by one without taking up a spot on the board)

We played a relatively quick game with 4 players, 4 resources, and a 4×4 grid, but less than halfway into the game I remembered the problem discovered in the playtesting of Workers II. I let the game play out, but suggested we play another game where you take two actions per turn, but your second action has to be a placement on the game board. One player left, so we played 3-players, 4-resources, on a 4×4 grid, but everyone started with one of each resource. I feel like this went pretty well, but still “needed something”.

Possible scoring mechanisms for multiple variable-sized groups:

• group-size times group-size added together
• group size added together times number of groups
• Fibonacci values for each group totaled, times number of groups

I have lots of ideas for Workers IV. I’ll post back here when I get a chance to try any of them out!

As a sort of follow-up to yesterday’s post on small-grid games, I realized that I haven’t made this pair of games public anywhere yet. (That I remember.) That post led to some Facebook discussion, where we got to talking about hex grids, and I mentioned that I haven’t seen any small hex grid games… but then I realized that I had worked on a design for one on-and-off last year!

Primitives is a relatively simple game where you place a card or one of your makers, or otherwise manipulate the gameboard. (I believe the last rules I playtested said you could do one of those per turn.) Manipulating the board means you could change a single card without a marker already on it, either by moving, rotating, or flipping it. By claiming a card, you “lock” it into place, and subsequently receive points for its symbols (and any matching symbols on adjacent cards) at the end of the game. The point values are dictated by the symbols on the center of the cards, either plus (+1 point) or minus (-1 point). Each card is double-sided, so flipping a card means it will change that symbol from + to -, or vice versa. The game ends when everyone has placed all their markers and all the cards are out on the board. More playtesting is probably needed, but I may need a rule that says something like: “If only one player has markers remaining, they MUST place it on their turn, and if everyone has placed their markers, the only available action is to place a card onto the gameboard.”

The first version was played with standard playing cards in a hex-like configuration. But I realized I could get more symbol matching in there (and more rotation) if I switched to hexes for the cards themselves. I also went from six symbols to three, for essentially the same reason. Here are some photos of various paper prototypes.

Primitives (version #1)

Hex Primitives (version #2)

These games were inspired by my playing Love Letter for the first time, and wanting to design a game that used a similarly ridiculously small number of components. (Love letter is played with a deck of 16 cards. Primitives is played with only 7.) I may try and bring this game to a Game Designer Sessions meetup tonight or in the future.