Designer Diary: Evacuation, Shipyard, and Aldebaran Duel

by Vladimir Suchy

Over the last two years, I have worked on only one game per year, and they were both co-designs. This year, however, I have been involved in several projects, and I have quite a lot to tell you about! Each of my new projects is special and has provided me with many new experiences, so this year’s designer diary is more of a summary of my work as a designer over the past year rather than a diary of one game…

Evacuation, or Leaving Co-Designers Behind…

After two co-designs (Messina 1347 and Woodcraft), both of which provided me with new experiences and the pleasure of collaborating with other designers, I decided to work on a new title of my own this year. It takes up a lot more time to design a game by yourself and is definitely more mentally demanding, but I wanted to remind myself how tough it is to realize a whole project by myself.

I started out by wanting to design a game that would differ from other economic games. Most economic games start from a position in which resources are rare, then over the course of the game you build up an engine that provides more and more resources for you to use to do more things.

Initially, I thought about flipping that premise on its head and providing players with all the resources at the beginning of the game and making the economy tighter and tighter as the game went on. However, that approach seemed a bit too negative for me as it would likely end up reducing the choices players had, potentially making the gameplay experience more frustrating the further the game progressed. Rather than having the game’s economy simply point downwards, I thought about turning the game’s economy into a U shape. Players would start with a lot of resources, then after one or two rounds resources would become scarcer, and after that as the economic engines build, resources would again be more abundant.

First sketch of the game’s planets and economic curves

Alongside this idea, I was developing a possible theme that would fit this idea, and it focused on two planets: one that players were leaving, while the other was where players were going to. This migration was being caused by an unexpected increase in solar activity near the old planet, meaning that all people (and their industries) needed to be moved to the new planet so they could survive.

The theme and main mechanisms were set early on. It was clear to me that Evacuation would be a thematically strong game with unusual resource management mechanisms. That provided me with an intriguing and new design space to work within — but it also didn’t leave me many examples of other games to be inspired by!

I had a few months of gathering thoughts and ideas for mechanisms for Evacuation before that design had to be put on ice due to the designing and testing of Woodcraft. Once that was done, I started to create the first prototype of my new game. I placed specific actions along a track between both planets that players could take as they moved towards the new planet.

Graphics of planets and orbits during development

My idea was that players could move faster on this track, but if they did, they would have fewer actions during the game as opposed to someone who went slower and would get more actions. Initial testing of this prototype showed potential, but it needed further developing. This track did, however, remain in the game until the final version.

Players gradually evacuated people and industrial infrastructure by spaceship from the old planet to the new one, which gradually becomes settled. This process creates a new economy on the new planet that is further boosted by infrastructure developments as the game progresses. These developments are asymmetric and are divided into four unique sets, one per player.

I then decided to create the mechanism for choosing actions. Actions could be taken either through text on cards or by choosing directly from the player board.

I added to this idea by giving the board and card actions different values. The sum of values taken could help the player gain an end of round bonus. This value was also connected to moving along the track between both planets, which represents an artificial intelligence track. As players move away from the old planet, the AI is less effective, but as the AI nears the new planet, its effectiveness increases, as do the players’ actions. This is the point where players face critical decisions: Do they play strong cards and have powerful actions but move slower along the track between planets, or do they play weaker cards for less powerful actions but move faster along the track and have the benefits of settling into the new planet?

The next dilemma I faced when designing Evacuation was dividing the process of resource management between the two planets. Resources gained at each planet generally have to be spent there. They can be moved to the second planet and used there, but this can be done only by a spaceship during the flight phase.

I was initially concerned that this resource management process might confuse players, but after playtesting I determined that players thankfully didn’t have any problems managing their resources in two distinct pools. After a basic version of the game was prototyped and playtested — and following necessary tweaks for balance — the later version was similar to what I started with.

There was one additional problem to overcome, and that was how the game should end. Initially I planned to design the game as a race game in which there would be no counting of victory points. Instead, the winner would be the player who managed to develop their resource income to a specific level. The player boards were variable, so I thought there would be enough challenge in that for players. However, during the testing of the game, more experienced gamers asked whether the game could be more complex and that meant more variability was needed. This caused me to move away from the race game idea and move towards the winner being the player with the most victory points.

I developed the game to be more variable, but the rule set increased in size and required players to make more decisions, thereby increasing the overall complexity of the game, restricting the pool of gamers to which this game might appeal. In this phase of development, the game included personal goal cards as well as action cards to play with, but this caused games to be long, with some games taking 2.5-3 hours to complete.

This increase in complexity and the consequent increase in game length made me think long and hard about whether it was a good idea to get rid of the original race game end condition.

I ended up solving this problem by incorporating different variants into the game. The basic variant introduces players to the game mechanisms and still includes a wide range of gameplay possibilities, but it is designed as a race mode. This variant was designed, following discussions with our testers, without using the action cards and uses only the actions on their player boards.

In other modes, players can include the action cards, which are drawn from a common deck of cards at the end of their turn. When playing with these cards, there is more randomness, but also more variability, tension, and excitement. There are also other ways to gain VPs through these cards, which add goal and common task cards, as well as modes adding more interaction while settling the new planet.

I was happy with this final decision to incorporate multiple modes into the game as it became the best of all worlds. The simplest variant offers a fully-fledged game with a reasonable length and difficulty, while the other modes allow the game to be tailored to each play group’s desired level of difficulty and duration.

One of the spaceships illustrated by Michal Peichl

At this point, the game needed to go through the final stages of balancing, which was particularly demanding in this case because of the four unique sets of technology tiles that comprise more than thirty technologies. This balancing process was very time consuming and required many group and solo playtests, and caused me to use a lot of perspiration as technologies were cut or moved from one set to another in order to achieve a level of balance with which I was content.

I am now happy with the balance of the whole game — of course, several hundred more playtests would always be nice, if not practicable! — and now that the wonderful illustrations by Michal Peichl have been added, we are looking forward to presenting the game to our customers at SPIEL ’23.

Shipyard, or Returning to Port

Working on the second edition of Shipyard, which was originally published in 2009, has also provided me with lots of new challenges in the last year. For a long time, the game hasn’t been available, and we were often asked by our fans if and when a reprint was coming. When the license with Czech Games Edition expired, we decided to re-release it with new graphics as it felt like, even though it is one of my older designs, it would fit in well alongside my more recent games and also within the Delicious Games catalogue.

That said, when we started thinking about re-releasing the game, we had to ask ourselves whether it should be re-designed, taking into account what I now know about game design, or whether we should leave it as it was and just graphically update it. To date, none of my games have been re-edited.

After reflecting on the original design process and checking out older and newer reviews of the game, I came to the decision that we would leave the game mostly as it was originally designed. I don’t often play my games after they have been published, but I found on returning to this game that I was still satisfied with the overall design and still much enjoyed playing it, so I thought it could be successful even fifteen years after its initial release.

Thus, the main changes we made were mostly graphical as we decided to change the look of the central mechanism by replacing it with a gear, even though it has the same function as in the original game. We also added a 3D crane box for storing particular tiles, which was suggested and realized by Petr Plasil (Youda) and his team of graphic designers and illustrators.

Stack for game components

I also decided to add a solo mode to this new edition of Shipyard that is in line with the solo modes of my more recent games in which I try to at least partially substitute a real opponent but with as little management overhead as possible. I am not a fan of solo modes that take a lot of effort to run as I feel it pulls you out of the game and distracts you from your own strategies, so I aimed to make it as realistic, yet as streamlined as possible.

The second question we had to deal with was with the balance of the game. The game received some criticism after its first release due to questions around balance of the government contracts. After reviewing this all again for this new edition, I came to the same conclusion as I did in 2009: The balance of the contracts was okay, none were broken, and they would allow players to end up with more or less similar amounts of victory points. I also looked at a survey that a fan made on BGG, and it confirmed my opinions.

While I was thinking about particular contracts, I discovered that the main problem for some of them is that they can more easily be achieved. This created the effect that they may give some players more VPs in the first games when all players don’t know the game as well. This issue is one I recognize and solve often these days. It can be resolved by finding a way of balancing some of the game elements which players realize are much stronger only after several games when they are more experienced with the overall gameplay.

We decided to solve this problem by creating suggested starting sets of government contracts. From this set, we removed the somewhat controversial (from our point of view, easier to play) contracts. At the same time, we also set the initial position of employees because we wanted all players to have the same starting conditions.

We think this was a good way to create the same starting conditions for all players, and after they gain more experiences with Shipyard’s strategic and tactical possibilities, players can play with all of the government contracts as in the first edition of the game.

These were my experiences of reimplementing this game, and we look forward to being able to get this game into the hands of a new generation of gamers.

Aldebaran Duel

As I’ve already said, I had a lot to do this year. Aside from a mini-expansion for Underwater Cities to coincide with the fifth anniversary of that game, the final project that I worked on was my first two-player only game: Aldebaran Duel.

I designed this game during the time of Covid. Generally people had to stay at home in smaller groups, and they weren’t allowed to visit board game clubs, so I thought often about simpler games for two players that could be played at home. Initially I thought I would release this design as a print-and-play game as a gift for those players who were stuck at home and couldn’t get out to their board game groups. I had a lot more time on my hands at that point, and consequently I managed to create the game in a relatively short timeframe of 4-5 weeks.

I was thinking about creating a card game with economic elements in it. The basic framework was built around a system of economic development, settlement, and colonization of planets with the help of a fleet of spaceships.

Cards can be used as something to build, but they can also be used as a currency to play other cards. A player has to decide whether they will gain victory points or pay to develop their system by going up tracks.

The next element I wanted to introduce had to do with player interaction. Not only do players fight for the better cards and victory points, but also for position on a map of space. On this map, both players control a single token, which by playing cards and moving along the various tracks they push across the space map. Depending on where the token ends up, the players will each potentially gain victory points.

I had created the framework for Aldebaran and still needed to work on the economic engine within the game. Gradually I added new ways to get VPs and also a new resource – science – which allowed players to gain important abilities and earn even higher VP incomes. I didn’t want the game to be solely about the economic engine, so I added other ways to get points so that players had different strategies to work with.

From the original idea of a simple game, the design had grown into a medium-weight game for two players. Even though the game worked and could be published as a PnP, it would need more thorough testing and better graphic design. I was working at this time on Messina 1347, so I put Aldebaran aside for now and left it as a game that might be published in the future.

Planet colonization

After a while, when Messina had been published, I pulled out some of the smaller games I had put aside in the past few years. I knew that the company that owns the printer in the Czech Republic where all of Delicious Games are printed also owns a big Czech publisher called Dino Toys. I offered some of my smaller games to them as I considered these smaller prototypes to be good games, and I felt it was a shame that they hadn’t seen the light of day. They didn’t fit with the Delicious Games catalogue as we publish heavy to medium-heavy strategy games for 1-4 players, and as such I thought Aldebaran Duel might never get published.

Dino Toys was indeed interested in Aldebaran, which they originally called “The Milky Way”. However, their decision to publish my game made me have to change my outlook on how game designs are developed and balanced. Since the founding of Delicious Games, I have been responsible for the full development process. When I worked with CGE, I was still closely involved in testing the prototypes and working on balance, and I discussed all my proposals for changes with the CGE team.

However, working with Dino Toys was quite different from any development process I had previously experienced. I had to let another person lead the testing, and they would consult with me on potential changes. This development process fell to a developer, Štěpán Peterka, from Dino. In the playtesting he organized, it became clear that even though I had been trying not to create a pure economic game, it was still very much that, and there was also the risk that the snowball effect kicked in.

The main economic mechanism of the game was based around playing cards, initially paid for by other resource cards, but as those cards were played, it became possible to play cards for free, and the player who was quickest to get their engine running became unstoppable, and the differences in VPs between players were huge.

When I was asked about this problem, I suggested that perhaps a player shouldn’t be allowed to get cards for free, but should always have to pay something. With this one simple rule addition, we were thankfully able to beat the snowball effect. The importance of building an economic engine was still there, but it was a touch less vital and it prevented the disparity in points between the two players. Once that was sorted, we moved on to other things such as balancing cards and especially the effects of the science resource. Štěpán consulted with me often on these adjustments.

Another question during the design process of Aldebaran was how to build the solo game. As I said before, I always focus on making a solo game with a simple ruleset and low player overhead. Initially I found that by trying to simulate an opponent’s turn, it turned into a more complicated solo mode and I wanted to make it as enjoyable as the two-player game. Eventually we came up with a solo mode based on drawing from a small card deck that offered a good challenge and was straightforward to manage.

After a lot of playtests and more balance tweaks, we were happy that the two-player and solo games were ready to be published.

We hope you like the sound of my designs for this year, and we look forward to you being able to play these games soon!

Vladimír Suchý

P.S. Thanks to Mike Poole for the language corrections.

Mini-expansion for Underwater Cities