In a way it’s like a cooperative version of Blackjack, with much better art and a few special powers thrown in the mix. But that’s what it really boils down to in a sense: trying to hit a maximum total card value without going over.
Ridere, ludere, hoc est vivere.
Showing posts with label Reactor scram. Show all posts
Showing posts with label Reactor scram. Show all posts
Friday, June 5, 2015
Importance of theme in a cooperative game
Saturday, February 7, 2015
UnPub 5: Friday
Friday, October 3, 2014
Spring and summer photos
Thursday, June 26, 2014
UnPub Mini Chantilly Recap
Last Saturday, Keith Ferguson ran an UnPub Mini event at Game Parlor Chantilly. (I helped a little.) We had about twelve designers and about 20 gamers playtesting over the course of the 11 hours that the store was open that day. It was about as successful as we could have wanted. For my part, I got to playtest "East India Company" and "Reactor Scram" one time each, as well as to play about four other games, though there were many more I wish I could have played.
Sunday, June 15, 2014
More designers for 21 June UnPub Mini in Chantilly, Virginia
As I mentioned in a post on May 8, there will be an UnPub Mini event this Saturday 21 June at
Game ParlorWe now have a full slate of eleven designers lined up, so we have plenty of opportunities for gamers to come and try out new game design prototypes and provide feedback to the designers.
13936 Metrotech Drive
Chantilly, VA 20151
Thursday, May 8, 2014
UnPub Mini Chantilly on Sat 21 Jun
Designers and boardgamers in the northern Virginia area, mark your calendars: Saturday 21 June will be an UnPub Mini event at
Game Parlor
13936 Metrotech Drive
Chantilly, VA 20151
Friday, April 11, 2014
Reactor Scram: early playtesting
I have finally started working in earnest on a co-op idea I've had percolating in my mind for the last few weeks. The theme is that the players are workers in a nuclear reactor plant whose maintenance has been neglected, until finally the bad day comes when everything seems to break at once. The goal is to get the plant into a "safe condition" without melting down a core or irradiating any of the workers.
I ran a couple of solo playtests. I won one and lost one, which made me think that I've got the initial balance at least coarsely in the right neighborhood. What surprised me was how quickly each game completed - roughly ten or fifteen minutes per game. I usually have the opposite problem with the games I design - play times that run way too long. Right now I've got a game that takes more time to explain than it does to play. So I want to figure out some way of extending the gameplay as well as the "story arc" so that I'm not just "making it longer" for the sake of making it last.
First prototype of "Reactor Scram" |
Tuesday, November 1, 2011
Reactor Scram
My latest design inspiration is a co-op game idea I've had for a while. The setting is a nuclear reactor plant that has gone horribly wrong. Players try to operate various controls to keep the reactor (or perhaps multiple reactors in a single plant) from melting down. Problems can accelerate rapidly; players can quiesce one issue only to have another pop up elsewhere. Players win if they can stabilize the entire reactor plant; players lose if any core gets hot enough to start a meltdown.
Existing co-op games like Pandemic and Forbidden Island are obvious models. I have a couple of specific innovations to try to induce a strong sense of urgency (and perhaps panic) in the players. I've realized that in general, a co-op game (one that does not have traitors) is rather like team solitaire. That means that the game boils down to card luck and problem optimization. The tricky part about making a game like this fun is ensuring that players' decisions are not obvious but do affect the progress of the game. I want to make sure that mistakes cause setbacks but don't render the problem unsolvable. So there has to be a pretty broad decision space, with multiple variables in play and multiple "knobs" for the players to manipulate in an effort to control the game state and get to a solution.
I recognize that in any players-vs-game, luck has to be a factor. In fact, I think uncertainty and variability contribute to the fun and excitement of the game. But I'd hate for the game to devolve into a question of what order the cards came up or how the dice rolled.
I had some thoughts regarding card luck in general. In an upcoming post, I'll discuss a game design idea that came out of the question, "can I make a card game that minimizes card luck?"
Existing co-op games like Pandemic and Forbidden Island are obvious models. I have a couple of specific innovations to try to induce a strong sense of urgency (and perhaps panic) in the players. I've realized that in general, a co-op game (one that does not have traitors) is rather like team solitaire. That means that the game boils down to card luck and problem optimization. The tricky part about making a game like this fun is ensuring that players' decisions are not obvious but do affect the progress of the game. I want to make sure that mistakes cause setbacks but don't render the problem unsolvable. So there has to be a pretty broad decision space, with multiple variables in play and multiple "knobs" for the players to manipulate in an effort to control the game state and get to a solution.
I recognize that in any players-vs-game, luck has to be a factor. In fact, I think uncertainty and variability contribute to the fun and excitement of the game. But I'd hate for the game to devolve into a question of what order the cards came up or how the dice rolled.
I had some thoughts regarding card luck in general. In an upcoming post, I'll discuss a game design idea that came out of the question, "can I make a card game that minimizes card luck?"
Subscribe to:
Posts (Atom)