Archive for Designer Diaries
1 , 2 , 3 , 4 , 5 Next » 
Hi there! We are Jordan and Mandy Goddard. Yep, you guessed it — we are married, and we design games together. We love getting the chance to work on projects together in our free time, and what better hobby than one in which we get to play games all the time! Here is the story on how our latest game, Lotus, came about and how it evolved over the course of two years…
Lotus is a game that was developed mechanisms-first, then grew into its beautiful theme along the way. The process started during the summer of 2014. Our early objective was to create a board game-like experience using cards and no board. We started playing around with how cards are held in your hand and how that same fanned-out shape could be placed down on the table to create a full circle of cards. This led to the development of the game's core mechanism of set completion with five different sets, ranging from three cards to seven cards. Using a little geometry to identify the exact angle of overlap for each set, we were able to guide placement of each card for a clean shape every time.
It didn't take long before the card-laying mechanism naturally led us to a theme of building flowers. That theme, in addition to our desire for a board game experience, led to the addition of butterfly meeples to be used for area control of the flowers in the garden. We gave the design the name "Bloom" and got to work on a ruleset and petal card illustrations.
It doesn't always make sense to invest in full art so early in the game design process, but in this case, the petal cards actually help enable the mechanism by providing guides for placing the next card in the set. The art also provides a visual indicator of progress toward the completion of each flower, which is helpful during gameplay. We had a full art prototype made to confirm whether our vision was going to work as we expected. It was time to move on to playtesting!
Thanks to the great community at Unpub and the Blue Noodle, we were able to show our design to a large number of wonderful people and receive incredibly valuable feedback. Their countless hours of playtesting various iterations and providing detailed suggestions helped us polish the details. We also leaned on the Reddit community, specifically the TabletopGameDesign subreddit, for some early feedback on artwork and general concepts of the game. You could even say this process led to some budding friendships.
Daryl Andrews, Gil Hova, Jordan Goddard, Ian Zang, Tony Miller, Mandy Goddard, Isaac Shalev (back row)
Tiffany Caires, Daniel Newman (front row)
About a year into our project, in the summer of 2015, we partnered with Renegade Game Studios. It was a wonderful experience working with the Renegade team and collaborating with their extended network of game designers and artists. While the core mechanisms of the game remained unchanged, there were a few significant improvements made as a result of working with the new team.
Theme and Visual Aesthetics
We learned that the name "Bloom" was already taken by a European game, so we started brainstorming alternatives. (Two examples were "Blossom" and "Garden in Bloom".) The final decision for "Lotus" didn't come about until after we landed on the idea for the box art. Kane Klenko (designer of Covert, FUSE, and Dead Men Tell No Tales) led the art direction for Lotus and we owe him a HUGE thank you for how beautifully everything came together. Illustrations were provided by Chris Ostrowski and graphic design by Anita Osburn — what an amazing team!
The box cover took on a clean, inviting, mysterious feeling through the use of negative white space to draw attention to the gorgeous Asian-inspired artwork. The petal cards bring the game to life with their bright, bold colors and natural imperfections that allow for no two completed flowers to look exactly the same.
The final theme was a result of the art direction — or at least of a feeling the art evoked. Players are invited into a mysterious lotus garden where they compete for flowers in order to harness the wisdom that the mystical blossoms provide. Each player also commands a set of insect guardians that helps them gain control of flowers and aids them in gaining special abilities to make their quest more successful.
Mechanism and Components
For what may seem like a fairly simple set of rules, the game did pose a number of challenges for us during playtesting. It's interesting to look back now to remember how much it really changed over the course of two years in development.
Below are a few examples of ideas we tested that didn't make it into the final version of the game. We also show the issues that kept these ideas from working and the solution that was implemented in the final version of Lotus.
A few more tweaks here and terminology updates there, and we finally had the Lotus rules. Final components were also taking shape, including a change from using just butterfly meeples to including three other critters — ladybugs, dragonflies, and caterpillars — to round out the mix of insect guardians.
The most fulfilling part of the entire process was supporting the launch of Lotus at Renegade's booth at Gen Con 2016. The reception of the game was so positive, and we are just so excited to see other people enjoying playing with their families and friends. If you have a chance to play, we would love to hear your feedback on Twitter @JordanandMandy.
Thank you so much to everyone who helped us along the way!
Jordan and Mandy Goddard
Ancon — a charming city with a lake surrounded by verdant hills, a pleasant marina, a beautiful opera house…
In winter when tourism is dormant, its streets are empty and fog rises from the water, Ancon's beauty takes a rather eerie and melancholic turn, verging on the sinister: something like Death in Venice (without the sun) meets The Shining (without Jack Nicholson running after you with an axe).
Needless to say, I was there one winter.
I had just flown in to replace a deficient colleague in a production of Mozart's The Magic Flute. I didn't know anybody on the production (the fate of latecomers) and had packed only one book: Jared Diamond's Collapse (which describes how brilliant past civilizations have collapsed almost overnight for badly managing their natural resources –something that, according to Diamond, will happen to us soon, if we do not change our ways).
Was it the uplifting read, the loneliness, the fog? Sitting in my hotel room, thinking about what the next game in the Oniverse series could be, I decided: "I'm going to take the WORST game mechanism ever and use it to make a fun solo/coop game" — and the worst game mechanism I could think of was "roll and move".
Ah, roll and move! The mechanism that most of us "serious gamers" love to hate! How could I possibly turn this into something that I would consider a satisfying and fun solo game experience?
My first impulse was to think: "Onirim: The Dice Game". You are in a labyrinth and have to get out. To do so, you must outrace a bad guy running towards you (it was obvious to me that he'd be running towards you as thematically absurd as it was at that time; my intuition would be proven right a couple of weeks later) and get to the exit (the bad guy's starting point) before he reached the center of the labyrinth (your starting point).
To make things interesting, you wouldn't only need to go as fast as you could, hoping for high rolls (where's the fun in that?); along the way, you would have to gather pieces of a key-like artifact. Only with the complete artifact would you be able to open the exit door. And the path would actually be made of the pieces, so no need for a board or track. For this reason, you would sometimes need to go slower in order to pick the right piece (obviously, there are several copies — four actually — of each piece, allowing you to jump over some of them).
Already in my first draft, the bad guy was not alone: an arch-villain would hover over the race, sabotaging your progress.
So the primal situation with its game-nurturing contradictions was the following:
• You want to go fast BUT must sometimes slow down to get missing pieces.
• You want the bad guy to go slowly BUT you must be careful that he doesn't land too often on the pieces you will need. After all, he steals each piece he lands on, so you sometimes need him to jump over a larger part of the track.
• You need to prevent the arch-villain from too often sabotaging your race as he makes you discard pieces you already have if he gets high results on the dice.
Three actors (player, bad guy, arch-villain), three dice.
And instead of each actor having their own dice, you would roll all three dice each turn, then assign them.
This was the first playable version. It had enough hard and fun decisions in a short amount of time for my taste, so I didn't throw the prototype out the window.
Still there were some flaws: I had no expansions at all and a lot of elements didn't make sense thematically: Why would you race towards the bad guy? Why is he ignoring you when you cross paths in the narrow alleys? Why do you lose as soon as he gets to the center of the labyrinth?
The solution actually came from a tiny, but annoying thematic/component-related problem: How could I represent the player?
In Onirim, the player has no physical presence in the game components: the cards represent the visited locations and the encountered dreams — but the player somehow stays "themself", which I find coherent with the story that the game is telling. And the same goes actually for Sylvion, Urbion, and Castellion.
Would I change this here? And how? A humanoid figure running? An abstract pawn?
Then the answer dawned on me: The player should either be wearing a suit or be in a vehicle! A diving suit? A car? A boat? A submarine!
And suddenly everything made sense!
You weren't escaping anything; you were diving into the depths, towards the lair of the arch-villain, who was no longer hovering over you, but firmly waiting at the bottom of the ocean, prepared to conquer the whole aquatic world of the Oniverse.
The bad guy would be the arch-villain's henchman, a ghost ship — or rather a phantom submarine! — on its way to the surface to bring desolation to your homeland, the Happy Isles.
That's why you have to get to the bad guy's starting point before he gets to yours: By destroying his boss, he will become powerless! And in order to defeat this arch-villain — a sinister Darkhouse that emits darkness instead of light — you would need help from various inhabitants of the depths, no longer inanimate pieces of a key.
This thematic change not only made everything more coherent, but it somehow opened up the game to various expansions, as if the thematic inadequacy of the first draft had me stuck into a mechanical dead end.
First, you could have various submarine designs. With of a simple "air conduct rule" (you can take a new member in your ship only if their cabin is adjacent to the cabin of another member), some submarines would be much easier to man than others. I came up with six different shapes, ranging from quite comfortable (lots of adjacent cabins) to very tricky (with cabins connected only to one other cabin).
Niobe racing the Hammer to Zion through a mechanical line, Lando and Nien Nunb maneuvering the Falcon through the Death Star pipes, Max and Furiosa bogged down under enemy fire — what would a good race between vehicles be without obstacles? In the "Reefs" expansion, some of the crew-members gain special abilities to outmaneuver various sub-aquatic traps that would otherwise bring your ship to a grinding halt, making you lose a whole turn, while the Phantom Submarine, impervious to anything in its way, would continue on its path up relentlessly!
If some crew members were pilots, other could become…fighters! The "Mercenaries" expansion develops on this and adds a new climax to the mid-game. (In a movie — or an opera — you would call it the first act's finale.) Now when you cross paths with the Phantom Submarine, you have to fight him! Not only does it start with better equipment, but it can also enslave fighters it meets on the way, further increasing its strength.
Fighters, pilots…how about some mechanics? Those would have the ability to re-roll some dice, but only if helped by a new sort of crew member: the Undersea Mages! This expansion actually brings a new type of dilemma; the fighters and the pilots help you as part of the crew on the submarine, but in order to get a mechanic's help, you have to pair it with a Mage in a separate section of the ship. Re-rolling dice is cool during the game, but is not part of the winning condition…
And what about the Darkhouse, lurking in the depths? I decided it would be fun to make him a cheater: the fourth expansion (named after him) brings rule-changing cards into the mix. Each turn, a new rule comes into effect, slightly modifying how the dice are rolled or assigned, how the figures move, how the tiles are distributed, and so on. Some of those cards make the game trickier, some make it easier; you choose at the beginning of each game how difficult you want your mix to be, then randomly reveal five cards that will be in effect alternately each turn.
Finally, what's a good crew story without some heroic sacrifices? The last expansion adds those; you will have to sacrifice some of your hard-earned crew members in order to accomplish heroic actions that may help you tremendously — but only if triggered at the right time!
This is how I made the journey from the quiet shores of Ancon's lake to the troubled ocean of the Oniverse, full of turmoil, submarine fights, and tricky tides.
The worst game mechanism ever? Probably.
A fun solo/coop game? Grab the dice, and dive into it to find out!
One of the first things they taught us in film school was that when writing a script, you need to write about what you know. Although we didn't agreed with that opinion, inevitably we did write about characters and situations that we had already experienced. Everything about this profession was new to us, and it's unlimited options were frightening, so we needed something familiar in order to get a foothold. It was obviously easier to reproduce something we already knew than to imagine, and then create, a whole new universe. As we grew as artists, we had the chance and ability to venture outside the known and usual stories to create something truly unique and new. That took time, practice, and a lot of hard work.
Some years later, the same happened to me again when I started designing board games. Here, like in the film industry, I was entering a whole new — and equally massive — ocean of potentials, and I needed something familiar to grab and float onto.
So the first game I ever tried to make was about the film industry, a subject I already knew well. As a beginner, I fell into literally all the traps a first-time designer can fall into. My first game was way too long and complicated, it had every mechanism I had encountered, and most importantly it wasn't fun. Thankfully I had already dealt with many, many, many failures and disappointments in my first job, so I didn't give up and I made a second, a third, and many more versions of that initial game. At some point I was confident enough to show it to a publisher, mostly for feedback and thoughts. In no way was it a finished design, but the meeting was positive enough for me to keep at it.
From that meeting, I learned about a national board game design contest that was taking place in my town. I was encouraged to participate in it, but I felt it wasn't the right time to show my design to such a wide audience. I promised to myself that next year I would be ready. In the meantime, I put aside my first game and tried to complete other ideas I had. Some were very promising, and some were unimaginable disasters.
Some months later, the next national board game design contest was announced and a friend of mine suggested that I should participate with my cinema game. I felt it was still too complicated and big for that environment, so I decided to make a new game, specifically for the contest, by keeping the same theme and inserting new, streamlined and easier mechanisms. I needed to create a game that could convey the theme of managing a movie studio by using only cards. I wanted a game that would be easier to set up, explain and play than the heavy worker placement and economic game that I had already made, so I tested many different mechanisms and I ended up loving the idea of hand management. As in real life, you need to manage correctly your crew and cast, as a production of anything audiovisual is an extremely long and hard process. I also wanted to incorporate a sense of expansion and progression, so I decided to implement deck-building aspects to the game by adding new crew members that the players could hire to their studios.
The projects at the beginning were only movies, but soon I realized that by adding new kinds of projects, such as television series, commercials and awards, I could add multiple ways to victory, much more replayability, and of course cool new artwork!
Early in the design process, I also decided to make the game two player only as I thought I could manage the balance better and I was able to playtest it more often. In the initial playtests, I was happy with the general idea and direction of the game, but I needed to make sure that players always had interesting choices to make during their turn and were not obliged to play a specific card. Unfortunately by making some big changes to the game, I went to the opposite direction. I though it would be cool to have each type of project always available to the players. That way they always had something to do in their turn, but the problem was that these many options didn't help the pace of the game, and by removing the limitations I had made the game less interesting. By reverting to the original idea of shuffling together all the projects and dealing some of them in the middle, I could create an interesting puzzle again.
Many versions later, I was convinced that the game could support more players, but I wanted to make sure that by adding more players I wouldn't add more chaos, so I decided to incorporate specific set-up patterns in order to ensure that by the time a player's turn came up again, the available projects would be mostly the same.
After a lot of work, I had a version that played 2 to 4 players in forty minutes, and I was confident enough to submit my game to the competition. During that competition the designers would have the opportunity to playtest and showcase their games, and after three months the jury would select the ten best games. The first of the three playtest events was very enlightening because for the first time strangers played my game and gave me feedback. Up to that point, my focus group was friends and family that although sincere still wouldn't hurt my feelings with aggressive opinions and critiques — but strangers didn't care about my feelings and that's exactly what I needed! After the first event, I redesigned almost every card in the game and I introduced goal cards. I felt that players needed a sense of direction both for the entirety of the game and for the early rounds, so setting up objectives that reward fame points for specific strategies helped to guide the players, even those who deliberately avoided them.
With the new version of the game, I went to the second playtest event, where I had the chance to show it to three different publishers! Drawlab Entertainment was the first company that immediately liked my idea and soon we met again to further discuss the game and its potential. From the first moment, their level of enthusiasm for my game won me over, and after months of balancing and developing its core aspects we had managed to create an amazing game based on what I knew best: cinema. The game ended up in third place in the card games category, but I felt like a winner as I knew I had found the best home for my creation.
I hope you will enjoy Motion Pictures: Movies Out of Cardboard and keep enjoying it as we develop more content from the endless world of audiovisual productions.
Motion Pictures on display in the press room at SPIEL 2016
In the present day, new movies, comics, books, video and board games are constantly struggling for our free time. New products come out every day, and many of them are so extraordinary that you just can't miss them. In order to catch all that stuff, sometimes we want to play something fast with just a few components, but at the same time we want to get the same range of emotions and amusement from a larger, complex game. Of course, all designers have the dream of making a game with just a small amount of components and cards, but that has become particularly important recently. We, as designers, decided we wanted to take up the challenge of creating a "minimalist" game.
In fact, it happened that I created the basic concept of Behind the Throne during just one single evening. There is something archetypal and basic, yet fascinating, in the mechanisms of "pressing your luck". However simple at core, I like these games a lot. It is always interesting to me to try to assess risks in these games. It's funny when you find out that you scared yourself in vain or (vice versa) you were too self-confident. That's why I like the idea of number comparison, and the ability to predict the risk seemed interesting to me.
The next morning, I made the prototype and showed it to my co-author Oleg. He was just about to take a break after designing Pirates of the 7 Seas. As this game was pretty light, I convinced him that we would be able to finish it quickly — but of course everything was not as easy as I had thought it would be.
Monsters That Almost Got Main Roles
After several days of testing, when we had determined the basic properties of cards and their values, it was the right time to make a "true" prototype, with actual art and layout, partly because I perceive a game much better when it has at least some art, which helps players to memorize specific cards and so on, but also because we had decided to give the game to our friends to see their reaction.
The game is quite abstract and almost any theme would fit. It could be based around animals, robots, aliens or something else. I decided it would be nice to see on cards some funny monsters that help their lord to win. Their appearance should help the players guess their abilities.
I went online to search appropriate images, preferably with a consistent style, and I was delighted when I found a series of very original monsters, just like I needed. Each of them had its character; they were very skillfully drawn and made everyone smile. There was even a back illustration for the cards! However, I couldn't find the contact data of the creator! That is how the game almost became a game in which the main characters were funny monsters.
After that, I started looking for an artist. I wrote to several people we worked with earlier, but after a few sketches, we still had not found the right style. Those monsters I had found were so awesome that we couldn't create something we liked as much if we insisted upon sticking to this theme, so that's when we decided to change it.
Politicians and Their Games
Together with the talented Ukrainian artist Denis Martynets, who worked with us on Pirates of the 7 Seas, we started looking for a new theme. It so happened that my friend dropped in and started talking about politics, conspiracy, and corruption — and suddenly I realized that this theme fits the mechanisms perfectly, even better than monsters. This theme allows you to control different people with the different abilities useful to you, outbid them, and try to surround yourself with the most influential people.
Denis made a few sketches. We were looking for a medieval look. Although this topic is used a lot in games, it allows for very colorful characters. We also added a little bit of fantasy, and to make it less grim, we focused on the grotesque. Oleg and I both didn't like the first two sketches in terms of proportions and style. Denis was about to refuse this job, but I convinced him to try one more time, and with this third attempt I was amused and convinced this was just what we needed! The character looked great. By the way, this card is the "judge" card today.
Balance of Powers
We worked on the game's balance for quite a long time. It seems the game is pretty simple and everything is ready, but this is a game with just nine types of cards (and they must have certain numbers), so there were a limited number of elements we could tweak for tuning the entire balance. Every little detail has a huge influence on the gameplay. We had a large number of different versions of the game and balancing it all took a few months until we got the desired result. We finally decided on the abilities and how the game should finish in order to keep the intrigue until the very end.
For this I have to thank our colleagues from Ares Games. They were the first ones who believed in this game and helped us with the final version. They were very patient, in spite of the fact that balancing of the game delayed its finishing much longer than we planned. By the way, there were originally tokens in the game; you can see them in the pictures which appeared with the announcement of the game. We used them to indicate cards with invalid abilities, but the constant shifting and placing irritated us. And Oleg, after he returned from one exhibition, brought a great solution, the idea coming after explaining the game to one of the exhibition visitors who constantly forgot to add or remove tokens. That's when Oleg figured out how to help him. It was a simple but effective solution: just rotate the cards when their power cannot be used! Ever heard of it?
Behind the Throne
Finally, we had to choose the name of the game. We thought we had found the right one, which fit well all the various intrigues, different fights for the throne, and backroom conspiracy: "Gray Cardinal". The name is derived from true historical events and one famous individual whose activities made famous this well-known term.
But this idiomatic expression translates differently in different languages. For example, in English it sounds like "Behind the Throne". We wanted a name to be the same in most languages, so we decided to use this title because it expresses well the main point of the game: Players are influential people who can have different levels of impact on the same characters.
The Experience vs Luck Factor
Does luck have a great impact in this game? Of course, but it is not decisive. You have to be careful and take risks in this game. I can also give one piece of advice: Do not ignore card exchange in this game. It is actually a very powerful thing. And, of course, you may well instigate others against the leader. That's politics!
Awaiting Players' Reaction...
Behind the Throne has just released in English and will soon be in the hands of players in the U.S., Europe and China. Its premiere was in Poland, surprisingly, but that is where we premiered our Mysterium game as well, so it happened again that an Ukrainian game appears first in the hands of our good neighbors. It almost looks like a tradition!
I hope you will enjoy the game. We have put in so much effort. We would appreciate your feedback! We accepted the challenge of minimalism. If we coped with it or not, you will decide — now it is time for a new project!
In this designer diary, I'll cover my experience of balancing a design using concrete examples from my new game Steel Arena: Friday Night Robot Fight. Also, there will be some words about what the game is and how it was designed and developed.
Part I: Genesis
My first published game, Kosmonauts, received a lot of feedback like "game is cool but where are lasers, guns and other stuff?!". The next one, Labyrinth of the Mirrors, was even more peaceful. The worst thing that you can do in this game to your opponents is snatch valuable treasures right under their noses. (Okay, you might add evil laughing to increase the effect.) Finally, my manliness broke through and I became obsessed with designing a game in which you
should MUST fight, shoot, burn, blast, and produce other kinds of destruction on your enemies.
I was thinking about the game setting and found that probably the best would be combat between giant anthropomorphic battle robots.
Early robot concepts
The second idea was to build your own death machine during the game from different modules. Some of them should move your robot, others rotate it, and of course there should be a lot of different deadly weapons. A game turn should consist of activating one of those modules and using its special ability.
Since game balance is extremely important for me, this game balancing was a real challenge. There should be a lot of different weapons, and all of them should be not only cool, but also effective in comparison to one another.
Early weapon tile concepts (text in Russian)
All my game design experience tells me that I should start to think about balance even earlier that I start to create specific modules. If a game is balanced on the core level, it will reduce the number of required tests and make development easier and faster.
But what is balance? I have read a lot of definitions of game balance, spent a lot of time thinking about it, and can finally state it in the following way:
A game is balanced when every game element has comparable application area in comparison to other game elements of that kind.
"Game elements" are quite broad in conception, including not only cards, units, weapons, building, etc., but also tactics, strategies and even player order. The application area of game elements is the set of game situations in which a particular element is more preferable than all (!) other elements of that kind.
Part II: Types
In this game of destruction, you will construct your robot during play, so my goal was to give players real, multi-valued choice of which modules to collect and in which order — but before I started to create modules, I thought about their types and the core mechanisms of the game. There should be at least three types of modules: moving modules, rotating axes, and (naturally) weapons. To balance them, I used irreplaceable abilities technique.
Move, turn, and attack modules—early versions (text in Russian)
The idea is that you can provide comparable application area by giving each game element a special function. That function should be not only necessary for the win, but also irreplaceable with other game elements.
So why do robots have to use weapons? Because it is the only way to win. Specifically, the player who destroys the most enemy modules by the end of the game wins.
Why do robots have to use moving parts? First, through movement they will collect new modules. Why is this important? Because the modules that will be collected are more powerful than the starting modules. Moreover, during the game even more powerful modules will appear on the battlefield (which should also give us tension mounting during the game and an epic finale).
Second, movement is essential for the same reason as rotating axes; robots have to be mobile to move and rotate quickly. Without this ability, it will never get a chance to attack opponents. Moreover, a slow robot will be an easy target.
Second generation move, turn, and attack modules
So all three module types have to be used and therefore they have to be collected. (If you remember, robots need to replace weak starting modules with more powerful ones.) And the question of which module you should take/use has different answers depending on your chosen strategy, present tactical position, and current robot status. On the basic (or "zero iteration") level, we give to every module type theoretically comparable application area and as a result may think that they are preliminary balanced.
Of course it is only a hypothesis, and of course we need to create specific modules and test them a lot of times to prove it. Moreover, we probably will change some things (or even many of them) in the game after tests. But the fact that we design the core level of the game considering the balance will save us a lot of time because we will make many fewer modifications and adjustments.
I know that most game designers think something like "let's create basis of the game, let's make it work, and after that maybe we will do something with the balance", but all my experience with both my own games and my colleague's games that I have helped to balance tell me that it is a mistake. Usually it is much easier to completely recreate a whole game than to balance it in its current state.
Part III: Comparison
When we are going to create a group of balanced elements, the most obvious way is to use a points system. Every element has the same number of points as all other elements. Points are spent on parameters, so when you make some parameters high, you have to make some others low. Every ability also has a price in points.
As far as I know, this is a quite popular technique, but for this game I had to use another one. As we considered in the first part, game elements are balanced if they have a comparable application area in comparison to other game elements of that kind. So I decided to create a standard for every module type; when I created a new robot module, I immediately compared its application area with the application area of the corresponding standard. If their application areas weren't comparable, I changed the module and compared them again until success.
Sometimes I needed to make a module more powerful than standard, but in this case some negative attribute needed to be added to recoup the balance.
For example, both EQUALIZER and O.R.C. are ranged weapons with damage 2, but since O.R.C. is a rocket launcher, I gave it high shot and explosion abilities with one penalty: it is a single-use module. So there are many situations when O.R.C. is preferable, but also sometimes you would like to use your weapon more than once per game.
When all modules of some type was created and basically balanced, I compared them to each other and corrected them if their application areas weren't congruous. Let us consider some examples of mentioned comparison:
Dimensional application areas are good for move modules. The tiles to which you can move using the WALKER module are indicated by number 1. CRAB could move your robot to tiles with "2". If you need to jump over an obstacle or enemy robot, FLEA is definitely your choice.
For some cases, it is necessary to analyze the time domain to compare application areas. It is especially important for auto-cooling modules. (Most other modules have to be cooled before their next use; all modules are cooled during a single turn.)
In released version, its named CRUSH
For example, CRUSH 2 with the auto-cooling ability deals less damage per turn then CRUSH 3, but after the second turn it has better results since it does't need to be cooled. Thus, CRUSH 3 has an application area in one-turn attacks while CRUSH 2 AC is preferable in protracted fighting.
After every module was compared with all other modules of its type (the first iteration of balancing), I compared combinations of modules (the second iteration). In this game, there is no need to compare every combination, but only combinations that have emergence — new properties that appear when you use both modules. Melee weapons, for example, become very effective if you have speed move module.
Moreover, the combinations of weapons and enemy armors have to be checked.
In Steel Arena, I did not recalculate the application area of modules after the analysis of their combinations; I found that for this game that I needed only to avoid much too powerful combos, but for some games such recalculation is necessary.
Of course, I used many more techniques to balance the game, but let me finish and not to make a draft on the reader's patience.
Using the described approach, you have to spend more time during the creation stage, but that work can save a lot of time later when you test and develop the game. In Steel Arena, I changed just a few modules due to balance problems after dozens of tests. Of course you still have to test the game a lot of times, but during those tests you can focus on the other important things: player interaction, gameplay deepness, replayability, etc.
My name is Martin Looij, and I'm a board game designer from the Netherlands. I love scuba diving, traveling, and board gaming (in that order). From July 2014 until May 2015, I was traveling through North, Central and South America, and while hanging in an overland truck for up to 14 hours a day, I started thinking about making a board game about my #1 passion: scuba diving.
I have been scuba diving since I was eight years old, and I still absolutely love it, so I started designing a board game about diving with sheets of paper, markers, and used egg cartons. In the picture below, you can see me working on Scuba in Baños, Ecuador.
From that point on, Scuba kept developing rather quickly. From the start, I focused on making Scuba as realistic as possible, but I quickly realized that it is hard to translate the concept of diving into a board game. After all, diving is very relaxing and that would translate to boring gameplay, so I had to come up with realistic ways to design an interesting board game. This is where concepts such as "currents" and "dust trails" came in.
In real scuba diving, there often will be currents that affect your dive. Sometimes you will make a drift dive, which is starting at point A, then drifting along the current and finishing your dive at point B. Since this is something exciting, I wanted to implement this into my game. After some experimentation, I decided to go with the element of surprise. Before a player starts diving on their turn, they draw a current card to see whether there is any current and which fish (or divers) are affected by it. In the game, currents mean that fish could swim out of the diving area, so when other players discover them, you can't just wait forever to see them, too, which adds a sense of urgency to the game.
In real diving, you don't make trails of dust. You will be trained properly so that you hover above the bottom of the sea without touching the floor with your fins. In Scuba, however, dust trails are a given. I added this element because otherwise it would be too easy to follow other players and spot their fish as well. In the game, you leave a trail of dust behind you that will stay for one round, during which other players can't see any fish that are on a space with your dust. (The cubes are used to indicate dust.)
While I developed the basics of Scuba, I was traveling through Ecuador and was still using egg cartons and pieces of paper. Then we hit Peru, and in a small beach town, I was able to find three magnetic chess sets to upgrade my "designer kit". With these sets, I had a game board and enough magnetic pieces to stick small pieces of paper on them with letters and numbers to indicate the type of fish. Pawns were also included in the set, which I could use as player pawns. This might still sound like a poor prototype, but it was a huge step up from the small cardboard pieces that were all over the place.
In the following months, I kept working on making Scuba as realistic as possible, yet an exciting and fun board game. I introduced events that made the game more exciting and thematic. When diving in the game, you can now find treasures, get grabbed by an octopus, or get seasick.
One of the event cards
There was still one crucial element to include in the game: air. You start with 20 units of air. This is 200 bar of 3000 psi, but non-divers can just call them units of air (as long as you don't call it oxygen). The implementation of the air in the game was actually quite easy. In diving, the deeper you go, the more air you use, so I used that principle in my game. When diving at 0-10m (0-30 ft), you use 1 unit of air. For every 10 m (30 ft) lower than that, you use one additional unit of air, and that worked out really well. On the board, you can see the amount of air you will use at a certain depth.
The air you use at certain depths
When the mechanisms of the game all came together, I started searching for an artist and a graphic designer. Whenever I had decent wi-fi — I was traveling through South and Central America at that time — I searched for artists with a style that would fit what I had in mind. I ended up contacting a few of them and asked whether they could send me a sample card with a turtle on it for $30.
The first three artists also tried their hand at the graphic design. (Note that turtle 3 and 4 are made by the same guy.) I asked the Dutch board game community Bordspelmania to help me choose between these artists, and I ended up settling with artist 3. Artist 4 made an awesome turtle, but was too expensive for this project and couldn't work fast enough on the 18 animals, box, and board needed for the game, so I decided on artist 3: Shaz Yong from Malaysia. I didn't like his graphic design well enough for this project, and just as I was about to start looking for one, Sebastian Koziner from Argentina saw something about my project on BoardGameGeek and dropped me a message saying that he was interested in the project. He would do the graphic design for one card for free to show me what he could do. He sent me his design, and I instantly loved it. So how did the card with the turtle end up? Like this:
Final artwork of the turtle (graphic design not yet final)
Now I had a concept, an artist, and a graphic designer. When I came home in May 2015, the next step was playtesting. Over the course of the months, I used all sorts of playtesting: local game clubs, Dutch and Belgian board game conventions, and many blind playtest sessions. I made three prototypes and they made quite a journey. I optimized a lot of game rules and by November 2015, playtesting was done. I sent the games out to video reviewers and went from game designer to game publisher.
Meanwhile, Sebastian and I worked on the Kickstarter page. Video reviews started to come in and luckily they were all positive! The most common conclusion of the reviews was that the game did a good job of portraying the feeling of scuba diving, without getting boring. Since this was pretty much my exact goal when starting designing the game, this felt like a huge victory!
The Kickstarter funded and was delivered a month early, with the game also being available at SPIEL 2016. Now you know how Scuba was made!
The journey of Honshu begins in the first quarter of 2014. I had played Patchistory twice in January 2014 and really liked the patching aspect of the game. The rules were not very clear, but what we gathered as a whole was a good experience.
The patching thing stuck to me, and I was wondering how I could make that more accessible to players? I hadn't played any other patching-like games (Hanging Gardens, Flix Mix, Edo Yashiki, Sunrise City, Heartland, Java, Taluva, Marrakech) at that point — well, Poseidon’s Kingdom but the patching aspect is very low in that game. I wanted the components to be easy to prototype and readily available, so basic cards were the choice. How could I distribute these cards among players before patching the cards together?
Trick-taking was the answer right from the beginning. Tichu was a game that I really learned to play in the first quarter of 2014. While Tichu is a climbing game and not a trick-taking game, the distribution mechanism idea for Honshu can be derived from my love of Tichu and trick-taking games. It is easy to understand, and players can have some interaction with it. I wanted the game to play up to five players and first thought that the lower limit would be three since two-player trick-taking isn't very interesting.
Trick-taking also can be used to determine player order. Win the trick go first, play the lowest go last. From the start I wanted the player order to be fluid and not locked in clockwise order. This opens up tactical play as going last in a trick is very good; going first is also good as you can pick the card you really want. I wanted a flowy vibe for players, allowing you to find a purpose to affect your own place in the order. This also links to the quality of the cards, but more on that later.
That was the foundation of Honshu: trick-taking to distribute basic playing cards and determine player order, make a map from those cards, player count 3 to 5. Then came the questions: What are players building? What are the pieces on the cards? How does the trick-taking work?
The prototype I made was thematically just a city-builder in the modern era called "Parks & Pavements". The reason for that theme and name is that my first published game — Councils & Contracts in 2013 — was a city-builder and I wanted this to be the second part of my small city-builder series. So what elements do cities have? Roads, houses, parks, water areas, factories, stores and (of course) land. Those were and pretty much still are the land types of the game.
Finished city map of Parks & Pavements
What each element did was pretty straightforward thinking. I could have longest road, resources delivered to factories, and single parks. Land was and is nothing, easy to replace. Water areas were also nothing, but they couldn't be replaced, so water was just bad without any upside.
During the prototype phase, the game was divided into four parts. First, you played three rounds of trick-taking. Then with the cards you collected, you made the map. Then you gave the rest of your cards to your neighbor. The "play three rounds until map-making" was there to give players some room to think. The change cards rule was — and still is — there because I wanted players to have an incentive to play high-numbered cards. This helps the map-making part and also gives players a little information of which cards can be played in the following three rounds.
The other important rule in the prototype was a size restriction on the map that a player would build, taken from Patchistory: You could build at most a 9x9 grid. Restrictions didn't stop there as the cards had numbers both horizontally and vertically. This was done as each number had to be readable from the player's viewpoint. (See the leftmost card in the image below.) The quantity of each number in the deck was very different as the numbers went from 1 to 10, with only four 10s, ten 1s, and the other numbers falling in between those two. Finally the cubes, in four different colors, were suits. In the trick-taking phase, you could make a card a particular suit and it thus became trump.
Map card phases through development
That was the prototype phase. The contract between me and Lautapelit.fi was signed in early 2015. I must say that I really like working with Lautapelit.fi; I know many from that company personally, including the owners; have had game nights with them; helped them promote gaming in Finland; and overall have a great working relationship with the firm and the people operating it. They know what they do and want to develop prototypes to a polished product, as was also the case with Honshu.
Then came the development phase. The theme was thrown out the window, and a medieval theme was suggested. (Limes was the inspiration here; see the cards second from left above.) The game got a working title — "TriXity" — that would have been a great name for the game. Lautapelit.fi wanted the game to be more family-friendly, so the size restriction of the map and the facing of the cards went away. I had no problem with those changes as they reduced the number of rules to be explained, while the gameplay didn't really change. (I still play with the self-imposed restriction of the map size from time to time.) The "play three tricks, then build" rule was also gone as it bogged down the game. It was like fun, fun, fun — then wait for all players to build. Since the building restrictions were now gone, it was better to use the pattern trick-build-trick-build since that toned down the waiting quite a bit.
During development, it was suggested that each element in the cards should have something "good" in them, which meant that water areas needed to change. Thus, water in groups now earned points. I still wanted them to be little hindrances, so the first one is bad, but if you plan ahead, you can get a pretty good score from water areas. This was the first change made to the prototype.
The card numbers from 1 to 10 were also gone pretty quickly, which was a good thing as it took care of the tie-breaker rules and simplified the game. Now the numbers were just 1 to 60. At this point, I recalibrated the cards for the first time as the previous version had the cards of higher value be better. I wanted the cards to be distinct from the phases. A card that is good in the trick-taking phase should not necessarily be your best choice in the map-making phase. If that were the case, then the game would be a multiplayer solitaire as players could pretty much play their hand cards right to their map.
I introduced more things to the game, such as the B-side of the start cards and personal scoring cards. These were introduced because we wanted variety for the game. The B-side start cards are interesting as they put the players on different paths right from the beginning. Personal scoring cards were introduced so that players had a focus right from the start. However, these scoring cards were the last thing in development to change and they became an optional part of the game with one card being used for all players instead of one card for each player. (With four players, you can still try the "one card for each" variant if you want. I like to play like that.)
Until this point, the player count had always been 3-5. As my usual gaming partner is my wife, I wanted Honshu to be playable with two players. However, as I said earlier trick-taking isn't fun with two players, so what to do? The map-making part didn't need any changes as each player makes their own personal map. It took a few tries and very many losses to my wife, but I think that I came up with a good system for two players to replace the trick-taking. The main questions were how to have as many cards available during the game as with higher player counts and what to do with the resource cubes. The answer was card pairs and simultaneous play. Players lay down one pair of cards, then draw another pair from the deck; each player then collects a pair and picks one card to place in their map. Each "trick" was now four cards, and players basically had the same options as in four-player game, but what about the resources?
My initial idea was that by using any two cubes, the losing player could win the hand, but you had to use the cubes before the "normal" winner of the trick chose their pair of cards. However, my wife sometimes plays a mean game and really liked the idea that the "winner" could actually lose the hand unexpectedly. Well, I liked that idea also, and the rule was changed so that the loser could use any two cubes to win after the "winner" had chosen the pair. With this system, the normal loser of the trick can spare their cubes if the not-chosen pair has something good to place in the map. It is not nice and I haven't seen that in any other game, so that is how I got the two-player game working.
The last part of the development was the involvement of the artist. The final theme idea came from the artist, and the final name was discussed for a lengthy time. I suggested "Mura Ezu", which could be interpreted as "picture map of villages" and one other mention-worthy title was "Torihiki" — but when "Torihiki" is translated into Finnish, it means "market square sweat". In the end, Honshu came to be the name, and it is a good name.
Pretty quickly the final art was done and layout began. The last thing that had to be done was the rulebook. While I wrote the first version of the rules, there might be 20% of that text in the rulebook. That is a good thing. Rulebook writing is the hardest part of game design for me, and fortunately Lautapelit.fi employs a few great minds that read and really understand rulebooks. At this point, I made the last changes to the game. The suits were gone; now a cube added to the card gave it a boost. This change got rid of about two hundred words in the rulebook without changing a thing. People without trick-taking knowledge can now get the game more easily, but people with a card-playing background still recognize them as suits. The final change was the final calibration of the card numbers based on playtesting.
The cards can now be divided into three groups: the higher cards are easy to place in your map and give okay points; the middle cards have the four-point factories and score the most possible points; the lower cards have the majority of the resource-producing squares, but also a high number of lakes that are more difficult to place. With these groups, you hardly ever pick up the card you play on the trick, so goal achieved.
Finally with all the rule changes made to the game during development, the rulebook is a condensed source of gaming goodness.
Honshu went through a great development process. The starting idea for the game is solid and fun, but after all the steps we have made to take out unnecessary restrictions and rules, keep up the tempo, and make things clearer, Honshu has become a great fusion of two established mechanisms. While my name is on the box, the development team of Lautapelit.fi are the unsung heroes of Honshu. A big "thank you" for believing in my idea and making it a great game! I sure hope that you, the players all around the world, enjoy this game as much as we do.
I still remember the day when I first came up with the idea for Solarius Mission: It was in summer of 2011 and I was working on the facade of a house. I mused about various mechanisms and suddenly an idea came to me: spaceships, which would be represented by dice. The number on top would represent the "class" of the ship, and this could change during the game — but why spaceship dice? That would be a smaller element of a great space game in which you would slowly conquer the universe — like in Twilight Imperium. I spun my idea further and as I had to start somewhere, I invented a simple game step by step, comprised of tableaus, cards and those same dice as spaceships.
I can't remember anymore how exactly I came to this mechanism, but it definitely was inspired by the "dice-building game" Quarriors I wanted a similar theme as in Race for the Galaxy, so at first I named the (dice) game "Dice for the Galaxy" as a working title because it sounds good (although it's an entirely reasonable free title).
Anyway, I wanted to represent different areas of a civilization with different colored dice, so I established the four colors. Then I took a bag of twenty dice in four colors (which, incidentally, were mainly the somewhat larger cubes of the first edition of Agricola) with the sides painted with a different number of points. Thus I had created a "dice-mechanism". The four colors/areas are those now in the finished game.
This was followed by some initial tests and I quickly realized that the mechanism was somehow incomplete. I made cards with actions and a game board in space. In this early stage, the game worked like this: The player drew dice from their bag and rolled them (like in Quarriors!). With the different colored dice/points, you could make different actions. Black dice were spaceships flying in space, with yellow you could draw action cards, with white draw additional dice from the bag, and brown were resource points.
So I had designed a simple system that worked somehow, but there was no progress: Via the action cards you could generate resources, more dice and also victory points, but that was it. I had to bring developement into the game and not static card effects.
Not much later I got the idea that I could represent development with dice on a tableau, and you could use the action dice to turn (upgrade) and slide the display dice. Turning was technology (white) and slide was "number of dice" (brown). Thus, you could make more efficient use of upgraded dice and you could pack more dice in the bag with "number of dice" — an ideal and easy way to show development of a player.
The first tableau was comprised of four rows and five columns. In there, the display dice were placed.
At this point I showed the game to Ode and he really liked it. Anyway, he had time and he read my first rules and commented on them. These rules from October 2011 were already in such a state that you could understand and play the game.
Every player had as many dice in their bag as they had free spots to the left of the display dice on the tableau. You could draw 4-6 dice and roll them, then you had to decide for each color of the dice where you wanted something to do with it: Yellow gave money (which was already used for dice manipulation by the way), white was enhance display dice (turn) and brown was slide display dice. The black dice were placed directly in front. These were the spaceships that attack all the other players at the same time, equally strong (a Quarriors! mechanism). For conquering, there were planets in the form of cards that specified as a "condition" different colored dice with different values. If I want to conquer such a planet, I had to use the specific dice with the appropriate points and voilà!, it was mine. These planets were worth points and whoever had the most points won.
I refined this version even further. At some point I realized that I had packed too much stuff into the game, even including rules for space fights. The game was, for what it was, simply overloaded and it no longer clicked. I sent this version to the Hippodice Competition 2011 as a game called "GalaxyDice", but I got a disappointing rejection. The game remained like this and only after several months was it reincarnated in a different version.
In the winter of 2011/2012 Ode and I started to discuss the game intensively. Our conversations resulted in Ode starting to develop a game from scratch. This then created a whole new game, which shortly thereafter, also thematically, chose a different path and became "Bauernhof-Bauer" (and later La Granja). There was no satisfying solution for DFTG, so we focused together on the new game.
I still kept working on my version with the space theme. This time it should be a civilization-building game, with players colonizing planets, managing resources, and tracking life points. Via space battles, the planets of other players could be attacked. Having no colonized planets meant your home planet could be destroyed at any moment. Once the entire life points of the home planet fell to 0, it was "game over" for you.
The dice mechanisms had to be revised because each player always used four dice sequentially. This downtime was almost unbearable, so I developed this mechanism, which was quite inspired by La Granja. With this we were very happy for a long time and only in the last year of developing have we again revised and refined it. Also around this time, I experimented with so-called "maneuver" cards through which the players could "level up" their actions and also fight in space combat. These maneuver cards introduced for the first time something similar to conditions through which one could increase their combat strength.
I tested the game for several rounds and kept working on it. On paper, the concept should have worked out, but it didn't. It was too easy for the other players to destroy everything you've accomplished. The game didn't feel balanced at all. On top of that, it took far too long for a game of this type.
At some point I realized that the game has a big "building up" character, so it had to be provided with Euro mechanisms: Instead of players destroying planets, they should colonize them, with the planets providing VP for a fixed number of rounds. (The end of the game was variable at this point.) High dice rolls should be punished, so I introduced pollution (waste).
You should be able to do more than just fight with your spaceships, and that was the birth of "primitive" space. The basic idea was that it includes 25 squares: 20 normal planets and 5 special-function planets, laid out face down in a 5x5 grid. The players started with only one spaceship on their side of the table, moving into space to explore planets with certain conditions. These conditions I split in the four colors and also marked on the backside of the cards as a hint of what you had to expect. As soon you fulfill the condition on a planet, you colonize it and put it next your tableau. In the middle of the space, I put additional planets with special effects and a +1 VP token on each. Every later colonized planet is placed beneath any already colonized planets, so every planet underneath a +1 VP token gives +1 VP. This design choice supported a rush ahead to the valuable planets rather than players just worrying about the planets near them. Soon after, I let all the spaceships start from the same side, but placed the valuable planets on the other side of space. This was a much bigger challenge as the players where in a race for the same planets.
Planet, special-function planet, development, standard planet
In addition to the planets, which were to be discovered in space and colonized, there were standard planets to be settled. These were made as a fixed display and could be "bought" with resources. They have specific effects on the game and they also provide storage space for waste.
Developments that players were able to establish brought various different effects, variety and replayability because each game featured a different selection of developments.
I prepared this version of the game for the Hippodice 2015 competition, I applied for it and sent the rules and game description. This time, a prototype was requested of the game, and in the end it landed on the recommendation list for the year.
Early in 2015 Spielworxx showed interest in the game. At the end of 2014 Ode and I agreed to join forces again to continue working on the game together. After a short playtesting period from Spielworxx, they agreed to publish the game in 2016, so we all thought about how to tie up the loose ends of the game, to shape and harmonize the big picture. We agreed on Ode taking the lead for this and I would take over the creative part in the further development.
Ode wrote a long report on how to change space and several other elements, and that was our starting point for redesigning half of the game. Many elements stayed, while others were changed or expanded — but the main aspect of change was the space. Before the change, there was only a small display of cards.
Space went from a small display of cards to a big board using a grid of hex spaces
At this point, space became a big grid of hex spaces painted on a board. The planets had fixed places in this grid, but additionally there were bonus tiles giving the players one time advantages when exploring those spaces. The player mat (tableau) was expanded to hold a number of hangars for multiple spaceships so that players would control a whole fleet.
Space now had certain endings, so new to the game were "final frontiers", i.e. frontiers of known space. Thematically this was meant to be the ultimate challenge to the players: Send out their exploring spaceships and find out about the outer limits of the galaxy. When reaching a "final frontier", the ship and contact to the ship was lost. They sacrificed themselves for science on a research trip with unknown dangers. The nation that had to mourn that loss now turned to an even better future, starting a science plan in order to honor the sacrifice of their heroic ship and crew. The player gained a victory point condition that grants a bonus for the end of the game. This victory point condition tile needed to be placed in the now empty hangar to remind the nation of the heroic and brave crew (who obviously went where no man had gone before).
Depending on the time the player gained that VP tile, there was another bonus tile given to the player. The earlier in the game this sacrifice was made, the more points the player could get.
The hangars are full of light-blue research tiles; in the personal display are orange-colored research planets that were once part of the game
The final scoring was expanded so that it would be possible to gain victory points from multiple sources. Back then I called them "sun points". By expanding space and the possibility of building more spaceships, the game got very dynamic. Building spaceships was quite important. The motto was "The more the better!", meaning that in order to win it was not optional to have more than one spaceship. You just had to decide whether to use them to do many things or sacrifice them to have valuable VP conditions. Wouldn't that be thematic? But we felt it was still a flaw in the design that you had to build more ships in order to be able to win.
Splitting the player turn into a die action and a supplementary action was always our idea. Every space flight consisted of up to three movements because you were able to have a maximum of three spaceships, and this raised the downtime. Our reaction was to create a new flight phase at the end of a game round. Thus, instead of having up to three movements with each supplementary action, we reduced that option to only one movement with any one ship per action, followed by a flight phase at the end of the game round in which the players would move every ship they had. (We had six game rounds back then.)
By reducing the maximum number of movements of spaceships, we reduced downtime, but nevertheless it was important to have all your spaceships early in the game to use the ships as much as possible. Another important point connected with this was that in order to colonize planets, the players needed to leave their spaceships on that planet as long as it took to colonize it. Once a player started colonizing a planet — that is, claimed it from the board and added it to their playing area — they needed to have their spaceship connected to the planet's colony as well. The motivation to complete the colonization was high because once the colony was erected, the player gained their spaceship back, ready for their next mission in space.
The small central board then, with a VP track, dice display and the track of power which was responsible for bringing the centers of power to the galaxy
Aside from the personal player components like colony discs, space station octagons, and mission cubes, there was a neutral gaming piece: The centers of power. You would go up the track of power as an action in order to erect one of those centers one day. The centers rewarded all gaming pieces by any player adjacent to this with bonus points in the end, so being able to place them was a huge advantage because you could choose the best place for yourself. In addition to this scoring opportunity, we added a scoring of the dispersal for the players. Depending on so-called "nation cards" there were different scoring conditions in the hand of the players. The cards showed a condition for how to spread in space. Every player had one secret card in their hand. All of them would be scored at the end, so it was important to observe the dispersal of the other players in order to be part of their "nation card' scoring.
Research effects and standard planets were also in a constant change. Not only the effects, but the cost and reward for the elements were always in flow in order to gain a better balance. Standard planets were changed thematically to space stations — partly because there were so many different types of planets in the game, including a phase in which a fifth kind of planet was available: the research planets. The new modular board had no defined sides anymore and no "Final Frontier" spaces. Instead of VP conditions by claiming research tiles, the players could complete the requirements of the orange-colored research planets (gas planets in space that needed to be researched). This fifth kind of planet had no relation to one of the four action-related colors. Instead the players needed to have some shapes or clusters in space consisting of their own gaming pieces, and forming these clusters in space was very valuable.
At some point, the centers of power were renamed to be commercial hubs. Instead of letting the player erect those centers, they now popped up in space randomly and had the additional job of being game round counters. What's more, players could deliver their resources to those commercial hubs to gain VPs. In order to do so, the players needed missions or delivery tasks. These new tasks were printed on the same cards as the research effects, so a card can now be used as research or a mission. The problem with the research effects is that they get more useless when played late in the game — a permanent effect is best played early so it can be used over and over again — so by adding the missions to the progress cards they were balanced for the whole game. The research effects get unattractive, but the VP-giving missions were still important. So again we have a multi-use card in the game; if you know La Granja, you might recognize our enthusiasm for multi-use cards.
Back when we had four phases per game round the player aid looked like this:
A – dice action, B – supplementary action, C – use space stations, D – flight phase
The game was in progress all the time, but it had many too many elements. The feedback from the playtesters also said so. The playing time was 3-4 hours. The downtime was high because of the structure of one game round. Our editor from Spielworxx always lead us in the way we needed to let go, so Ode did a huge cut. Once again players had only one spaceship, which removed the need for the flight phase. Research planets were banished from the board completely. The personal scoring cards from the players hand left as they were a constant distraction. The number of game rounds was six back then, with four turns per player per game round for a total of 24 turns per game. We reduced the number of actions to three and shortened the game by a quarter. Later we went back to four turns per game round but cut two game rounds, making for a total of four rounds with four turns each for a total of 16 turns per player — one-third from the original 24 was gone.
The screaming by the playtesters was loud! They liked the game and Ode had just reduced it by a third — but the anger did not last long since the game feel got better and better. We were down to a playing time of two hours with four players, yet the game was still complex enough to be challenging. The playtesters who knew the game before were still missing some things, but everybody was sure that the changes worked out pretty good for the game. It gained focus and felt well-rounded. The dead freight was gone and nobody really missed the eight (!!!) missing turns. The editor nodded in wise silence.
Modular board and the bonus wheel on an extra board
But the most important change to decrease the downtime was the change of the structure of a game round. Up to this point, in every round a number of dice were drawn from the bag and rolled. Each player chose one of the dice in playing order to perform one turn, with the remaining die being placed on a certain board to indicate the bonus the player would gain if they took the die in later rounds. After four turns, the game round was over. The problem was that the starting player of one turn was the last player in the next turn, so they had to sit through six whole turns of die actions and supplementary actions when playing with four, which was endurable only by reading a good book — even without analysis paralysis at the table.
Thus, we chose to change the structure of a round and introduced a new element. The old side board had a place for the dice display that showed certain bonuses for untaken dice, but what if we played just one turn at a time proceeding clockwise for the entire game without having a change after the game round. To do this, we couldn't have a pool of dice that would empty after a few turns; instead we need a constant pool of dice available each turn — but doing this would disrupt our old bonus system that relied on the unchosen dice being shifted along columns to indicate the appropriate bonus.
The solution to this problem was the first time we were inspired by another designer. Uwe Rosenberg is a friend of Ode, and while Uwe did not invent the wheel, he made it a great element for board games. Games like Ora et Labora, Le Havre: The Inland Port and Glass Road use this wheel wonderfully, and this inspired us to create our new bonus wheel! The wheel was a new, constantly changing pool of four dice. In order to always play in clockwise turn order, the old La Granja-styled dice distribution had to go. The bonus wheel was able to use one turn of the hand in order to change the value of the bonus for all dice at once. A lesson well learned after many playtests and talks with Uwe.
By using this bonus wheel we reduced downtime, and again the feedback from the playtesters about the game feel got better and better.
After balancing the game over a period of six months, we called it quits and stopped development of the game. It was ready. The always stunning Harald Lieske started drawing wonderful pictures, and the publisher started writing a 20-page rulebook and an 8-page glossary for the game. Finally in the middle of 2016, our game took off to space: 10 – 9 – 8 – 7 – 6 – 5 – 4 – 3 – 2 – 1 – 0!!!
Thanks very much to Ode for sharing his perspective for this diary and not forget to mention a BIG thank you to Grzegorz Kobiela for (some) translation and proofreading!
Asger Harding Granerud
Soon to be published!
I've always been drawn to racing games, and my favorites include Snow Tails, Ave Caesar & Tales & Games: The Hare & the Tortoise. The simplicity of the goal is something everyone intuitively understands: Get. There. First.
Yet this simplicity also hides a tough design challenge. You have to balance accessibility and game length (since races are rarely slow cumbersome affairs) with a catch-up mechanism: too strong catch-up and early stages of the race don't matter; too weak and the game can be a foregone conclusion sooner than you want. Decisions clearly need to matter throughout the race, and as a designer you still want a good race to end in the tension provided by a close sprint. A single minor misstep shouldn't put you out of the race completely. Moreover in a pure racing game, you can't distract players by adding engine building or side quests. You have to keep players entertained simply by the tactics of the race at hand, while making it engaging enough to keep people coming back.
This is the story of the making of such a racing game. I have been told by people with real credentials that I succeeded in meeting this challenge, and Flamme Rouge has earned a sweet spot with hardened gamers from Australia, over the U.S., and across Europe. Hopefully I've even created a game that could become one of THE classics of the genre, but only time will tell if you agree. Suffice to say, I'm immensely proud of Flamme Rouge, and I hope you will enjoy it. I still do every time, even though I'm more than three hundred games in!
"Flamme Rouge" (red flame) is the name of the red triangle flag that marks the last kilometer of all grand tour stages. It was first introduced in the Tour de France in 1906 and has been a staple ever since. It helps riders know exactly when they should be 100% ready for the sprint.
Note: I am not a hardcore cycling fan, and it is by no means required to enjoy Flamme Rouge. It is first and foremost a great game, though I will challenge anyone to find a better theme to match the mechanisms!
Why Dominion & Magic: The Gathering?
It started on a cold weekday in December 2012. My apartment had been invaded by a horde of carpenters and plumbers, and thus I found myself exiled to my childhood home for some weeks.
There was no one else at home that particular evening, thus I found myself sitting in the dark on a bench just outside the front door, having a smoke. As happens so often in those situations my mind drifted to board games, and on that occasion it drifted to Dominion. What made Dominion such a success? Why had everyone gone crazy over the innovation of deck-building, when years ago I and thousands other people had clearly been doing it in Magic: The Gathering?
Outside the front door of my childhood home in Copenhagen
I don't want to detract from the success of Dominion or MTG (nor CAN I!), yet the thought stuck in my head: Dominion isolated a single aspect of MTG, and subsequently expanded it to become a fully fledged game in its own right. That formula should be possible to apply to other games: isolating one aspect and creating a game around it. My mind still circling on Dominion, which single element could be expanded into a game on its own? The element I personally enjoyed the most was the feeling of optimization involved in deck-thinning, specifically buying the Chapel card to facilitate it even when it wasn't the best strategy. Seeing as your deck in Dominion "recycles", having few cards means you get to see each card more often. Thus, if you remove cards from your deck and ensure only the best cards remain, it eventually creates a lean, mean, VP-buying machine. Why were there no games (that I was aware of...) designed to focus solely on this deck-thinning concept!?
The idea for Flamme Rouge had popped into existence just then. Still in the same sitting, I pondered on what would thematically fit a deck-thinning game. What would fit a game in which you started with a deck of cards and gradually depleted it, while striving to have the leanest-meanest machine at the end? The analogy that came to mind was spending energy, which once spent would leave the deck and thus thin it — yet a player would also need to preserve key doses of that energy for the finish.
Energy consumption and preservation. Energy consumption and preservation. Energy consumption and preservation. Cycling! Racing! Cycle Races!!!
Various stages of early prototypes
Once that connection had formed in my mind, it felt as if everything fell into place in short order. Cards would have numbers that represent how far you move. Each rider in your team would have a distribution of different numbers, and that rider's entire deck (15 cards eventually) would be the total energy reserves for the whole race. In cycling, you don't want to be leading the race throughout as the wind resistance exhausts you in short order. Two simple rules were introduced to simulate this: slipstreaming and exhaustion. Exhaustion adds cards with a low average to any rider ending a turn leading a group, effectively diluting their energy reserves by filling up their deck (a milder form of the Curses from Dominion). Slipstreaming provides bonus moves to well-positioned riders hanging back in larger groups. This created interaction en route to the finish line. You want to hang back, but not too far back, and want to lead, but not all the way up front.
Cycling being a team sport, I decided to include two riders per player, with different characteristics defined by their distribution of energy cards. The Sprinter has a low average but a high top speed, which was reversed for the Rouleur, a tempo rider with a higher average but lower top speed. The other advantage of two riders is that you could now use one to screen the other.
Early sketches of the miniature cyclists
The whole process had taken 30-45 minutes, and I vividly remember having a feeling that this should work! My gut feeling was that strong. In theory, whether there would be interesting choices should be a matter of adjusting the total energy per rider in relation to the total distance needed to cover. If the distance is too short, then the best strategy would simply be to play your highest card each time. If the distance was too far, then you would almost never have an incentive to play the high cards, but simply hold back. If the distance was just right, then small gains and losses each turn would accumulate to help find a winner at the end.
I decided to try to make Flamme Rouge a game that as many people as possible could enjoy. To make it "family friendly", I removed all unnecessary complexity by picking the most streamlined variants of slipstreaming/exhaustion/tiebreakers/etc. I also added simultaneous play to create a faster game flow and reduce the room for analysis paralysis as the game moves from calculation to second-guessing, risk-taking and a little bit of bluffing — much like real cycling!
At the first live tests, I tried a few different slipstreaming variants and a couple of different deck configurations. Some ideas worked, some did not, but I had a strong notion about where to go. Already from the second prototype the game was 95% of what it is today. My then girlfriend (now wife!) isn't a gamer, but was the first victim of the second prototype and I knew I was on to something when she asked to play it three times straight. (This has never happened since...) Hundreds of playtesters subsequently reinforced that impression and revealed the same semi-addictive nature of the game. Strangers asked to buy it, and fans even made huge and elaborate versions for themselves!
A fan-made mega version (I'm on the left)
The many playtests also proved that Flamme Rouge had lots of room for expanding the game play. Each time a new group tried it, they returned with ideas. Different track and rider types were the most common ideas. From the start I wanted to include mountains to ensure players could pick different stage profiles to ensure replayability. I'm very proud of how smoothly they integrate in the core game and how intuitively they alter gameplay in accordance with real life cycling. The rules for mountains can be summed up to "a capped move of 5 and no slipstreaming". That is it. Though simple, such climbs really change the dynamic of the game and shift the advantage from the Sprinter to the Rouleur. More exhaustion cards are handed out, less slipstreaming occurs, and breakaways are more likely to get away. In turn, this means there are many points of tension throughout a race, even sprints to be the first to reach a climb. In conjunction, going downhill simply makes your card count as a minimum of 5. They are slightly harder to activate because you have to start your turn on them, and you can still expend energy to make a break on a downhill section when everyone else is relaxing.
I don't know how many thousands of possible stages can be made, but there are 21 double-sided tiles that can be strung together in numerous combinations. We have included six pre-designed stages in the game that we have tweaked and tested again and again. Several of them have been made by guest designers that enjoyed the game enough to assist by developing these. (Of course they've been bribed with beers and promises of a copy of the game.) Thanks to Anders Frost Bertelsen, Max Møller, Hans Lerche, and Daniel Skjold Pedersen. A particular big thank you goes out to Daniel since he also came up with the name.
Prebuilt stages: not all in the box as one is a promo
I think that the publisher Lautapelit.fi went above and beyond the call of duty on this game. They've previously done well known games such as Eclipse and Nations, and I'm thrilled that they've taken me on board with what is essentially a much lighter Euro. Not only with the artist they've hired, but the amount and quality of components they've put in the box is excellent value for money. I just got my hands on the first production copy the 30th of September 2016 (days ago!) and have laid it all out on my dining table for you to see.
There is just SOOOO much stuff in this box!
In most racing games, there is a natural push towards being in the lead. After all, that is how you eventually win. However, the combination of mechanisms in Flamme Rouge means that you actually don't want to be in the lead until "the right time". This creates an interesting situation in which positioning in relation to the other riders (your own and others) becomes paramount, and results in tension from start to finish. Naturally the positioning is most important at the end, but if you neglect it early on the incremental gains and losses that are handed out each round, your actions may favor your opponents instead of yourself.
As a result, the race naturally takes on distinctly different phases based on distance to the goal line, geography of stage and potential breakaways, much like real cycling races. (I feel I've said that phrase a lot.) First there is a build-up phase, then positioning, and finally a head-on sprint. An emergent narrative arc, if I may call it that. Executing your strategy, coordinating your riders, and second-guessing your opponent becomes integral to succeeding. Breakaways sometimes win, but more on mountain stages than flat sprints where the pack very often catches rogue riders, when they eventually have exhausted themselves.
I am extremely excited to show the world Flamme Rouge! It holds tension throughout the game, escalates towards the end, and has simple and accessible mechanisms that fit the theme incredibly well. I'm not personally a big cycling tour fan, nor have the playtesters been, but it doesn't detract from the experience since it is first and foremost a solid and engaging game.
Kind regards, and check my BGG design blog for more details on this game and others!
Asger Harding Granerud
Sniffing the first production copy ever. Absolutely thrilled!
Back in 2012, Among the Stars was published by Artipia Games. It was a card-drafting game with a sci-fi theme in which players tried to build space stations. It ended up going very well, having a big reprint a couple of years later, localized versions in various parts of the world, as well as a co-publication with Stronghold Games. It also gave birth to various expansions that added numerous new things to the game.
Since that time, Konstantinos Kokkinis (the president of Artipia Games and a close friend) kept telling me how cool it would be to have a game with the mechanisms of Among the Stars, but with a farming theme: "Wouldn't it be cool to have these square cards represent fields in a farm?"
This wasn't a one-time suggestion. Every few months he would pose the same question but always with a "half-joking-half-serious" attitude. My reaction was always the same: "Meh."
You see, I've always been a huge sci-fi fan. Although I'd play farming games and I'd enjoy them, I would never place them (theme-wise) above sci-fi. "Why would someone want to play the same game with farms over space stations?" was my way of thinking. (Boy, was I wrong!)
Come early 2016. I was at the offices of Artipia Games and we were discussing options for the company's main game at SPIEL 2016. Once again, the farming-themed Among the Stars game was mentioned, but this time it was different. It wasn't mentioned as a half-joke; this time it was 100% serious. I have to admit, I wasn't thrilled with the idea. I tried to offer alternatives. I listed reasons against it. But the tide wasn't turning. Everyone else was agreeing it was a great fit and that it would be really popular.
With a heavy heart I agreed to work on it. Luckily, the plan wasn't for me to do everything on my own. Konstantinos (who was super-excited with the whole idea) would help with the adaptation and we would share design credits. He was already writing down various ideas and suggestions on how the game would be.
Our first task was simple: How would this game differ from Among the Stars? Yes, it would be based on that game and would have many similarities, but one thing I definitely didn't want was to just have a retheme. This game should be able to stand on its own and offer a different experience to the players. Someone could easily own both in their collection and not have to choose over which one is better.
One of the first things we discussed with Konstantinos was the introduction of a new type of abilities. In Among the Stars, we had immediate ones (their effect was applied when you built them) and delayed (their effect was applied at the end of the game). In this game, we could introduce end-of-round abilities. The theme allowed for recurring abilities as they would be part of the harvest season so that fit perfectly.
Regarding the card types, after some discussions we settled on having four types instead of five: fields, animals, buildings, and "miscellaneous" (basically, whatever else we could think of that didn't fit in the previous categories).
Since we were changing things in the game, it was a great chance to address some of the complaints we had heard about Among the Stars. Many players said that although it was very enjoyable, they were worried a bit about the set-up time, especially when including many of the expansions. With "Among the Farms" (our initial nickname for the project), we knew we had to make set-up as easy as possible and in such a way that additional content from future expansions would not take more time. During a brainstorming session, Konstantinos suggested we do what New Dawn was doing. This was a game designed by him in which each card type was in a separate pile and players could choose what exactly to draw. It made sense to apply the same logic in our new game. Instead of drawing six cards from the same deck, there would be four piles and players would draw their new cards in any way they wanted.
Another change we discussed was getting rid of the scoring track. We thought it would speed up the game not to have to adjust your marker every round and just focus on the cards you play. Scoring would be easily done at the end using a scoring pad. What we weren't realizing at that point, though, was how hard it would be to have immediate effects in the game that would not grant you points. Since scoring would happen at the end, they had to have different effects.
We also had to take a look at the game's resources. Money would remain, but energy had to change as it didn't make much sense on a farm. It was, however, easy to change. Making it water, something much needed on a farm, made perfect sense, so we went with that. We also explored the possibility of additional resources. There would be many different types of plants, there were many animals — we had many options on what to do. In the end, to keep things simple, we settled on just using one more resource: food. This would be the product of the fields, and it would be used by the animals. In short, fields would require water and animals would require food.
That's where it started to become more and more apparent that the game would offer a different experience than Among the Stars. This was now turning into an engine game. You have water towers that produce water. You plant fields, and you use your water on them to produce food. You use that food on your animals in order to make money. And then, you use your buildings to turn money into victory points (VP). That's also when I became very excited with the project. Here was the chance to create something new and different; I could explore design space I couldn't in the original game and that was great!
The final thing we added that would change the game even more (compared to its predecessor) was a series of tracks. Instead of having the players gain a fixed amount of resources each round, there would be tracks indicating what they would get. Card abilities and players' actions would advance their pawns on the tracks, making them gain more resources as well as VP at the end of the game.
Up to that point, most of the above was mainly in discussions as we hadn't tried all those ideas yet. It was time to build a prototype and see how it played. I started making some simple cards to see whether everything was working. Suddenly, a ton of other details that we hadn't thought of became apparent — but that's what playtesting is for, right?
The signs from the first playtests were very positive. Most of what we had thought of was working. Maybe an adjustment would be required here and there, but for the most part, the game was turning out very nice. The exception to that was the tracks. While everyone commented on how they differentiated the game from Among the Stars, the impact they had was not that great — and sometimes people ignored them altogether. In other cases, a player would focus on them, lagging behind on the development of their farm. The rest of the time, people would be doing roughly the same things. Although it sounded like a good idea, it ended up not being fun, so I knew they had to be changed. Some other ideas were explored, but they made the game more complicated. The harvest abilities were already requiring more from the players (thinking-wise), so we didn't want to make things even more perplexing.
At one point I thought of tiles that the players would place on top of their locations, with these tiles having an ongoing ability. For example, you could increase the range of a water tower or the production of a field. I made a few of them and tried them out, and they were really interesting. They couldn't all have ongoing abilities, but that wasn't too much of a problem. On top of that, the theme was very nice; they would be equipment that you use to improve your farm.
With the main "skeleton" of the game in place, it was now time to take a more detailed look at the card abilities. That's where the studying started. You see, in most of my games, I want the abilities to be theme-driven. In this one, I didn't want to take abilities from Among the Stars and rename them, nor did I want to just stick names to cards randomly. Of course, my knowledge on all things agricultural was quite limited which meant only one thing: Internet to the rescue! I started reading a lot about growing fields, taking care of livestock, and running a farm. My goal wasn't to make a 100% realistic simulation, but I did want the abilities to be tied to the cards' theme.
The process went like this: What field could I use? How about "X"? Okay, let's see how X is grown. Many articles later I would hopefully read something that I could "translate" into game terms and make an ability for the card that would be interesting and fun. In the end, not only did the abilities turn out more thematic, I also learned a lot about farming (to the annoyance of my friends to whom I would randomly say something that I had read about).
All this time, the playtesting would continue. Abilities would change, new ones would be tried, even small changes in the core rules were tried when needed. Luckily, the general consensus was very positive and it showed me that I was on the right track. In the end, the feedback from the players helped a lot to shape the game to its final form.
Unfortunately, despite his involvement in the initial brainstorming sessions, Konstantinos wasn't able to participate a lot afterwards, so he decided it was best that I be credited as the sole designer. I thank him a lot for that, especially considering it was his idea that started everything!
After a long process, the game is now ready. It has been produced and is about to make its debut at SPIEL 2016. So far, the reception it has gotten has been very positive, both during its Kickstarter campaign and here on BGG. It turns out that the farming theme is actually very popular. Konstantinos was right to suggest it!
1 , 2 , 3 , 4 , 5 Next »