:strip_icc()/pic6669791.png)
/pic6669791.png)
This gaming group met regularly at the home of David Ivan Salcedo Casareto, one of the most fun and generous people I've had the pleasure to meet. David and several other people joined me in the first-ever game of "Space Stations", and...it was a mess, both physically and in more than a few key mechanical ways. Still, the core game ideas worked, and I got lots of great feedback in both Spanish and English that helped launch the journey this game has taken over the last eight-and-a-half years.
:strip_icc()/pic6842712.jpg)
David and others at Club Rath's Edge, playtesting another homemade game in 2013
Below, I'll try to give a bit of insight into the story of how Space Station Phoenix went from concept to publication.
Note: I'll use the name Space Station Phoenix (or SSP) throughout, despite calling it "Space Stations" or "The Space Station Game" for several years and "Orbital Architects" for a few more. Thanks to William Giammona for finally coming up with a name everyone could agree on! For a list of all the names that were suggested to me, click here.
Origins
I need to go back before that first playtest in Lima to start us off. Two big ideas combined to lead me to create Space Station Phoenix.
:strip_icc()/pic3720648.png)
The second seed came from this blog post on the Board Game Design Forum. It outlined the idea of a game based on surviving a famine. Instead of a game in which you are building an empire, you would simply try to be the best at helping your empire last through its collapse. While I came up with a number of other game ideas that more directly built on that theme, I took just one element as an inspiration for SSP: the idea of having fewer choices as the game went along. So, as opposed to many games (think worker placement games like Agricola or Troyes) in which more and more action spaces become available throughout the game, in SSP players would have fewer and fewer options as the game moves forward. In fact, they would be intentionally forced to eliminate options to make progress.
As I delved into the idea behind the game more, I realized these two ideas meshed quite nicely. An isolated fleet floating in space would lack a ready supply of resources to develop their stations. Therefore, they'd need to start cannibalizing their ships to get enough metal to build.
From the beginning, this took the form of one of the core mechanisms of the game. In SSP, players begin with a limited number of ships that serve as "action spaces" that they pay to use, but the main way players get metal to build their stations is to destroy those ships, causing them (and also other players) to have fewer options as the game goes along. At the beginning of the game, tons of ships are available, but players have very limited resources, so there is rarely a type of action a player desperately needs that is unavailable. By the end, however, there may be few ships on the board that allow players to, say, build their station or transport new residents to live there, and a competition to use those remaining ships can arise. This thematic nugget of dwindling resources fit quite naturally with the cold depths of space.
:strip_icc()/pic6842714.png)
Example from the rules: using a Dismantling Ship
Design Goals
As I started to conceptualize the story behind Space Station Phoenix, I also took time to give myself a few design parameters. First, one of my least favorite elements of Exodus Fleet was the round structure: Everyone gets a turn as "Admiral", then we move to the next round. It has no effect on gameplay except as a timer. This approach served a purpose — putting pressure on players to accomplish something by the mid-game scoring round and setting a time limit for the game overall — but it felt artificial and it was sometimes hard to remember to track when players moved from one round to another, so for Space Station Phoenix, I wanted a more fluid structure in which once the game started, players were off to the races, with short, punchy turns that would continue one after another until the final moments of the game, the timing of which is dictated by player choices.
Second, I wanted to make sure there was significant player interaction. To be clear, I love many games that get accused of being "multi-player solitaire". However, even in most of those, I find it interesting to look for the places where one player's actions impact the choices of others. That said, I aimed to exceed that minimum, and while players can play SSP focusing only on themselves, there are many crucial ways that one player's actions in the game impact others. A few examples:
• As mentioned above, the number of ship/action spaces is limited and shrinks during the game, so there is the typical sense of "blocking" that comes in similar worker-placement games, yet in SSP, there is also the converse: When a player takes the income action, all of their previously used ships become available again, so other players with the means to do so can jump on these newly free action spaces. Of course, that's another source of interaction: When you use another player's ships, you have to pay them an extra fee.
• The station parts that are required to build are limited, as is the number of residents who players can bring to inhabit their station. Points are awarded for pluralities for each different type of resident, and station parts often have unique and powerful abilities, so overall there's an element of racing or outfoxing other players to get those bonus points or grab a desirable station part.
• The cherry on top is the diplomacy board. By moving up the diplomacy tracks, players can gain resources and points when any player takes a particular type of action. Therefore, players can get direct benefits during other players' turns. I particularly like elements like this, where not only do I care what another player does because it may limit or perhaps force my own choices, but I care what they do because it can directly benefit me.
:strip_icc()/pic6842715.jpg)
An early version of the diplomacy board
Overall, the level of player interaction in SSP hits a sweet spot for me: Players are mostly focused on their own little world — building their station and filling it with residents — but paying attention to other players is crucial to success.
Replayability is the other key issue for me. I have limited space for games at home, so while I love learning new ones, the ones I own tend to get played to death, especially ones I can play two-player with my wife. If I wanted to playtest this game several hundred times, it had to have variation from game to game. Of course the player interaction as described above helps, but beyond that, I developed SSP to feature a huge number of station parts, of which only a small portion are available in any given game. The game also has thirteen different types of higher-level ships, of which each player gets only four, making set-up different from game to game.
Things Lost Along the Way
All that said, the game is not what it once was. It went through dozens of changes, some huge and others tiny, so let's just be honest and say it took a long time to get from concept to final product. I'm a full-time teacher, so I usually have time to work on only one game at a time, and even my top-priority games can take months from one version to the next. After the initial design was done, it spent most of the next three years sitting on a shelf before I dusted it off.
Most of the biggest changes happened over a series of playtests in early 2016 before I showed the game to any publishers. After that, it was a serious process of "trimming the fat" and clarifying where the game's main action was happening. Here are a few of the "greatest hits" of ideas that came and went:
• In the initial version, resource gathering happened on a separate exploration board. Depending on the "level" of exploration ship a player used, they would choose a random token from somewhere on the board and get what was shown there. This turned out to be slow, tedious, and frustrating — clearly not the mix of adjectives I was looking for — so this was replaced, through several iterations, with a dice-rolling mechanism. There's still randomness and variation, but within a more bounded and more generous range.
• The design of the space stations in the game also changed massively over time. In the initial versions, station parts were square chunks that had "in" and "out" tunnels in various colors. Only an "in" of the same color as an "out" could be connected. Later, the ins and outs got chucked in the trash, but the color connections stayed, meaning it was still a massively time-consuming puzzle for players. It was fun but unnecessary. Also, having only the top tile of each pile of station parts available was fine, but it didn't allow for strategic planning. Instead, I replaced this with a set-up of exactly enough parts for all the players to build. These parts are displayed at the beginning of the game, allowing players to make strategic decisions about how to build their station from the beginning.
:strip_icc()/pic6842716.png)
A rough idea of the progression of the design of the station sectors from 2013 to 2022
• Once I realized that I wouldn't be working again with Tasty Minstrel Games (R.I.P.), the theme took a big turn. Instead of humans building space stations in alien territory, I decided it would be fun if the stations were built by aliens who wanted to observe Earthlings. This thematic change also helped clarify why different groups of residents inhabit different station parts: They breathe different atmospheres. But this change has left one lingering question: When a player adds a human to their station, have they just recruited a friendly one to come live amongst the aliens, or has the poor person been abducted in an X-Files kind of scenario? I'll let you decide.
:strip_icc()/pic6842717.jpg)
• Of course, I wanted players to build circular stations like you see spinning in space in the movies, but since I'm a Luddite and I make all my game pieces in Excel (see the images?), that meant I needed to have players build their station out in four directions to make a circle. This turned out to make the game way too long, and it was also a pain to try to see what was happening on the station parts players played upside down from their positions. Fortunately, fellow designer Aaron Vanderbeek asked, "Why don't you just have players build in three directions?" Brilliant! That shortened the game right up and made it easier for players to visualize their situation. The art team of Claus Stephan, Martin Hoffmann, and Mirko Akira Suzuki did a great job making it look sleek, too.
/pic6842718.png)
Alien ally cards that
players could purchase
Balance in All Things
Even once a lot of the excess weight was shed, the game still needed work. This is where Ken Hill, developer for Rio Grande Games, became a major sounding board for new ideas. After pitching the game to Rio in 2016, Ken and I traded a lot of emails, had a ton of phone and video calls, and generally were in touch constantly over the next couple of years. Of course, we both had full-time day jobs throughout this whole time, so it wasn't exactly the only thing on our plates. (Seriously, I get jealous when I read the designer diaries of people who do this full time and can just put all their time into gaming, not just evenings when I should be planning lessons or grading papers.) But progress, however slow, was made.
One thing we eventually agreed on was that actions should simply be a touch more powerful. In particular, the resource-gathering actions of expeditions and dismantling needed to be slightly less painfully slow, so we simply threw more resources at the players. Boom! Game time dropped, and player engagement increased. At the same time, we realized that not all ship actions were perceived as equally valuable, so we started to play with the relationship between the GEM cost to use ships and the value they produced. This took some tinkering and guesswork, but in the end, I think we came out with a set of ships that push players to think creatively about how to achieve their goals in any given game.
:strip_icc()/pic6842719.png)
Here are minor tweaks in cost to use (orange), metal generated when dismantled (4 to 6), and resource generation (on the explore/expedition ships) — all of which produced a more dynamic game
Once all of those issues (and more) were worked out, it came down to several hundred repeated playtests to balance out all the various ship and station part abilities. I had a massive Excel spreadsheet in which each station power was described, ranked, and rated, all to plug into a formula that would generate a number showing how much metal that station part should cost. The problem was that sometimes that number was wrong. Over time, I adjusted and revamped the formula. Still, there were times when I had to give in and note that I had been wrong about how valuable one ability or another was — or how valuable players perceived them to be.
Somewhere along the way, as we closed in on a playable final product, I realized something was missing. It was good, but I needed more. After spending so much time shedding excess weight from the game, I was worried about adding new ideas. Not only would I be creating a whole new mess of things to balance, but maybe it wouldn't work at all, and I'd be wasting my time.
Nevertheless, it turns out my instincts were right. When I reached into my conceptual bag of stuff I had wanted to add to the game (but was afraid to try), I realized that players should start with asymmetric station hubs. These give players a starting bump in their abilities and perhaps a little nudge in a strategic direction. I designed a few, then designed more, and eventually ended up with 24 of them. These make the game. Now each time I play the game, my favorite challenge is to compare my various hub options to the available array of station parts and figure out, "How can I win this game?"
:strip_icc()/pic6842720.jpg)
Set-up for my first game with finalized components; my wife and I each have two very different hubs from which to choose
The most fun part of this phase were the nights I spent trying to balance the powers on the station hubs. I had a regular group of playtesters over at my house, and we would play SSP at a ludicrous speed three or four times in a row, often with the same arrangement other than trading those starting hubs with one another. We knew they were probably balanced as long as Kenny Tracy won by the same amount regardless of which hub he had. (He's just that much better than me at all of my games. I should also add that Kenny provided invaluable feedback on balancing the various hubs before, after, and during playtests. He's the best.)
Rio Grande Games
/pic1463107.jpg)
In 2011, I went to Gen Con for the first time, hoping to pitch the design that later became Exodus Fleet to publishers. The first publisher I met was Jay Tummelson of Rio Grande Games. He generously gave me, a novice designer with no insider connections, nearly an hour of his time. While he didn't sign the game that day, he expressed serious interest and gave me a lot to think about. Without that encouragement, I might have given up on game design. Instead, I returned with a better product at Gen Con 2012, and while the game didn't get published by Rio Grande, it did get published, which kept me going. So when I returned with my next batch of games in 2016, Jay was the first publisher I contacted, and...here we are.
I'd be remiss if I didn't reemphasize the great work that Ken Hill has done, helping push me to refine the game in various ways, some of which are described above. He's a great, clear communicator and collaborator and kept me in the loop on every detail of the graphic design and production process. Scott Tepper, Robin Hill, and many others also contributed useful ideas along the way. Finally, the art and graphic design team (Stephan/Hoffmann/Suzuki) have turned it into a fantastic final product. After so many years of tinkering with it, I can't wait for this game to get out in the world.
So...here’s my game. I hope you like it.
Gabriel J. Cohn
:strip_icc()/pic6429261.jpg)
:strip_icc()/pic6868943.jpg)
:strip_icc()/pic6871774.jpg)
/pic6596237.png)
:strip_icc()/pic6268503.jpg)
