Archive for Nicholas Hjelmberg
1 , 2 , 3 , 4 , 5 Next »
This is the thirtieth of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
The first idea
Find the Bug! Project is a good example of a game design that evolves from both mechanics and theme. The roots of the game stretch back in time to Politburo, a game of which I wrote the following:
"The inspiration to Politburo actually came from my professional work, where political differences often delays or even prevent work from getting done. The step to the totalitarian theme of my two previous micro games Comrade and Gulag was surprisingly small. The initial idea was to have a project with three different priorities, time, cost and quality, and where each player would want to prioritize one or several areas to score the most but where all areas must score something or the entire project would fail (causing all players to lose), resulting in a blame game."
That simple idea fit the black humor of the Comrade series very well and the project game was shelved. However, many years (and games played) later, the idea of designing a more serious game about projects returned to me. Kanban: Driver's Edition showed me that you can design a fun game about project deliveries and Food Chain Magnate showed me that it can be fun to manage organizational hierarchies in a game. Even such different games as Concordia and Carpe Diem helped with ideas. The former gave the idea of playing different cards and spending a turn to "reset" and getting cards back. This would create a balance between many weak cards with few resets and few strong cards with many resets. The latter gave the idea of using those reset turns to place "seats" between goal cards (steering group cards) to "influence" which steering groups to evaluate future projects. This would give players a hint of which priorities to focus on.
What would be the objective of a project game then? To succeed with projects. How would you measure success? Against the time, cost and quality budgets. Who decides the budgets? The steering group. Thus, in a project game the players would assume two roles to optimize the "victory points" (the budget margins): as project managers, they would supply the optimal mix of "resources" (time, cost and quality), and as steering group members, they would adjust the "demand" of resources (the project budget). To make things more complicated, they would participate in each others' project and sometimes cooperate but most often compete with scarce resources and conflicting objectives.
A typical game decision would look like something like this. I have a team of developers and testers. There are some upcoming projects with a tight time budget. There are also steering group members willing to prioritize time higher than cost. Perhaps I should send a developer on training (and increase her cost but in exchange get a senior tester delivering on less time). Then I should also make sure that the steering group will reward time more than cost and perhaps cooperate with some other players. This sounds like a game decision that's both interesting and thematic.
Turning the idea into a game
So far so good, but how to turn this into a playable game? Imagine the scoring procedure if you would first have to compare the time spent with the budget to get the total victory points for time, then assess each player's time efficiency, then allocate the individual victory points based on this time efficiency, then multiply the score with a priority factor to indicate time's relative priority, and finally repeat for the cost and the quality. Such a game would need an accompanying spreadsheet!
This challenge nearly stopped the game until the breakthrough came. Why not skip some of the steps by listing both time and time efficiency to the action? Say that you play a senior developer to a project. Such a role would increase the cost of the project but also the time efficiency by the project. When the project is completed, there is no need to calculate an exact time efficiency, only to check if the time budget was met and if so, exchange each player's time efficiency tokens for victory point tokens.
The next challenge was how to incorporate quality. Should it simply be treated as the same kind of resource as time and cost and thus rewarded with "quality efficiency"? This could work but felt a bit dull and almost solvable. After all, the Find the Bug series is about finding bugs so the game should make this part a bit more interesting. How about letting testers add not quality but tests with the ability to detect random bugs?
After some iterations, I came up with the following basic project model:
5 development boxes (1 VP each)
10 test boxes
Risk level 3 of 5, equal to a 50% of a defect (-1 VP each)
Time budget 5, Cost budget 5, Quality budget (test boxes without defects) 7.5
Spent "time units" 5 (of which half on test), Spent "cost units" 5 (of which half on test)
Detected defects 2.5, resulting in 7.5 test boxes without defects
Time vs budget 0, Cost vs budget 0, Defect vs budget 0
Thus, in the basic project, time and cost will be spent exactly according to budget to deliver a quality exactly according to budget. Say that the project spends 1 extra time unit on test. This will give all the players +0.5 VP (since 0.5 additional defects can be expected to be detected. However, the players investing in time efficiency will lose 1 VP (since the time spent exceeds the budget by 1) and thus get a net loss of 0.5. This will create exactly the kind of tension between different project interests that the game aims at simulating!
The below cards illustrate the basic game flow. The first (project) card shows a project with 5 development cubes and 10 test cubes. The initial risk is 2 out of 5, which equals to 4.5 bugs on average, and the budget is 5/5/8 (time/cost/quality). To increase the variability, the budgets are half-sized cards that are randomly allocated project cards and the risks are triangular chits that may change during the game.
The second (project member) card shows a developer that may be assigned to the project. This will let the player take 1 development cube (D) and place it in the cost reward box and add 1 to the time budget. When the project is completed, the cube is converted into victory points, depending on how well the cost budget was met and how much the steering group prioritized cost.
The third (steering group) card shows a steering group that prioritize time first (triple the victory points), then quality (dobule the victory points) and last cost (no multiplier).
Balancing the game
The next challenge was to balance the game by ensuring that the different strategic paths would be worth an equal amount of cubes, leaving it to the player interaction to tell the players apart (who manages to set up a team that best avoid competition, who manages to secure steering group priorities that best match projects and so on).
Some designers argue that testing should balance the game but as a professional in the testing business, I know that testing cannot create quality. Instead, I had to come up with conditions for a simple simulation table and feed different strategies into it. Assuming that each project requires 10 cubes to be taken (5 development and 5 test) and that the number of projects equals the number of players, each strategy would have to return 10 cubes in about the same time. After some further iterations, I came up with the following results after 15 turns (where "X" equals reset):
The iterations answered many questions in relatively little time. "Vanilla strategies", where you only play with 1 or 2 project members, return 7-8 VP and are inferior to more elaborate strategies, which return 10-12 VP. The strategies in the lower end of the VP range return VP early and are likely to benefit from the best projects before the strategies in the higher end get their VP engines running. Some other important learnings from the iteration were that the leads need 1 cube to be trained and the scrum/devops teams need 2 cubes to be formed (or else they would be too strong) while the trainers and recruiters need to become senior automatically (or else they would be too weak). They also helped assessing the average number of steering group seats given to the players and thus the suitable number of steering group cards. The iterations could easily be extended to analyze shorter and longer games to capture obvious imbalances.
Testing the game
Naturally, not even the best iterations can replace testing but the important conclusion was that the core of the game was balanced and that any imbalances would have to be created and exploited by the players by competing in budget areas, manipulating the game time etc.
Thanks to the iterations, I already had different strategies to pursue in the testing. The players first built up different teams with different strength and then went on to select projects and steering groups that would give them the most return for the effort. As designed, time was critical in the early projects, when the teams were mostly junior, and cost in the later projects, when the teams were mostly senior.
The game worked but felt a bit too much like an engine building game without drama, e.g. players would just run their engines till the game end and then count VP. This observation inspired several tweaks that not only gave the progressive gameplay more peaks and troughs but also felt thematic.
Budget penalties for overspending a budget so that exceeding one budget to get a better margin on the other budget is less viable and a mix of junior and senior team members is encouraged.
Quality bonuses for all budget areas so that an exceeded budget may still earn VP.
Risk rewards with easier but less rewarding projects and more difficult but more rewarding projects so that different projects are attractive at different stages.
Program rewards so that early presence on projects is rewarded.
Retirement rules, earlier for senior members, so that the players must plan to constantly renew their teams.
Those tweaks turned the game from a balanced optimization exercise to a game of intertwined strategic and tactical paths where the players must keep an eye on each other to find the best ones. Find the Bug! - Project may be less accessible than Find the Bug! and Find the Bug! - Agile but it's also more challenging.
This is the twenty-ninth of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
The origin of Dyce is traceable to several sources of inspiration. One is my long term idea to create an epic city/empire building game, where the events of the Swedish empire would shape the rise of Stockholm as a commercial center for the empire's supply and demand. The end of the game would see a complete city where the streets and the buildings would have found their places not through central big decisions but through the "invisible hands" of the players' individual small decisions, similar to how real cities grow.
This city-building aspect is also something I liked in Lisboa and highlighted in Preview: The Rise of a Beautiful City and a Beautiful Game. This part of the game focuses on commercial aspects by encouraging similar stores to be placed close to each other.
A third source is The Game Crafter's Contest Game Pieces Only Challenge, where only non-printed components are allowed. A natural idea was to use the only "printed component" allowed, namely the die, which holds both a color and a number. Translated into an economic game, the color would represent a good and the number would represent a price.
Additional sources are the games Alchemist, where cubes of one color are converted to cubes of another color, and Kairo, where the customers' movements between shops are simulated.
Finally I had so much inspiration that I couldn't help but putting it all together. I tried to convince myself that I really only wanted to test a mechanic in a smaller game for the contest to see if it could work in a bigger game. The truth is probably that I simply couldn't resist the temptation of designing yet another game. As often in my design process, the first ideas were quickly scribbled down on the nearest piece of paper I could find.
One of the requirements of the contest was to make the game so simple that the players wouldn't have to consult the rules too much. Such a requirement excluded complex conversions between goods so it was natural to use the commonly known rules of color mixing, e.g. blue+yellow=green. The first level of goods could then be blue, red and yellow and the second level of goods could be green, orange and purple. Later on, I added a third level as well: black for mixing all three first level colors.
In most resource conversion games, it's the players themselves that move or build routes to trade the necessary resources. For this game, however, I wanted the players to build static trading points in a city to attract suppliers and customers. Hence, I connected the dice to non-player merchants, moving around in the city according to preferences dictated by their dice. A merchant with a yellow die followed by a purple die would first be looking to sell yellow for a price according to the first die and then buy purple for a price according to the second die. In the case where a good would be offered by more players, additional rules were added to create "artificially intelligent" merchants (move to the closest, move to the best offer etc.).
Having reached this far, it was time to decide on a setting. Given the components, trading in dyes felt appropriate so why not call the city Dyce (dyes+dice)? I made a quick Google search to find out if this was a real name and it turned out to be the name of an Aberdeen suburb. Unfortunately, Scots are not known for dyes but they are known for whisky and whisky is often blended. Why not simply let the players trade and mix whiskies instead?
With that, I felt that I had enough to build a game on. Since I couldn't have a physical game board, I set up an "imaginary grid" of 5x5 spaces around a central castle (which worked good in the Scottish setting as well) and surrounded it by the dice. Since each "space" would hold a house component with a number of cubes representing whiskies and meeples representing the merchants, it should be easy enough to see and play on such a grid.
Next, I started looking at the necessary components, partly to ensure that the game cost would be below the contest limit and partly to have some indicative numbers to start balancing. For the dice, I needed to balance the different colors so that there wouldn't be too few or too many of a certain level, otherwise there would be "useless" dice in the game that might cause the game to drag.
This mix would have an exact match between first level colors and higher level colors:
2 blue+2 red+2 yellow=1 purple+1 green+1 orange
2 blue+2 red+2 yellow=2 black
However, I feared that such a combination would be too scripted, since there would most likely be enough first level colors for all higher level colors. To introduce some more competition, I added 1 purple+1 green+1 orange. With this mix, a player would no longer be able to go for black dice and rely on getting the necessary lower level dice, since another player may use them for other blended colors.
The above figures were also used to assess the value ranges of the whiskies. Since six sided dice are used, a range of 1-3 for the first level dice and a range of 4-6 for the higher level dice was suitable. Then an input of 2+2 on average would return an output of 5+5 on average. Bear in mind that it takes three turns to accomplish this so the profit of six pounds must be reduced by the alternative cost of three pounds for simply passing three turns. The same applies to the black die with input 2+2+2 foroutput 5+5+5 - a greater return but a higher risk.
For the number of shops, I first calculated with four players and six shops each - enough for each player to place one shop per color in the 24 squares of the city. When the black die was introduced, the players would be one shop short but I decided to keep the number anyway as an interesting restriction.
The cubes (representing whiskies) were trickier to calculate, since I hesitated whether limited cubes would make the game more challenging or just frustrating. In the end, I went for the middle way. The competition would be more fierce and fun if there were just about enough cubes for all players to enter a whisky market. In that way, the players could either play "friendly", and leave cubes for everybody, or aggressively, and disrupt the balance by taking more cubes than needed to exclude others from a market. With one cube to place in a shop (to mark which color it trades with) and one cube to trade with per player and color, eight cubes of each color would be enough. Later, I reduced the higher color cubes to four of each color, since the player could simply turn first level cubes into money directly without turning them into higher level cubes inbetween. For the money cubes, I went with 48 white (12 per player), which hopefully should be enough, and for the victory point cubes, I went with 12 clear (3 per player). Why clear? Because ice go well with whisky.
The colors of the players and the merchants would unfortunately have to be the same as the dice due to the limited color availability. Here I used the first level colors of blue, red and yellow (and white) for the players and the higher level colors of black, green, purple and yellow for the merchants.
The turns and rounds
The initial iterations were done in Excel. First I tested "small turns" where one player action would be followed by one merchant action, but the decisions became too obvious (attract the merchant currently due to move). The game became better with "big rounds", where all players would act followed by all merchants, but this was quite unforgiving to players that failed to attract a merchant in the first rounds. Next improvement was to give the players several turns to either act (and improve their offers to attract the merchants) orpass (and earn money while waiting for better opportunities), similar to games like Amyitis.
The solo version
The solo version of Dyce turned out to be quite interesting. I've added it in previous games, where the solo game can be played with the same rules as the multi-player game. In those cases, the human opponents have been replaced by an objective that must be accomplished before the game ends but the strategy has basically been the same.
Dyce uses an idea similar to Find the Treasure! - the Card Game, in the sense that you still place pieces on a board to find objects (whether it be treasures or whiskies). The lack of opponents makes it easier to find what you want on the one hand but itdrives the games faster towards the end on the other hand. If no player (you!) offers a color that a whisky baron wants, his die will be removed and the game clock will move one step forward. You can't stop this since you can't offer all colors all the time by yourself.
The result is that you must use a completely different approach in the solo game compared to the multi-player game. Instead of placing shops close to the whisky barons to get whiskies as soon as possible (before your opponents), you have to place some shops far away from the whisky barons to delay getting some whiskies. This will keep the whisky barons' dice in the game and prolong the game long enough to accomplish the objective. You still need a strategy about when and where to get whiskies but the realization of this strategy will be different.
Putting it all together
With this, the foundation of the game was completed. Since no printed components were needed, I could order everything I needed for my prototype from Spielematerial and start testing! The initial testing gave mixed but very useful results. One player simply didn't get the idea, which I consider a compliment since I want my games to be fairly unique. Those who did get the idea enjoyed the inventive mechanics and the rewards for planning ahead. Another player played poorly and thus revealed how unforgiving the game was. I considered this as a feature rather than a bug but did introduce victory points instead of money to prevent the runaway leader problem where richer players will be able to outbid the poorer ones.
The first complete test game unveiled a very tense game: 9 rounds with theend score 25-25-24-23!
This is the twenty-eighth of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
Warring States started as a retheme of Cosmoclasm. The reason for this was to qualify the game for World Original Design Contest of Board Game, which required a Chinese theme.
However, since this had to be a new game, a mere retheme wouldn't be enough but new mechanics would be necessary as well. The question was which mechanics that could be added to Cosmoclasm without disrupting the core mechanics. The answer was given - by the theme!
The new theme for Cosmoclasm was obvious. Which other period in the Chinese history would be better suited for Cosmoclasm's struggle for hegemony than the period of the Warring States? All that was needed was to replace the factions with the dynasties, the planets with states, the battle stations with strongholds and the modern arms with historical ones (infantry, cavalry, crossbow, chariot, spy). But what could the suits (sun, moon, star and eclipse) be replaced with? I had to go to Sun Tzu for an answer and got much more than I asked for.
In his Art of War, Sun Tzu speaks about four strategies:
When campaigning, be swift as the wind;
in leisurely march, majestic as a forest;
in raiding and plundering, like fire;
in standing, firm as the mountains.
To use those as suits was a simple decision but how could I possibly not use Sun Tzu's strategies for something else? Why not use them as is, as strategies in the game? The arms of Cosmoclasm are used for placing static battle stations and the only way to move them was through a later abandoned faction ability. Why not make the game more dynamic by letting superiorities in strategies be used for manipulating the strongholds?
After some testing, the two pairs of strategic manipulations were determined: move own and others' strongholds and place strongholds inside and outside states. Consequently, the arms symbols were renamed tactics cards to match the strategy symbols and the immobile strongholds were replaced by mobile armies.
How about the "bonus suit", the suit that lets a player play an extra card? It was another simple decision. Since advisors played an important role during the Warring States period, it was fitting to use an advisor for the bonus suit and illustrate it with the most important influencer of that time: Confucius.
With a thematic explanation for all the cards, I moved on the dynasties. This time I turned to Master Wu and his descriptions of the various dynasties was so easy to translate into the faction abilities from Cosmoclasm that no changes were necessary. Perhaps Master Wu had this game in mind?
Last but certainly not least, the new mechanics solved a component challenge from Cosmoclasm: the printed chits. I had long wanted to replace them with wooden tokens but needed some of them to be printed so that a player taking control of a planet could get a control chits with the planet number. With the strategic possibilities to manipulate armies (and hence control), I wanted to reward the first player to control a state to place an extra army in the state (instead of outside the state) and thus the numbered control chits were no longer necessary!
What started as a retheme of an old game turned out to become a very good game and Warring States reached the final in World Original Design Contest of Board Game!
So is Cosmoclasm or Warring States the better game? It's like comparing Go and Chess. In Cosmoclasm, what you place stays and forces you to think carefully where and when your battle stations will be most useful. In Warring States, placement is still important but must be balanced against possible manipulations. Thus, both Cosmoclasm and Warring States have a purpose.
Wed Jul 10, 2019 11:33 am
In the eighth part of The Quest for the Holy (Civilization) Grail Part 8 - Lessons Learned from an Alpha Test, I discussed learning from alpha testing. In this ninth part, I move on to the additional perspectives received from human testers.
After a (too?) long maturity time, I finally demonstrated the core concepts of Peoples - Civilizations for an external test group and ran through the initial turns. The test gave me many valuable insights and confirmed many design decisions but also gave me many questions for the future development.
A pleasant surprise was that the civilization mechanics worked relatively smoothly.
The slow map revelation was perceived as a bit fiddly in the beginning but after a few rounds all civilizations had found their place on the map with plenty of unknown areas left to explore.
The one meeple-one action turns resulted in extremely quick turns and minimal downtime, although the production actions (lay down meeple and take resources) were perceived as less interesting. However, since the civilizations were still in their early stages, the more interesting civilization actions were still rare.
The slow map and the rare civilization actions also meant that the initial interaction was low. This was by design to allow players to lay the foundations for their civilizations first, similar to games like the computer game Sid Meier's Civilization. However, some player styles may prefer early encounters.
The many development cards were, as feared, overwhelming. 15 cards per era or 45 cards in total pose a huge threshold for new players. On the other hand, they also offer experienced players rich possibilities to shape and control their civilizations' destinies.
Those insights inspired several small fixes but also left me with some big design decisions.
One small fix was to let land areas be connected if separated by one sea area only. This promote growth and interaction without the necessity of sailing and is also thematically correct, since water connected early civilizations rather than separating them.
Another potential small fix could be to let civilizations start with level 1 in all civilization advances as well as a number of development cards to speed up the beginning. However, would need more tests with different player personalities first to assess the "fun factor" of the early civilization gameplay.
For the more radical design decisions, I have several ideas to work with.
One such idea would be to scrap the civilization advances and development cards altogether and replace them with a technology board. On the board, a player could choose her own path through the six civilization areas, e.g. move from Economy 1 to Economy 2 and then on to Military 2 (skipping Military 1). Each level would give a small and easy understood bonus, such as +1 food production.
This idea could be easy integrated with a round-based game instead of the current turn-based game.
The production round would see production in all areas simultaneously (and let players with fewer areas produce in some areas more than once).
The civilization round would also see simultaneous actions as much as possible.
Economy could let the players trade similar to in Mare Nostrum by offering as many resources as their Economy level and then take turns to take resources from each other. Resources could then have to be unique when buying things for them, e.g. a food cost of 3 would have to be paid with 3 different food.
Military could let the players pay for attack and defence, perhaps through a secret and simultaneous allocation between players similar to Diplomacy. A player allocating 3 military markers against another player's 1 military marker would get 2 victories used for raiding (cost 1, take 1 resource) or conquest (cost 2, replace 1 meeple).
Culture and Religion could let the players use the markers taken from their technology boards as monuments on the map, as could Civics let the players use the markers as cities.
Science could let the players launch discoveries on the map and either discover new land or establish relations with other civilizations. Relations could be tracked on a relation board, not unlike Peoples - Migrations, and be a prerequisite for interacting with other civilizations through the above civilization actions.
Those ideas would certainly make the game quicker and more interactive. However, it would also limit the players' wiggle room. Instead of combining development cards and civilization actions, they would simply accumulate "cube pushing" bonuses and take clearly defined civiliation actions in isolation. The thematic progress from taking production actions only to increasing productivity and engaging in civilization actions instead would also be lost. The game would be a streamlined and "modern" civiliation game but would it still feel like a civilization game? Clearly the answer can only come from further testing with different player styles.
This is the twenty-seventh of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
The card game version of Find the Treasure has an interesting background that well illustrates my creative/chaotic process. The Game Crafter contest Hook Box Challenge was using their new 18 card hookbox and I had considered submitting a card game version of Turn of Time (which is basically a retheme of Iconoclasm - The Card Game). However, I thought a game of laying and flipping cards would be too simple and abstract for the contest. An unexpected sales of Turn of Time almost made me reconsider but I still wanted a meatier game.
How about a game where you lay cards to build a map instead, similar to Akrotiri? On a Thursday evening, during a floorball session and with only three days left to the deadline, the idea began to form in my head. Cards could be played either as maps or as clues, showing the way on the map. But wouldn't players just build their own routes?
Well, what if the routes all starts from "holes" (cards spaces never filled) and where routes are followed in turn order. The turn order could be based on pass order, hence creating a tension between passing first (and take treasures first) and passing last (and decide starting points). That would add a turn order struggle in addition to the map/clue card management.
With that, I thought the game was interesting enough to pursue, not as Turn the Time - the Card Game but Find the Treasure! - the Card Game. I then spent the Friday evening drafting rules and making art, mainly reusing art from Find the Treasure.
Still, I thought the game lacked some action and when I realized that you could use shards as well, new ideas emerged. During a jogging session, I thought of how to make the map more dynamic and the solution was the addition of pirate flags as movable starting points. By letting the players choose between different starting points, altering them and exchanging used clue cards with new ones, I suddenly had a a GAME not only in the first "map" phase but even more so in the latter "treasure" phase.
The rest of the day was spent completing the all the cards and rules, before leaving for a dinner. Some final details were modified on Sunday morning (thankfully, so that I could get the game out of my head during the following chess game) and I could then spend Sunday evening preparing the shop page, the print and play documents and the draft game video.
Find the Treasure! - the Card Game also got a solo version, something that is increasingly popular in today's board games. As a player, I'm not a fan of solo games where you play against mechanics rather than opponents (although I did add solo versions to my small puzzle games Iconoclasm - the Card Game and Turn of Time - the Card Game). However, the contest encouraged games with many different player counts and I realized that the same rules could be used for solo play as well so why not?
Three days' work is way too little time for designing a game, even a small one like this, but the deadline helped getting the idea out quickly and find the simplest solution at all crossing paths. Nevertheless, subsequent testing revealed that the game was solid enough for the contest and it almost reached the semi-finals in spite of the huge competition (130+ games). Find the Treasure! - the Card Game will definitely be revisited and further worked on in the future!
Wed Dec 19, 2018 12:14 pm
This is the twenty-sixth of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
Fair Trade was designed in response to a call for game designers by Value Add Games. The requirement was very open - a family game illustrating fair trade and the supply chain relation between farmers and traders - but that was enough to inspire me.
I have a weakness for games where the conditions are set by the players themselves and my very first game Nova Suecia was based on this idea, where the players are both producers and consumers. But Nova Suecia is a fairly complex game where land is acquired to create production and consumption, resources are produced and consumed at market prices, and letters are sent home to influence supply and demand. How could this idea be used in an even simpler game?
The answer came to me almost immediately. What if I focused on the two roles of farmer and trader and the traditional euro distinction between money and victory points? The farmers could use money to invest in fair production and get a return from traders, who could use money to acquire fair trade products (=victory points). That would put the players in a situation where they need to invest money to raise money to earn victory points. Very interesting!
The next question was how to gamify this market relation. Again, the answer came almost immediately: bidding is a very powerful mechanism for a player-driven economy. By giving the players a limited set of money and letting them bid as farmers and traders, they would have to manage their economy to minimize investments and maximize returns.
But should the bidding be open or closed? Open bidding works if the offered objects have different values to different players. However, in our economy, money and victory points have the same value so closed bidding was the best option here. Hence, each game round would pose the following decisions to the players:
How much money can I afford to spend this round?
Should I aim for the highest farmer bid (expecting the traders to bid high and aiming for a high income) or a lower bid (expecting the traders to bid low and aiming for a low cost)?
Should I aim for the highest trader bid (expecting to get more victory points) or a lower bid (expecting to pay less for my victory points)?
At this point, the design process had been so smooth that I had to step back to avoid falling in the trap of not finding even better solutions. One idea that I elaborated was to give the players personal farms, where they could either place workers on them (as farmers to increase the production value) or between them (as traders to place bids on several farms). Then a purchase could be executed by simply withdrawing a trader and pay a price based on the number of other bidders, similar to how Spyrium handles bidding. Another idea was to let each round offer different combinations of goods and victory points and let the player collect sets of goods to give the offered goods different value to different players.
However, although those ideas sounded interesting, they would move the game away from the simple family game so I shelfed them for the time being. Perhaps they can be revisited in an expansion? I did give the different round cards different victory point distributions to add some variety to each round but the fact remains that the actions are fairly similar from round to round and the main variety comes from how much money you have left and how much you expect your opponents to alter their bid strategies from previous rounds.
Moving on to the components, I decided early to use unique bidding cards, similar to High Society. Adding the rules to "lock" used bidding cards and prevent them from being used in the following round, I would not only give the players a restriction regarding which bid cards that are available to play but also an opportunity regarding which bid cards the other players cannot play. In addition, I could follow another design advice and number the cards from 1 to 13 to allow them to be used as ordinary playing cards. The decision to use endangered animals as player symbols further strengthened the family look of the game.
The rest of the game design was simply a matter of putting all components together. The card symbols were picked from Game-icons and the photos from Wikimedia. The coins were reused from Nova Suecia while the fair trade symbol, also used as the game symbol, was compiled by free resources from the above sources.
Fair Trade was a return to my early simple and quick designs for simple and quick games. I may prefer heavier games but it's still refreshing to design a filler every once in a while.
This is the twenty-fifth of hopefully many blog posts where I reflect upon my first tentative steps as a game designer.
The inspiration to Cosmoclasm came from many different sources. One was my first attempt at an area control game, Iconoclasm. Indeed, Cosmoclasm first working name was Iconoclasm II until the theme was dropped in favor of the current space theme. One of the unique things about Iconoclasm is the very free placement of tokens, allowing groups to form virtually anywhere on the board and giving individual tokens the ability to become part of and influence many different groups throughout the game. However, the free placement of both own and opponent tokens could also be perceived as too many decisions and lead to analysis paralysis as well as lack of control.
There are other excellent area majority games like China and The King is Dead which don't have this problem. In those games, the cards are used to limit the placement decisions and avoid the problem. However, those games have other dimensions that Iconoclasm doesn't have; the three different majority types of houses, roads and ambassadors in China and the "majority in the majority" in The King is Dead. Yet, the idea that Iconoclasm could be improved didn't leave me.
Another source of inspiration was the Trick Taker Challenge, a contest about trick taking games with a twist. As I hadn't played that many trick taking games, I initially decided to pass the contest, but subconsciously I guess I kept thinking about it.
Finally the third source of inspiration came from Taj Mahal's excellent bidding system. In this game, the players compete for several majorities at the same time and use them to claim point scoring spots on a board. How about letting the players use their card majorities to compete for majorities on the board instead? And how about letting the pieces placed on the board compete for several majorities? The ideas of Iconoclasm and several professional games seemed to meet in one single game.
By that, the game was more or less designed already and I felt that I entered the development stage immediately. Questions to answer covered the shape of the majority areas, the number of suits and symbols of the cards and the theme of the game.
With Iconoclasm in mind, I considered hex-shaped areas first, then switched to square cards for production economy purposes, and then finally settled with hex-shaped cards. For the symbols, I started with four for the four corners of the squares and kept them even after increasing the number of corners to six, since this would leave some corners empty and thus leave some surrounding areas unaffected and more/less interesting for future majority struggles.
The fifth special symbol came early, as I wanted to give the players the power to modify the board. The first idea was to let the winner of the fifth symbol place the next area, presumably next to a corner which he or she has already claimed. However, I was concerned that this would remove control from the other players and make their choices of corners irrelevant. Instead, I made the areas fixed but the order of their resolution variable. This created a good balance, where the winners of the four first majorities could predict the likely order of the future struggles, which the winner of the fifth majority could alter slightly. I also gave the latter winner a bonus card to help him or her take advantage of choosing the next struggle.
The number of suits was initially set to three and further testing indicated that this was a good balance given the five symbols. (Taj Mahal has four suits for six symbols.)
The theme was initially abstract but it quickly became clear that the card and tile placements needed a theme to make sense. Iconoclasm's theme of clashing elements was too abstract to explain the cards so I needed something more concrete. Since the corner placements gave control over several areas, I considered a medieval theme where castles could be placed for each majority in a weapon type (card symbol). A similar theme is used in another game of mine, Mare Balticum, where the players struggle to control historical provinces. However, since Medieval themes are considered too "euro" by many players and possibly by the contest judge as well, I switched to the current space theme with battle stations controlling planets. Still, name Cosmoclasm became a worthy tribute to my old Iconoclasm.
It was also the thought of the contest that paved the way for the asymmetric player abilities, something I normally avoid both in the games I play and in the games I design. But perhaps this asymmetry could be a good thing in an otherwise symmetric game to break potential stalemate situations? I chose fairly light and generic abilities to avoid letting them "play the players" by forcing them into predefined strategies. The ability to switch a symbol, a suit or a card assist in the card playing aspect, the ability to move a battle station assist in the majority playing aspect, and the ability to modify the timing of the planets assist in the timing aspect. All of them come with the cost of forfeiting the play of another card and hence add an interesting decision so I felt I could live with asymmetric player abilities in Cosmoclasm.
This is a continuation of Designing Apokalypsis, in which I discuss the ideas behind the second edition of Apokalypsis.
Spurred by the success of the first edition (and by a component upgrade at The Game Crafter, that allowed more tiles for the same price), I started to think of improvements for the second edition. One idea, suggested by a buyer, was a larger island but then I would need more omen cards for the new areas. Or? The omens of the first edition did not trigger an apocalypse if two similar cards turned up, something that sometimes confused new players. But what if similar cards would trigger an apocalypse in those new tiles? Two storms could strike stormy areas and so on. Thus, the island tiles outside the coastline were born. Another idea originated from the idea of defying the gods. How about certain areas that were either protected by the gods or targeted by the gods depending on their mood? Thus, the temple tiles and their corresponding temple cards were born. For the rest of the tiles, I simply added mechanics that would create a more unpredictable island. The castle tiles could be accessible to some meeples while the mountain tiles could go through the stages inaccessible-accessible before finally turning into water.
In addition to the extra tiles, I also started to look more critically at the game. With only six meeples per color, the score ranged from 0 to 6, something that made draws and tie-breakers frequent. Could that score range be increased somehow? Yes, by giving the gods a bigger role in the game! Instead of playing a people trying to survive, the players could play gods trying to save one people (and score for survivors) and eliminating another (and score for casualties). This would also add a hidden color dimension, successfully implemented in games like Clans. Thus, the open "people variant" and the hidden "gods variant" were born.
But the hidden variant highlighted another issue. With 12 meeples to save/eliminate, 2 actions weren't enough. More actions would not only increase the downtime but also make it even harder to keep your colors hidden. Besides, the concept of only moving 1 meeple at the time was not consistent with the theme of panicked crowds escaping for their lives. The solution was so obvious that I blame myself for not seeing it at once. Instead of focusing on the individual meeples, the actions should focus on the tiles and all meeples on or around them. Thus, the evacuate and rally actions were born.
The second edition of Apokalypsis clearly shows that even a game that appears to be ready can be improved.
In the eighth part of The Quest for the Holy (Civilization) Grail Part 8 - Lessons Learned from an Alpha Test, I reflected upon what you could learn from testing using only a spreadsheet. In this ninth part, I look into how physical prototype takes the testing to the next level.
To prototype, or not to prototype, that is the question. A prototype requires a lot of work; the components have to created, printed, cut and assembled - and most likely completely redone after the first test. I still have my very first prototype of Nova Suecia: The Last Letter Home but none of the components created then are used in the current version of the game. With later games, I stayed in the alpha test much longer and didn't bother with the physical components until the game was more stable. The result was often that once crafted, the components could be used over several tests with only minor modifications. Thus I got more bold (or lazy if you prefer) and started to print my components through The Game Crafter instead of assembling them myself. Yes, it's an expensive solution but it does save time and lets me focus on what I like best with game design - the design of the actual gameplay.
However, Peoples - Civilizations is my biggest game by far, both in terms of components and strategic branches, so the alpha test became a long and cumbersome affair. How well does a certain civilization advance or development card pay off over 10-15 rounds? How do small and specialized peoples fare in comparison with larges and general ones in short and long term? Most importantly, are there any over-powered strategies or strategies that are doomed to fail?
There is a limit to how much a spreadsheet can test in a game like this. To build an automated simulation that covers all branches would take too long. To manually maintain a digital record of all actions and transactions would be too cumbersome and prone to errors. And even if a spreadsheet would be able to accomplish all this, it would still fail to answer the key question: how fun is it to manage all game decision with physical components? In the end, only a prototype could move the game to the next step.
After careful proof-reading, the prototype was ordered together with some new games and some new components for old games. With the exception of the "expected" issues (the occasional spelling error, wrong icon used at one place, the purple color being slightly too dark etc.), the first impression was good. The components had the right size and were easily distinguished from each other, the setup was quick and simple (after the many chits were punched and the many cards sorted that is), and the initial game turns were short and straight-forward. So far the game played as expected. Then came the doubts.
One important change from the pre-prototype testing was that the game speed had to be accelarated. This was accomplished through extra tribes and abilities from the start and lower costs and other barriers for acquiring advances and developments. While those changes looked harmless in theory, they did accelerate some strategies more than others. In particular, the rule that unique resources gave a bonus resource instead of being a prerequisite acquisitions gave some unexpected results which, in hindsight, should have been predicted.
A people starting next to an "early" luxury (available from start) would suddeny get 2 luxuries and be able to acquire an advance whereas before, a second luxury of another kind would have been necessary. This gave peoples with access only to "late" luxuries (available later in the game) a disadvantage.
Solution: Make all luxuries "early" but allow only one group of luxuries to be used at the time to keep luxuries limited in the early game.
A people starting with Economy and any productive development would not only get 1 extra resource but also be able to trade this extra resource with a neutral tribe for 2 other resources, resulting in twice as many resources as other peoples. Granted, combos like this are encouraged in the game but when they come so early, they make all other early strategies inferior.
Solution: Do not add any neutral tribes in starting regions.
Without the need of unique resources, the acquisition bonus for Culture and Religion tokens are worth less. (Why spend actions to save 1 resource when you could produce and gain 2 resources?)
Solution: Exponentially increase the bonus with the number of tokens. This will reward a focused strategy in the long run.
The bigger start areas mean that parts start merging already at the first new region, removing the discovery phase of the game.
Solution: Allow parts to grow a bit bigger before being forced to merge with each other.
Another interesting lesson from the prototype testing was more difficult to predict and shows the importance of physical testing: production actions are fun in a spreadsheet, because they increase the number of resources, but civilization actions are fun on a physical board, because they provide tactical and strategic alternatives to the routinely "cube pushing" that is so common in modern euro games.
But the old rules made civilization actions expensive and the alternative cost for them was high compared to the "accelarated" production actions that they became rare and hence the fun moments also became rare. The simple solution was to accelerate them so that they could be used more often and with greater effect.
Those changes certainly didn't come without pain. The first few turns of the test game were replayed over and over again and I often feared I would have to resort to a slower gameplay or more complex rules. But as is often the case, the simple solutions turned out to be the best ones and once they felt solid and simple enough to implement, the test could proceed. The position below shows the start of a test game where all peoples have taken about 10 actions per tribe each.
The Babylonians have founded an early settlement and even expanded it. Their initial growth has been severely hampered but they will be able to act at a higher rate from now on and it'll be interesting to see if and when they'll catch up.
The Egyptians have also delayed their growth bo spread their Culture. The strategy has already paid off plenty of luxuries that have been converted into advances. How will they best make use of them?
The Olmecs have a strong economy with a high resource production thanks to developments like Herding and Mining and they have also started trading with a neutral tribe. How long will they keep their development lead?
The Romans have focused on expansion and have already made contact with a neutral tribe to exploit. They will be able to take many actions between their Revolutions but will those actions be beneficial enough to compete with the more specialized peoples?
Another interesting observation is that all the four peoples ended up in the same half of the board, although with a lot of lakes separating them, while the other half of the board remains unchartered. Will the peoples move towards each other and will they come in peace or with arms? Or will they race to explore and expand in the unknown part of the world first? The answers are actually irrelevant - the fact that the questions can be asked is a good inidicator of a promising game!
In the seventh part of The Quest for the Holy (Civilization) Grail Part 7 - A Civilization Game that stands the Alpha-test of Gameplay, I looked into the preparations for alpha testing Peoples - Civilizations. In this eighth part, I look into the Learnings from the alpha test.
The alpha test turned out to be quite slow due to the many parameters to keep track of. How many tribes and resources does each people have? Which advances and developments has each people acquired? Which tribes have acted and which have not acted? Which areas are discovered and how are they located relative to each other? An Excel sheet wasn't enough but I had to resort to draft PowerPoint maps as well. Nevertheless, those challenges helped enforcing simplifications. Ater all, if an Excel sheet can't keep track of everything, how is a player supposed to do it?
The images below shows the tables and images I used to keep track of the test games. We see that a player has to keep track of tribes (and later settlements) on the map as well as the six civilization levels and the three resource types (of which each has six specific resources). Add to this all the developments acquired. Any ideas of monitoring all this with player tracks had to be abandoned in favor of individual components for each item and level. Military level 3 had to be represented by 3 physcial military tokens and 3 grain had to be represented by 3 physical grain tokens to avoid a fiddly game.
The Civilization Levels and Resources
This also meant that development cards couldn't be shared among players so either there had to be a limited number of development cards or one complete set of development cards per player. The first solution was used by Civilization but abandoned in Advanced Civilization. Given that some developments felt more popular than others (e.g. Mining to get access to new commodities, although Economy could be used as an alternative to trade for those commodities), I decided in favor of development cards for everybody, although this made an already expensive game even more expensive.
To manage all those items, the player board was designed with spaces for the civilization and resource tokens, which would be moved to an unavailable pool above the board when used.
The image below shows the game state after 53 turns and 8-9 revolutions per player. Although the different peoples explored different strategic paths, none of them ran away or fell behind in the early game but they did lay the foundations of very different civilizations. The map grew at a balanced rate, giving each people enough space while still leaving unknown territories to discover in the mid-game.
However, there were some other issues. One issue was that the game felt a bit too long. The players had only just started acquiring level 2 advances and developments, whereas they should have been close to level 3 given that a majority of the tribes have entered the game and that so few white spots remain. Another issue was that it got a bit fiddly to keep track of enslaved and converted tribes (marked with a square in the image), not to mention how complex the rules for handling them were.
First, we looked at the time issue. The idea that you only act with one tribe at the time, that your people can't advance and develop until all tribes have acted (in the "Revolution") and that advances and developments are slow meant that the sense of progress was limited.
One simple solution was to skip the scripted start and let the peoples start with two tribes, four region tiles and resources (or, optionally, an advance and a development specific to the people for variable powers). The one tribe action was kept to minimize downtime but the cost to advance and develop was decreased (or rather the gain from resources was increased) to allow a people to acquire several advances and developments each Revolution. This had to be balanced against the risk that a people would grow too powerful over a Revolution but in the end it managed to double the advance and development rate.
Second, we looked at the fiddliness/complexity issue. Originally, enslaved tribes were marked with tokens, converted tribes were replaced and marked with tokens and both could return to the original owner through various rules. In addition, it was simply unfun to be the victim of such mechanics. (Note how the Romans have been a menace to her neighbors.). Instead, those abilities were limited to a temporary use of each others' tribes for the current Revolution cycle only (provided that the tribe hasn't acted already).
Did this also remove thematic opportunities like the slave revolts and "conversion from within" that the historical Roman empire faced? Not necessarily, by letting only tribes that haven't yet acted be the victims of such actions, a tug of war was introduced where such tribes were sometimes oppressed and sometimes free. In addition, the use of others' tribes were associated with a cost, adding cost/benefit balance for both players. Hence, the rules were not only simplified but also improved!
Another result of the alpha test was that the open question of events could be iterated and resolved. The initial idea to let the players choose events to "change the history" didn't quite work with specialized strategies. If you specialize in Military and can choose between and a positive and a negative military event, the choice is obvious, as is the choice if you don't specialize in Military. Thus, the events would most likely punish players doing their own ways.
Instead and with the inspiration from Michael Schacht's "book" in Africana, a history book was introduced where pages could be flipped each Revolution. In this way, all the event would be cycled through but not necessarily be open long enough to impact the game. Players would no longer be able to choose the events but they would be able to prepare for those that would have an impact. In addition, the concept of a history book, presented by authentic historians, appealed to me.
As a result of those changes (and of being tired of Excel and PowerPoint), I decided to enter beta test and order a prototype from The Game Crafter. It was expensive indeed and it's likely that most components will be redone anyway but the time saving for crafting all the components myself far outweigh the cost of letting someone else doing it. Besides, it's always fun to receive the first printed prototype and play with it!
1 , 2 , 3 , 4 , 5 Next »