Category Archives: Game Design

pyramid games for every BGG game mechanic

Posted on by

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).

pyramid cards backThis 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.

creativity is hard — tips for playtest feedback

Posted on by

I was musing on game design this morning, and came to a conclusion that I already knew both intellectually and intuitively, but one that I’m not sure I’ve articulated to myself previously: Game design is a creative endeavor. (With all the subjectivity and painful process woes that plague all creative endeavors.)

I’ve always just made games that I myself wanted to play, avoiding the entire camp of game design that suggests your players should be influencing your design. That may sound like an arrogant position to take, but at first it was borne more out of laziness and ignorance than anything else. Until I attended my first GDC in 2012, I didn’t even really realize there were people whose job was game design, and I certainly didn’t realize there were books written on it or — more importantly — people thinking about it academically. It was that revelation, more than any other, that has kept me going back to GDC; I find immense value in immersing myself in game design topics opinions and thinking for a week, not to mention all the networking opportunities.

But anyway, aren’t I also a player? In my opinion, I’m a player whose wants and desires are seriously under-served. (That means my games are probably for a small segment of the market, and I’ve made peace with that. I’m not looking for commercial success… if it finds me, awesome.) I’m not going to cave to the pressure to make games for someone else. Because essentially I feel like that’s compromise. And I think compromise kills art. My vision is no more important than anyone else’s, but it’s also just as important as everyone else’s. And hey, I’m the one making it.

So is this all one big excuse for not accepting constructive feedback? Partly, yes. These thoughts all come in the wake of showing off a new (-ish) board game last night at a local game designer meetup. I haven’t talked about this game publicly before, and this whiny blog post is probably not the place to start, but it was not received well. (In spite of many — at least 10 — fairly successful playtests previously.) Mostly, the feedback last night consisted of ways to change the game entirely, ways to take it in some other direction. Essentially, the playtesters (game designers, but for one) didn’t enjoy the game, and spent a good fifteen minutes after their play trying to brainstorm ways to “fix” the design. Almost all the player suggestions last night involved tearing up the design and making something new out of the pieces. This is something I’ve already done with this particular design at least three, maybe four times so far, and I’m actually very happy with where it’s at right now, so that option is not really on the table.

It’s hard not to take this kind of feedback personally. (Made more difficult by at least one of the designers in question having a lot of problems keeping his feedback constructive.) The whole experience really threw me for a loop, and I spent this morning struggling against an impulse to just put the game away and not think about it for a while.

Perhaps I can salvage this piece by adding a few bullet points about giving constructive game design feedback.

  • Be thoughtful — Generally speaking, think before you speak. As best you can, it’s a good idea to form complete thoughts before you speak them. If you’re offering up specific “fixes” for a perceived issue, make sure you articulate that issue before you offer up your solutions. Think about why something is a problem before you say it’s a problem. General “impressions” are generally not that useful, better to back them up with a “why” or a “how”.
  • Be courteous — Nothing invalidates your feedback quicker (or makes it harder to hear) than an insulting statement. Make sure your feedback is about the game, and cannot be construed as a criticism of the designer. In general, if it’s not nice, try hard to think of a way to say it nicer.
  • Context is everything — Ideally the game designer has asked for specific feedback points, but even if not, it’s probably worth asking some probing questions before getting into a torrent of specific criticisms. There are several “levels” at which you can talk about any game. Is the designer looking for feedback about the overall systems used in the game, or are they looking for feedback about specific components or balance issues?
  • Be specific — “I did not like this.” is not, by itself, useful feedback. Generally speaking, the more detailed you can be about why you didn’t (or did!) like something the better. If the designer was paying attention, they probably already know whether you were enjoying the experience.
  • Stay on topic — I’ve found that “after playtest discussion” can easily veer into a speculative realm of what-ifs and imaginary games that could exist. This is especially true with game designers. Try not to be the one leading the discussion away from the current game.

Workers, Workers II, Workers III

Posted on by

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”
Workers Screen Shot - game startThe 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!

Primitives and Hex Primitives

Posted on by

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)
20140325-145301.jpg20140325-142342.jpg



Hex Primitives (version #2)

20140325-142311.jpg20140325-142258.jpg



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.

games I wanted to make for Ludum Dare 28

Posted on by

So another Ludum Dare has come and gone. (The 28th Ludum Dare, although don’t ask me why the twitter hash-tag appears to be #LD48, rather than the equally noisy #LD28, because I can’t figure it out.)

The theme this time around was “You only get one.”

I saw the theme on Friday (on twitter, of course) and being “aware” the game jam was happening, spent much of that night (in between and around playing board games as I usually do on Friday nights) thinking about what kind of game I would make for it. I idly wondered how many Highlander or Lord of the Rings games would get made over the weekend, although browsing the (approximately 2000) competition entries, I have yet to see any. (I have looked through far less than a representative sampling, however.)

It was Saturday afternoon before I decided I definitely didn’t have enough time to participate, but I was still thinking a lot about game ideas. At that point, I had narrowed down the infinite paths in my brain to about two game ideas. Who knows, if I’d had enough time to actually make something, which one I might have latched onto.

First idea: touch-and-drag math game

I’ve been thinking lately about games that I characterize as “math puzzle games”. Some app store examples are Drop 7 (very early example), 10, Nozoku. I think some of the inspiration here is seeing the updates to my friend Roger’s Nurikabe app, Nurikabe Vault, as well as seeing some twitter buzz around Asher Vollmer’s forthcoming Threes.

Anyway, the game idea is essentially a grid of empty spaces that slowly fill up with numbers and math operators. (0-9 and +, -, x, %) The goal would be to “remove” those numbers by sliding over an equation that equals exactly 1. It would start easy with lots of 1s, 2s, 3s, and +s and -s, but eventually end up more difficult. Of course the speed of numbers and symbols appearing would also need balancing. This idea is simple enough I could easily have made it over the weekend. I may yet do up a prototype, we’ll see.

Second idea: local multiplayer

This is clearly inspired by all the thinking I’ve been doing about local multiplayer games, (which deserves its own post some other time), but essentially the idea here is a “get the man with the ball” type game. These are not uncommon and I would not have pursued it without adding some twist or spin on it, but I’ve been really wanting to make a game or two that uses 2-4 PS3 or XBox controllers plugged into a computer. (With the eventual intent to showcase the game in an arcade cabinet somewhere, again, more about this later.) I didn’t actually come up with (enough of) what would make this game super different from every other game with a mode like this, but I was thinking maybe the “thing” you carry around gives you some power, (like a sword that gives you the ability to fight off the other players, or a teleport on a timer or something) and that would be randomized between “rounds”. Again, not a super unique idea or anything, but it fits with some of my personal short term goals.

(Thanks to Gavin Bowman, who inadvertently encouraged me to write this post.)

Game Design: For Science

Posted on by

zooniverseSo, I’ve been following the Zooniverse projects for a while now, ever since the retired “Galaxy Zoo” project. For those not familiar, the Zooniverse projects (you can see a list of current projects on that link to their homepage) are basically crowdsourcing science. Each one takes a relatively focused (and menial) task that would take a researcher or research team years to complete, and makes a pretty simple web interface that allows “citizen scientists” to participate. The tasks all appear to be (at least from my limited experience — I’ve only done two or three of them) mostly image recognition of one kind or another. Interestingly, in the Zooniverse Reddit AMA (ask me anything) this afternoon, I learned that one of their retired projects was used to successfully train a computer to perform the tasks that the humans were completing, and thus, the project is no longer needed. That is some pretty cool computer SCIENCE.

Until today, I hadn’t given much thought into the people behind Zooniverse. But when I did think about it, I sort of assumed it was like rocket science — in other words, impossibly hard tech-wizardry. Reading the AMA where the team answered questions about quite a lot of their projects and process was for me a humanizing experience, striking home for me that, much as scientists are real people, (not superhumans), so too are the people who make really amazing software that advances science (also not superhumans).

As an aside, I think I have sort of an inferiority complex when it comes to “real” scientists. Not that I don’t know a few here and there, I do have a healthy smattering of PHDs in my facebook friend feed, (who for some reason don’t count). I think of “real science” as this thing that you have to be WAY smarter than me to do. When, in reality — or anyway my newly rationalized version of reality — I am now trying to internalize the idea that much of scientific discovery is not “breakthroughs” and genius-level eureka moments, but rather made up of tiny incremental observations and discoveries. Maybe this putting scientists on a pedestal comes from reading too much science fiction where there is a lot of hand-waving around what happens when the big breakthroughs are made. (This is actually something I do occasionally fault science fiction for, one of my pet peeves is when some near-future science fiction novel’s plot hinges on one or more breakthroughs that completely disrupt modern society, yet we’ve never heard of them before.)

Anyway, the Zooniverse projects aren’t quite gamefied, at least not in a competitive sort of way. I’ve “helped” a bit with a couple of the latest ones, and some of them give you some nice stats about how many images you’ve helped classify, and that sort of thing, which could be used to create a leaderboard or achievements, but the messaging around all the projects is much more about how you are helping further science than about how you can score more points or get the next gold star.

Screen Shot 2013-11-04 at 11.57.37 PMWhich brings me to my next example of crowdsourced science, the far more gamefied “puzzle” game, Phylo. Phylo is played by moving squares around the gameboard, matching their colors vertically, and trying to optimize (or eliminate) empty space between them horizontally. The link between science and what you are doing in Phylo is a bit harder to grasp than in the Zooniverse projects, but as near as I can tell, the colored squares represent genetic sequences of DNA or RNA. From the project’s about page: “By taking data which has already been aligned by a heuristic algorithm, we allow the user to optimize where the algorithm may have failed.” The game is interesting at least, to the puzzle gamer in me, if not actually fun (it would probably be considered fun to some people, I can’t quite decide why I don’t think it’s fun, even though it’s got that “just one more game” draw for me), and they have packaged up the game with a leaderboard and “levels” (that all represent sequences that need matching). There is even an end-game condition, whereby you have to meet the “par” set by the computer algorithms before you can complete each game.

So back to my observation that scientists, or at least the computer programmers who help scientists are not superhuman, and my final link-observation that much of the Zooniverse code is up on github. This means that, if I had the time to spare and inclination (and an image cataloging project I wanted to crowd-source) I could probably get a pretty decent head start by checking out what they’ve already put together. That observation led to my thinking about whether the power of lots of humans playing could be harnessed to create the ultimate video game. A kind of crowd-sourced game design. I imagine a sort of branching-path puzzle game where at the root node, the game is in its simplest form, (and probably least creative). Then, you give the player a choice of whether they want x feature, or y feature. You measure how many people chose x vs y, and you make games x and y also, so you can measure how long players “stick with” both. (One assumption here is that a “sticky” game is good game design.) You could build this incrementally, so maybe in the beginning only a few branches are “built out”, just to have some content, and then you keep building branches, ideally in direct response to additional user feedback or surveying. Wouldn’t that be fun? The problem is that of course you need to generate the “branch ideas” from somewhere. Maybe you also let the players contribute ideas that also get voted on. (A sort of “other” survey answer.) Dunno, it was just a thought. Might be fun tho.

A 4X Dice Game

Posted on by

dice-pnpThis project came about while I was joking yesterday afternoon with my friend Patrick about how we needed to rush a space-themed dice game to Kickstarter before TMG publishes Eminent Domain Dice.

I’m still working on my deckbuilding 4X game, so 4X mechanics have been on my mind a lot lately, and the more I thought about it, the more I actually thought a 4X dice game could be pretty cool. Right away I had the idea that you would take your actions at the beginning of your turn, then roll the dice to plan out your next turn’s actions. From there, the game practically wrote itself.

I went to BGG to post my rough draft of the rules (without any graphics or pnp files), and before I got that far, I discovered that the theme for this month’s 24 hour game design contest is dice. Well, that seemed awfully convenient, but reading through the rules, I’d have to do everything myself, prototype art and all… so I did.

The other thing I did for this project that I’ve never done before, because I think it’s part of the “complete board game package”, is that I wrote some “flavor text”. I’m actually pretty happy with it too. Here’s probably my favorite bit: “What gravity at the edge of a black hole, this calculating weight of choice?”

So without further ado, here are the rules (and PNP pages, including custom dice in two sizes), for my new game, which I am tentatively calling 4X Dice.

Announcing Oppo-Citrus

Posted on by

You already saw the logo in my last post, but here it is again for posterity. Cool, huh?

I realized I was procrastinating this post, partly because I don’t know what to write here. I mean, this should be a teaser, so I don’t want to give away all the details, but I also want to be honest about giving an insight into the work I’m doing, both technically, and from a game design perspective.

There was another reason for not writing, a personal one that I normally wouldn’t go into here, but since I said I was going to have this post done a couple of days ago, I figure I should at least mention the real reason it’s later. The short of it is that I haven’t gotten anything done the last couple of days because my 2-year old daughter has been sick. The doctor thinks it might be whooping-cough, which despite having the silliest sounding name of any child’s illness, is actually fairly serious, and can lead to death in very small children. (Fortunately, she’s beyond that age, but it hasn’t been easy, and the most frustrating symptom is coughing until she vomits or gets very short of breath.) Anyway, it’s been a rough first week as an indie. I keep reminding myself that this is at least part of why I wanted to do this. I have the freedom to drop everything now and take care of her as needed. Yes, I might be delaying a product launch by a couple of days, and maybe I won’t make as much money in that time or whatever, but those are tradeoffs I get to make now.

Moving on… Lets start with the basic premise.

game_screenHere’s the current mockup of the game screen for Oppo-Citrus. The first idea I had for this is still intact: you drag a bar of colored squares into the column above, trying to position it such that you make a shape with four (or more) of the same color. You get points for every unique tetris shape. Right now, you get 1 point for the first one, 2 for the second, 3 for the third, etc. I thought about making additional shapes a multiplier, but since it’s fairly random right now, it seemed like that might be too rewarding. There is skill to it, don’t get me wrong, but a lot depends on getting the right combinations of colors.

The red shape and faded red squares around it are because this screenshot is mid-animation of removing the shapes made from placement of that top row from the gameboard.

As you can see, this first level is just two colors (lemons and limes), and as you might imagine, it’s actually fairly easy to make shapes. The real question is whether you can make enough shapes before filling up the board to progress onto the next level. That half-filled yellow bar below the row at the bottom is the level progress indicator. As you make shapes, it fills up, and eventually you get a screen that asks whether you would like to continue on to the next level or keep playing this one for points. I’ll leave what happens on subsequent levels up for a future post or posts, but in addition to the obvious (adding more colors), I have lots of ideas for powerups and additional game mechanics that actually change the game pretty radically while sticking with the original premise.