Rabbits and Revolvers

Apr 282011

After a brief flurry of activity last month, it’s been hard to concentrate on all my little gamey side projects, since I’ve picked up a gig working on Flash games, but I’m still trucking along as the hours or fractions thereof present themselves.

I’ve recruited my friend and fellow improviser Halyn to work on the art for Fluffy Bunny Tea Party! We met today, and I’m totally amazed by the sketches that she put together. I’m really looking forward to working with her on all of the bunnies and desserts and associated artwork for the cards and rule booklet and boxes and whatnot. I’m sending her more technical graphic specs tonight, and we’ve got a production schedule down for a solid BGG.Con launch this year, and I’m totally confident that this is going to be a fantastic little game.

Speaking of cards, I just received a box of a hundred 4″x6″ Six Gun postcards from overnightprints.com, and they look amazing. I already liked the design, and seeing them all glossy and up close makes it all that much better. I’ll try to keep a few on hand as I toodle around – if anybody wants one, let me know, and I’ll make sure that you get it.

Work on Game Poems has been pretty slow lately. I’m just not feeling super inspired – I feel like I’ve explored the form a good bit, published a book of games (which still gets me a small check from distributors every few months, which is pretty nice), and although I’m certainly not out of ideas for them, I’m just not really moved to keep up with the weekly-or-so output these days. I’m writing a few special ones for a collection of vampire games that someone on Story Games is putting together, but beyond that, I’m not promising anything.

There are a couple of other projects still on the medium-back burners (Skin Men, and the Cochise RPG), but my energy is going towards getting Fluffy Bunnies out this year, so we’ll see how much writing and playtesting those get. Still keeping my hand in things, but taking it a bit easy right now, yeah?

Implosion

Apr 262011

I’ve been digging through some old archives, and came across an old, old design of mine for a game called Implosion. The general idea was that it handles up to twenty-four (!!!) players, and can be scaled down to work with factors of twenty-four; so, twelve, eight, six, four, three, or two. The board is twelve concentric rings populated by a series of connected nodes, with the players’ starting nodes on the outer ring, and a single scoring node in the center. Each node can contain a number of units belonging to a player, and the further out the node is, the more it can hold – twelve for the ones on the outside, and only a single unit in the middle. Moving and attacking is very simple, and there are “spawn” nodes in the rings about two thirds and one third the way in to generate new units.

The game was originally designed to be played asynchronously online, over a long period. Say, one turn per hour, one hundred sixty eight turns over the course of a week. As the game goes on, the rings start disappearing from the outside in. The board implodes, one might even say. When a ring vanishes, all the units on those rings vanish as well, until the entire board disappears on the last turn, and the game is over. (Actually, that part isn’t in the original version of the rules, which I’ll post below, but I know that was part of the design from the beginning. Weird.)

Anyway, you can see that this is a relatively primitive game, and it would be ridiculously unwieldy to play on a regular board, and probably still clunky and kind of a drag to test out in an online multi-player setting, as well. But it still feels like it has potential, and I think that with some futzing about and iterating over a few rounds of playtesting, something neat could come out of it. I don’t have anywhere near the bandwidth to do any of that right now, but it struck me well enough to give it a little think again, and maybe set it to simmering on the back burner of my brain…

Here are the rules from the original text file; I’d seriously revise these before attempting to play, but for the sake of posterity, enjoy:

Implosion

The game is played by 24 players, on a board made of interconnected nodes in twelve concentric circles. Each player begins with twelve units on their starting node on the rim of the Implosion board. Moves are submitted over the course of a turn (maybe an hour, when played online), and are executed in the order received. A move consists of a player transferring one or more units from an occupied node to a node that is connected to it. Nodes are connected to anywhere between three and six other nodes on the board, and units may only move along these connections. If the target node is empty, or contains units owned by the moving player, the units just move into the new node. If there are units belonging to another player in the target node, it is considered an attack – a battle occurs, and the winner’s remaining units are placed in the node. Units owned by more than one player may never occupy the same node without conflict. Units may only be moved once per turn.

When a node containing one player’s units is attacked by units owned by another player, the conflict is resolved by unit-to-unit battle, until only the units belonging to one player remain. The defending units attack first, then the invading units, and continue back and forth as long as both sides have at least one unit remaining. When an attack is made, there is a 50% chance that the attacked units will lose a unit, regardless of the size of the attacking or defending forces. For example, Player A uses three units to attack a node which contains two units belonging to Player B. Player B goes first, and succeeds, so Player A’s attack force is now two units. Player A also makes a successful attack, bringing it down to two units against one unit. Player B’s next attack fails, but Player A’s attack in return succeeds again, clearing out the node. Player A now moves their remaining two units into the node. If another player has submitted an order to move units into the same node after Player A’s move, battle occurs again, this time with Player A playing the defender, and attacking first. Moves are resolved in this manner until all conflicts are resolved, at which point the moves for the next turn may be submitted.

A node’s capacity is determined by its distance from the center of the board. The outermost ring of nodes, the twelfth one out, may contain a maximum of twelve units per node. The nodes in eleventh ring out (second ring in) have a maximum capacity of eleven units, and so on, until the center “ring” is reached, which consists of a single node that may only hold one unit. There are four different kinds of nodes on the Implosion board – normal nodes, starting nodes, spawn nodes, and the center node. Normal nodes have no special qualities, beyond their regular maximium capacity limit. Spawn nodes are distributed around the seventh and tenth rings – if a spawn node is occupied by a player at the beginning of a turn, they receive an additional unit in that node (up to the normal limit for that node’s ring), before movement occurs. Starting nodes are where each player begins the game, and are considered to be spawn nodes, with the additional advantage of creating one new unit per turn even if the node is not occupied by one of the player’s units, unless another player has occupied the node themselves. The center node is the method by which points are scored – if a player occupies the center node with a single unit at the beginning of a turn, they receive a point. Needless to say, this is a very precarious position to hold.

A standard game of Implosion is played for 168 turns, or one week if the turns occur once per hour. A game may end early if there is only one player with units remaining, in which case, they are declared the winner. Otherwise, the player with the largest number of center points wins. Ties are broken by the number of units left at the end of the game, number of spawn points occupied, and, in extreme cases where two or more players have equal numbers of all of those measures, number of inner nodes occupied.

Six Gun

Apr 082011

I just finished laying out the game postcards for Six Gun, a quick little clapping game where you play gunfighters trying to shoot each other quickly. I talked a bit about the design of the physical cards themselves a bit over on unDesign, but I’d like to note a couple of things about the game design here, as well.

As I mentioned over there, it’s based on a childrens’ game called High Noon. The play is really almost identical, except for one or two bits that I changed. First, I added a limit of six bullets to the game; in the original, you can just go on loading and shooting forever. This seems okay at first, but in practice, it leads to any number of degenerate strategies that will make the game just go on and on – the “always hide” thing, the following by one thing, and so on. Which is totally fine for a playground game! Fun!

But my inclinations being what they are, I need to impose some kind of closure on the play, so I added the “six shots to win” rule. That way, if someone is stalling, the other player can rattle off half a dozen bangs and blow the lollygagger away. (You can still sandbag your opponent a little, or both jump right on doing load-bangs, but the “if you both shoot your last bullet simultaneously, you both lose” rule is my band-aid for that.)

The other major change was the addition of a verbal component to the game. This, it turns out, makes it so much harder, for me, anyway. Maybe I’ve got some kind of mouth-brain-hand dumbness, but it really takes a lot of concentration for me to only count down the bullets when I’m loading the gun, instead of shooting it. It’s pretty fun to break down in the middle of a game like this, though – it kind of reminds me of the simple/impossible 1-2-3 clapping warmup from improv – but it’s a good way to build that mental dexterity, and it definitely adds pressure when the you hear the numbers going up like that. Of course, my screwing it up all the time makes it a little harder to playtest, but it’s all part of the fun, in my opinion.

Fortunately for me, playtesting a game that only requires two people and plays in about fifteen seconds is really easy. This is where my design process falls apart most of the time – I usually either can’t get the bodies together to give something a good go-around, or I personally can’t find a gap in my ridiculous schedule to get new designs to the table. So, this was a refreshing little break from the larger stuff, and I think it worked out really well. Grab a partner and give it a shot, and let me know how it goes!

Dribbble

Apr 072011

Recently, my buddy Troy Gilbert hooked me up with an invite to dribbble. Dribbble is basically kind of like a twitter for creatives, with a few extra rules; you get twenty-four “shots” every month, each of which is a small screenshot of something that you’re working on. The maximum image size that you can post is only four hundred by three hundred pixels, so everything there is mainly just some kind of glimpse or peek of the whole thing. This is nice for a couple of reasons – you don’t have to have a whole huge finished piece to post, and you can give a small tease of the greater work, which sometimes is more fun than seeing the entire deal all at once. It also lends itself to a nice kind of graphics simplicity on the site itself, and acts as a nice little creative constraint to work within when you’re creating a shot to post.

Anyway, I created my account on the last day of March, and the way it works, you get all twenty-four shots refreshed when the month rolls over, no matter how many you’ve posted. So, if you use all twenty-four, you get them all back; if you’ve only used one, you just get one more, bringing you back up to twenty-four. (“Drawing back up to your hand limit” is how I described it to someone else. So, since I had only a few hours to post everything that I could lay hands on, I got to work picking a few things that I had on various burners and cutting them to fit.

I wound up playing with some spray-paint graffiti techniques in Photoshop to create a “hello, world” post, and then moved on to the projects in front of me. I’d been drawing a hundred robots for a self-imposed challenge, so I found an interesting corner of my big art pad, and put up a shot of that. I’d also recently taken a couple of photos of some dungeon geomorph cards that I sketched up a while back (that were just sent to trade for a Machine of Death card), so those went up, too. I’m reworking Skin Men to fit in a much smaller format, and I posted a bit of the re-designed shrunk-up map from that, and finally, a piece of the Papair Hockey sheet that I was in the process of laying out.

Then midnight rolled around, and I took a little breather. I’m also getting back into exercising some of my illustration and design chops – which are more like … something clever that’s the opposite of a chop… – so I posted a bit of the Monkey Princess Palace that I’d been working up over at my unDesign blog, and that’s where we sit now. I have a bunch of older art that I could totally cut up and post, but it kind of feels like that’s going against the spirit of the thing. I could post old game boards and prototypes, or card designs or art from the cover of Twenty-Four Game Poems, but those are all done, and I’d like to keep generating new artwork and design bits for my dribbble stream, so maybe I will, and maybe I won’t. I have a bit of free time now to spend working on that kind of thing, so I should take advantage of it, right?

Is RocketYard colorblind-safe?

Apr 022011

There I was, innocently reading an entry about double-coding and color blindness over on Daniel Solis’s blog, when it struck me that my game RocketYard (self-published in 2009, very close to two years ago today) almost entirely relies upon the players distinguishing cards of different colors, which represent the different qualities of rocket parts that are used to build the ships in the game! This was my first real shot at doing my own graphic design for game cards, so I thought that I’d revisit it and see what’s what. To me, the styles of the rockets of each quality are distinct enough that, even without the coloring, it shouldn’t be hard for anyone to tell them apart (double coding!), but I was curious to see how they fared for actual color blind people.

So, I put out a call on Twitter and Facebook, asking if I knew anyone with color-blindness could take a look at the card images and let me know how they looked to them. I’m not planning on doing a redesign or another printing of the game any time soon, but I figured it’d be good to know for future reference. I do have another card game coming down the pipe directly, so the lessons from this will hopefully apply to the new art, as well.

After getting a good number of responses, I put together this color sheet of the cards, and sent them out to a few friends:

I got some great feedback, almost immediately, which tells me two very important things. First, it looks like I did the right thing, totally accidentally. I suppose that I stumbled upon the correct hues or values such that the weren’t really a problem for anyone, so, go me. Second, it’s also nice to know that I have a bunch of folks who are willing to step up and help out with a request out of nowhere like this, so, go them!

For the record, here are some of the responses, with the names removed for the sake of propriety:

JW: Looks great. Not even close at all.

BS: Well, I can clearly differentiate them, with my partial Color blindness. Don’t ask me what color the last one is though!

GW: They’re fine! Four different colours, to me.

DP: These look fine. The blue and yellow you’ll have very little problem with.  That type of color-blindness is less common.  The red and green are fine for me and I have a pretty significant red/green color-blindness.  The green is a light enough shade and the red is a dark enough shade that I think it’s fine as long as these are color correct for printing.
Also, I think the designs for each ship are different enough that even were a person completely unable to see the colors, they could easily distinguish one ship piece from the other.

So, that’s one design burden removed from my mind. One more thing to check off on the “don’t worry about this any more!” list…

Tension

May 132009

Last night Ian and I had a discussion about tension in games. We wanted to figure out how to add more tension to a game, but first we need to define what exactly tension was. We decided to break it down.

First, we picked out some games that we felt had tension. I brought up Ticket to Ride as a game with a lot of tension. As a player, you are always on egde wondering if you will get the right cards in time or if someone will steal your route. In my book, there is no greater tension than in a five player game of TtR. Another game that has tension is Carcassonne: You can feel it when tie up a lot of meeples in a city or farm all the while unsure of whether you can make it pay off.  Agricola also has tension in that you don’t know if you can feed your family or if someone will take the resources you desperately need.

Second, we tried to find the common factor in all of these games. The first thing we noticed was that the player took a risk. The bigger the risk, the more tension felt. The second thing we noticed is that the longer the risk takes to resolve, the higher the tension. In Ticket to Ride, you make have an LA to New York ticket from the start of the game. You may not complete it until the very last second. In Agricola, your entire plan revolves around getting the grain action, but you have to sit there patiently waiting for the other players to place their farmers.

In summary:

Tension = Risk  x  Time

This seems obvious laid it out like that. Now that we have the formula, we can think about it in terms of our own games. What can we do to ensure that our games have the right amount of tension?

Underworld Updates

Sep 032008

I was feeling a little concerned about my game prototype Stellar Underworld. This feeling came from some of the feedback from the guys from Oklahoma, and from a botched playtest with some “improved” rules based on that feedback. All of that, and I feel pressure to get this game ready for the Protocon design contest.Well, last night I decided to try out some simple changes and see how that fared. We played and I am happy to report that it played really nicely!

Here are some of the things I addressed:

Your ship is your ship – In the previous versions, your ship could be stolen if a player sent enough henchmen to do it, though you could also defend it if you wanted to. The system worked out ok, but the feedback I was getting was that it didn’t feel like you owned your ship. The “comandeering” rules for stealing are no longer in effect. You can only use your ship and the two neutral ships. Suprisingly, this worked out pretty nicely. And it was one less thing that players had to worry about (keeping enough henchmen around to defend a ship).

A nice side effect of this is that when you used your ship, you could leave cargo aboard without fear of thievery. No need for the warehouse. However, when you use the neutral ships, you almost always have to use the warehouse. The usage of the neutral ships are amplified now that other players ships are off limits to commandeering.

This is a perfect case of the development philosophy “How much can I remove from the game, and have it still be the same game?”

Henchmen are worth less – In the previous version, a recruiting strategy seemed to be a main path to victory. Henchmen were worth the same as completed contracts, and they provided many other benefits. Now, they are worth half as much as contracts. Players still benefit from having a lot of them, but now they aren’t “double dipping”.

There were other feedback points that I may or may not address, but for now I think the game has improved. I just to make a new bigger board, and a few other cosmetic changes, and I think I’m ready to go!

Highs and Lows of Game Development

Jul 302008

There are two main states of game development:

Exhilaration – You have a list of some issues in your game that need to be addressed. You’ve come up with a solution to one of the problems on paper. You think it is so elegant and will solve all of your problems. You, sir, are a genius! You live in the land of happiness and can’t wait to try out your idea.

Despair – Your elegant solution failed completely. It made the game unbalanced. It made the game broken. It made babies cry. Now you must head back to the drawing board to face that annoying issue you were trying to resolve in the first place.

So, this process continues over and over. New issues replace old issues. New fixes break old fixes. You become an expert on your game, and you have tinkered with every aspect of the design. One day everything everything falls into place and you have a game. Sometimes this takes you by surprise. In the end, all the highs and lows were worth it.

Stellar Underworld Feedback

Jul 142008

Today I received some feedback from Mike and the guys at the Royal Steamwork Society about Stellar Underworld. Here are some of the main points I pulled from it:

Rules Clarifications

Can contraband assets be delivered in multiples?

Yes. This will have to be explicitly stated in the rulebook. Contraband assets are different from other assets in that they don’t require any contracts to score them (because contraband is always in demand). This leads to some extra rules in dealing with them, and I guess this area had some confusion.

When can a sector ability be used and how often?

For the most part they are used during the docking bay ability phase. I will need to clarify this a bit more. I also plan on adding a glossary for each sector to answer any specific questions.

Strategy

Is acquiring henchmen too powerful of a strategy?

There are two methods of scoring points in the game: recruiting henchmen and completing contracts. It has been suggested that taking a strategy of heavy recruitment is the best way to go. I know that henchmen are important because they not only score points, but also provide the manpower to activate abilities. I don’t believe you can win by ignoring them, or by solely focusing on them, but I need to test this out.

Test: Play a test game where one person only scores via henchmen.
Test: Play a test game where one person does not recruit any more henchmen.

Are warehouses necessary?

An interesting occurrence happened during the blind playtest: In their second game, the players completely ignored one feature of the game because they deemed it too weak for its cost. The feature is the warehouse. The warehouse allows you to move assets around more effectively, keep them safe from commandeering, and set up more efficient scoring. The cost for loading an asset into the warehouse is one henchmen. You also have to pay the cost for unloading too. In all of the other playtests, everybody used their warehouses. I am always on the lookout for dominant strategies, but I failed to look for utterly weak ones. Maybe the warehouse is too weak. I haven’t really thought about it, but I will need to investigate more.

Test: Play a test game with one player does not use his warehouse.

Theme

Players don’t feel like they own their ship

In the game, each player has one ship and there are two neutral ships. Owning a ship means that if someone tries to commandeer (steal) it, you can defend it and try to stop them. Other than that, owning your ship means nothing. In real life, owning an object really means nothing either except that you feel like you would need to defend it (by force, lawsuit, etc.) if someone tried to steal it. That was my reasoning, but it doesn’t seem to come across to well in the setting of a game. Especially in a game setting where stealing is an everyday occurrence.

Possible Solution: I think that stripping out the idea of owning a ship is the way to go. I have an idea on how this would work, but would like to experiment with it first.

Components

The board is too small for some components

The board is a map of a space station with a space in the center for the “bank” of henchmen and contracts. I underestimated how many of these things there would be and it does look cluttered.

Solution: This one’s easy! I think I can just reduce the number of pieces or make the board bigger where it needs to be.

Frustration Points

Replenishing no assets or no Contracts at a sector

Frustration: The production system in this game uses a random method that could result in the sector gaining no contracts or no assets. Having no contracts at a sector means that you can’t score points there, and having no assets at a sector means that when you arrive there you’ll have nothing to ship back on the return trip. Statistically, it shouldn’t happen that often, but when it does, it is really frustrating. I have yet to determine if this actually hinders the player or if it is a psychological issue.

Possible Solution: I need to add more flexibility to this system, but I’m not sure how to do this just yet.

Having limited end game options

Frustration: The game uses a system where each player has an identical set of cards. Each turn you play one card a turn until no players have cards. This system inherently causes the end game to have limited options.

Possible Solution: Make the end game occur before the players reach their last card, possibly third to last. This will still give players choice on the last turn. Of course, this solution will cause a new frustration: player wanting to play the rest of their hand!

Not being able to ship directly from sector to sector

Frustration: The core idea of the game is that you always have to stop at the space port when traveling from sector to sector. There is no direct route. If there was a direct route, there would be little reason to use the space port (the whole point of the game).

Possible Solution: Give each player one or two Direct Route Cards to allow this to happen. It should appease player frustration enough, and answer that question “Why can’t I just go from here to there?” The best “abilities” in games come from easing player frustration.

A Good Night of Testing

Jul 092008

Ian’s Unnamed Space Game Playtest

Ian, Jon, and I played a newer version of Ian’s unnamed space game. This game is your basic 4X game: explore, expand, exploit, and exterminate. Actually, the “explore” aspect isn’t really there because the board is pretty much open information from the beginning. So, I guess it’s a 3X game. Anyways, the real ingenuity of the game comes in the form of flicking, as in Crokinole or Ian’s other game Taktika. Instead of dice or card draws, the random element of the game comes in the form of flicking. About 80% of the time, the flicks are successful, but that remaining 20% keeps players in a haze about their future. You see, the rest of the game is perfect information, and the only uncertainty comes from your opponents and the flicking. All in all, this game is coming along nicely. It will take a lot of play-testing because there are so many build paths and strategies.

Venture Forth Playtest

Ian, Jon, and I played my latest incarnation of Venture Forth. This game started as an ambitious project two years ago to make a Euro-style Talisman. It has gone through many many incarnations between periods of being shoved in the back of my closet out of frustration. The core of the game has remained throughout: character ambitions. My big beef with fantasy games is that it is assumed that all characters have a bloodlust to kill monsters and an unending desire to acquire treasure. My game would allow the character to be who they are and be rewarded for it. For example, in the current version, you can have just a lone Faerie in your party and score points by just ‘making friends’. There is still treasure and there is still killing, but only certain characters desire those things.

Last night, I got to test it with more than two players and it worked great! My new bonus point system worked as well as my new cube ‘currency’ system. Everything fell into place, and I couldn’t be happier.

Older Entries