The design of Amritsar: The Golden Temple was born near the beginning of 2021 as a result of the “failed” development of my first prototype, for which I couldn’t find a publisher. I wanted to shelve that design and start from scratch with something fresh, so I got down to work with what would become this game.
At the early stages of development, the game was just a bunch of mechanisms put together, and once I had something coherent and interesting to play, I needed to add a theme. It could have been almost anything since the design is a very abstract Eurogame (I even considered the industrial revolution), but because of how it is played and how the central majority tiles form shapes, I thought about making the game about the construction of a temple, pyramid, or something similar.
Since I didn’t want to make another game about Egypt, Greece, or the Aztecs (to name some popular civilizations), I started to explore other possibilities, then I found out about the Golden Temple of Amritsar. I fell in love with it and immediately started learning about the temple and everything around it, such as the sikhs and its community — and now I am really looking forward to traveling to Amritsar and visiting the temple eventually!
I really enjoyed the learning process and getting to know about that culture and lots of interesting topics such as the reason behind the temple having a door on every side, which is to represent that it’s everyone’s house regardless of culture, religion, and so on. The theme fit perfectly with what I originally designed, mainly because the temple was re-built using three resources (the same number I was using in the game); its reconstruction lasted about three decades (the same number of rounds in the game); the common workers would be the people from the community helping in the reconstruction; we would play the role of personalities such as the Maharaja, who helped by donating resources; and instead of just a round marker, it would have the figure of Ranjit Singh, who would be playing an important role in the game by supervising the reconstruction of the temple and being like the clock of the game.
There were so many cool things about the theme and how it could be implemented in the game that I always thought this was meant to be its theme from the start. Nevertheless, we had to leave out many aspects of the Golden Temple as we couldn’t implement them well into the existing game mechanisms, so we had to focus exclusively on rebuilding the temple.
The development lasted about two-and-a-half years, of which a little more than a year was in conjunction with publisher Ludonova. When I signed with the publisher, the game had pretty solid mechanisms, but many corners to polish. We met every week to play a game with the prototype and test different changes. It was a long and partly tedious process because eventually you end up loathing the game after so many plays and it is very difficult to be able to isolate the sensations produced by some changes or others, but without a doubt the process is something I would repeat as I think it is one of the best ways to develop a game.
Together with Ludonova, we have introduced many changes that have greatly improved the game experience, and thanks to the publisher I was encouraged to develop the solitaire mode as well, something completely new for me and of which I am very proud. Throughout this development diary, I will talk about those changes and how they have affected the game, but first I want to thank again the work done by and the professionalism of everyone on the Ludonova team.
Without further ado, let’s get into it.
Merv, Tawantinsuyu, Ginkgopolis and Pax Pamir: Second Edition as Inspiration
At that time in early 2021, Tawantinsuyu and Merv had just been released in the Spanish market. I had recently played both games, and I liked them a lot, but I was especially fond of the action tile matrix and the way of carrying out actions in Merv, as well as the dynamics generated by the common workers with different skills in Tawantinsuyu.
As is common for me, I started the development of Amritsar based on those two concepts that I liked so much and wanted to explore. When I had a set of mechanisms that more or less made sense, I came to the (obvious) conclusion that there should be a way to determine a winner since I also wanted the game to be competitive. That’s when I hit on the key to a scoring system similar to Ginkgopolis, which was also a game I had recently played, loving how simple and deep it is. Based on the Merv mosque and with a majority system as in Ginkgopolis, I designed the first draft of what would be the Golden Temple with its different parts, but we will call it the “map” for now.
I would say that the weight of the influence of Pax Pamir: Second Edition is not comparable to the influence of the other three games because those alone form almost 90% of the game core, but it helped with the balance of the game by adding one more use for coins to help players mitigate the chaos of the game while adding more interaction.
An action matrix as in Merv
To start working on something simple, my first idea was to make a 3×3 action matrix. I think that, in general, it is always better to start with something small and more accessible and gradually add layers or complexity, if necessary.
Around the matrix I put a total of twelve spaces, one for each row and column per side. I decided to fill those surrounding spaces with meeples and have the players use those meeples, in some way or another, to perform the actions depending on which row or column they activated.
I wanted the actions to be simple and atomic as my idea was that you could perform more than one action per turn. I determined that there would be four types of actions: get resources, get money, activate the different actions on your personal board, and advance on development tracks that would let you improve the other actions and get bonuses (because I really like development tracks).
Special workers as in Tawantinsuyu
I was very confident from the beginning that I wanted the workers to be common and different from each other, with each one having its specialization. This is something I liked a lot in Tawantinsuyu, and I wanted to transfer it to my design as well.
With this premise, I proposed the initial idea of associating a worker to each type of action so you would have workers specialized in getting money, others in getting resources, others in carrying out different actions on your personal board, and finally a kind of wild card: apprentices that specialized in learning (i.e., advancing on the development tracks). The specializations would grant a bonus when using a worker to carry out actions of its type, such as getting more money, more resources, more progress in the knowledge tracks, etc.
One idea I liked at the beginning was to have to pay the workers when you used them, with the cost varying. I designed a “queue” of workers much like a typical card market in which the first one would cost 0 coins and the last one 3 coins. Each time a player used a worker, they would pay the associated cost (0-3 coins), then move it to the last position, potentially lowering the cost of the others. However, this system didn’t quite work out, and in the end I decided to eliminate the cost of workers altogether, which made the game much more enjoyable and fluid.
Ginkgopolis-style scoring, more or less
I really like Ginkgopolis scoring because in an elegant way it manages to give a lot of depth and layers to the game. China has a similar way of scoring, but I think this system shines especially in Ginkgopolis more than in China.
I decided to do something similar with Amritsar, but I chose to start from a “map” with fixed spaces that the players were going to occupy. I designed this “map” inspired, once again, by Merv, specifically the part of the mosque.
Merv’s mosque
I decided to divide the “map” in four parts since it fits with the four sides of the action matrix. Each part would be symmetrical and have the same requirements.
Soon after playing with this system, I thought it would be interesting to add more interaction and make the upper levels of each part available only by completing the directly connected lower ones — as if it were a pyramid in which to put a stone on top, you need two stones underneath. Also, the upper levels would be harder to get to, but they would also give more points.
Intermediate scores
Another thing I wanted to add was intermediate scoring phases. In each of these intermediate phases, everything that the players had done on that “map” was scored, giving 1 point for each marker present and also the Ginkgopolis-like majority bonus in each of these parts. This bonus works as follows: Each part of the map is scored, and the player with the majority of markers gets as many points as there are markers in that part, the second player gets as many points as the number of their markers in that part. Other players get nothing, even if they have presence.
Simplifying the scoring
The Ginkgopolis scoring system works perfectly in that game, but in this case it didn’t quite work because it generated unfun dynamics. Everyone wanted to go to the same part of the “map”, but not everyone had the same opportunities since the mancala board changes every turn and also the number of spaces for player markers in each part is a fixed amount.
In the end, I opted for a much simpler and more effective alternative, which is to award a variable number of points (1-4) per majority to each part of the map and make them score differently in each round. In this way, player interest in each part of the “map” is distributed more evenly, the number of bonus points per majority is fixed so that it does not unbalance the game so much, and players can plan to make donations in a part that does not score much at the beginning, but will score more towards the end.
Pax Pamir: Second Edition
This might be one of my favorite games ever, among Race for the Galaxy, The Castles of Burgundy, and others, such as those I previously mentioned.
I really like the closed economy in Pax Pamir and how money flows from one player to another, with the card market acting as a cool coin buffer between the players. I wanted to replicate something similar, and it occurred to me that players could use coins to kind of mitigate the chaos in the mancala board by being able to skip sections of the board without placing workers. (More on how the mancala works in the next section.) To do so, they must place a coin on the board, and those coins would remain until another player picks them up. Even though I didn’t manage to get the same feelings as in Pax Pamir, it did end up being a cool mechanism in my opinion, and it is one of the oldest mechanisms that has stayed in the game since the moment it was implemented.
Mancala as the Core Mechanism
I considered many options for activating workers, such as a fixed movement like GWT, a double phase of actions in which workers are first picked up, then placed again, and so on, but nothing really convinced me.
After many iterations and inspired by my good friend [user=mon_auale]Jordi Climent[/user], who is passionate about and an expert of mancala games, I ventured to try the “sowing” mechanisms of these games in which players must take all the elements of a space and sow them along the board, depositing them one by one until they run out. Each time an element is deposited — in this case workers — it must be done in the following space, either from where the workers have been taken or from where the previous one has been left.
This mechanism convinced me for two reasons: it brings a lot of variability, and it seems to me original since few games use it. After several plays using this mechanism, I could see how it fit perfectly with the design, so I had no doubts and decided to go all in with it.
Personal Boards
From the beginning, I wanted each player to have their own personal board so that they would have a sense of growth and development. I wanted it to be a key part of the game since I liked the idea that each player could feel that they were customizing their game experience to their liking.
I started by designing something simple. Initially the boards had only one warehouse with empty spaces for two more, four slots at the bottom to hold cards that granted small bonuses during the game, and at the top a summary of actions they could perform by activating the green action tiles, along with four empty spaces for additional actions that can be obtained throughout the game.
Once I realized that the turns could be longer than I liked, I decided that to make it lighter, I would add the option to carry out micro-actions on other players’ turns. To do this, I associated each additional action space to a worker color, so when it is not your turn, you can follow the active player by carrying out the action you have placed on the color space of the worker they are using. The active player earns a victory point, and you do the action — everyone is happy!
As could not be otherwise, the personal board has undergone drastic changes: moving the “green” default actions from the personal board to the central board, changing the bonus cards to endgame objectives, making the delivery markers available for building improvements on the board, and much more. In the end, it turned out great, and I think that I managed to achieve what I was aiming for. The picture below is the latest version we used for the prototype.
Goodbye Matrix, Hello Districts
The action matrix, as it was designed, could be unfair to players and sometimes, due to the set-up, certain sides of the board were more important than others, which caused workers to accumulate in that area, and this did not help the flow of the game.
I tried to make the actions in the matrix change places every turn or round to mitigate that, but that only made the game worse. Also, having up to six possible combinations of actions along with the workers giving you different bonuses resulted in turns with a lot of AP.
I decided to change that matrix for four districts with three different actions each. In total, I made three actions of each type, and to provide variability I made each one unique. For example, if the blue actions grant resources for the construction of the temple, I made each blue action tile give you resources in a different combination. This way I made sure that right off the bat each district felt unique, balanced, and equally interesting as the others, thus getting rid of the accumulation of workers and unwanted dynamics.
In this way, I kept the essence of the matrix while reducing the combinations from six to four. Also, now those combinations were more accessible and interesting, and players already had a much clearer and simpler reading of their turn, which sped up the game drastically and made turns more enjoyable.
Adding the Carriages
After the matrix changes, I saw there was still room for improvement in the AP that players could suffer during their turn. Even though four combinations of actions is better than six, there were still times when depending on the player and the situation a turn could be greatly lengthened by AP. I wanted to add an element that would help players focus on their turn, and that was when the carriages — which are now elephants — came in.
Normally when you want to focus people’s attention on something, you can do it through bonuses or penalties. I usually like to use bonuses as I think it tends to leave you with a better feeling, but needless to say, penalties are also a good tool and much needed in some cases. (See taxes and the maharaja penalties.)
In this case, I thought about having the carriages help you determine which district you wanted to activate. To do this, I made them move from district to district, costing one coin each movement, and they would give you one additional action to do on your turn if you were to activate the district the carriage is in.
Another thing that made the game more interesting was to force players to make donations in the temple part of the district where their carriage is located. Previously players had total freedom, and while it wasn’t necessarily a bad thing, it made that part of the game a bit flat. This change made the carriages more interesting as they would now have more than one use, and it would be crucial to manage its movement well.
Round Marker
I wasn’t happy yet, so shortly after adding the carriages I thought of adding the round marker (now the maharaja) that would move from one district to another, helping with the count of the turns of each round, but also helping players with the movement of their carriages by having a discount if they were to move the carriage over the marker.
It didn’t take long before I changed that idea as it generated a “tailgating” effect in which all players would go behind the marker to have one free movement each round. Since I didn’t like that, I made it so that passing over the marker would cause you to lose victory points. This way it is not necessary to follow the maharaja’s movement, and there is more freedom, but it is important to keep an eye on where his position is if you don’t want to lose points on your next turn!
Ludonova Era
And it is more or less at this point that the game arrives at Ludonova’s office. As I said at the beginning, we applied small changes weekly until we reached the final product. Whenever a big change was needed, we tested it several times at different player counts to make sure it was an actual improvement and not a step back. I will talk about some of the most important changes below.
Also, I will now use the current terminology for the game components so instead of carriages, the round marker, development tracks, and the “map”, I will talk about elephants, the maharaja, knowledge tracks, and parts of the Golden Temple, respectively.
Free movement for the elephant
You almost always had to pay for all your elephant (carriage) moves. The only time you didn’t have to was when you were moving to or through the district where the maharaja (round marker) was because you were already losing points and that was enough penalty. We saw that sometimes players could get “blocked” when they didn’t manage to have a stable economy, and their chances to get money on their turn were almost zero or implied a suboptimal turn. At that point, they could neither move the elephant nor plan to since there were almost no interesting options that would make them get money, and it could be a bit frustrating.
In order to fix that, we made the first movement of the elephant free (although moving through the round marker would still cost you victory points). With that change, we mitigated that issue heavily, and even though you can still be poor in the game and have rough turns, you now have more interesting options of getting out of that situation if you want. As a hint, always have one or two rupees in your warehouses!
Bridge tiles
In the prototype, if you advanced enough on one of the knowledge tracks, you could remove one tile from your player board that would unlock the ability to move the elephant again right after moving the workers on the mancala board. You would then flip that tile and place it in one of the empty spaces of the bridge alongside the temple parts, giving you a small bonus of points, resources, or coins.
That system was weird and always felt like an outlier in the game. We got rid of it, but we liked having the bridge in the game somehow, so we decided that we would instead create a set of six tiles as common bonuses. This is also a cool little bonus that helps you make decisions in your turn and can create interesting combos eventually. We started with a different set of tiles. For instance, we had a tile that would make you have another free movement on the elephant, but after making the first move of the elephant free, we needed to get rid of that tile.
Limiting the space for workers in the mancala
One of the first big changes we made was to limit the number of workers that could be in a section. In some games, seven or eight workers (out of a total of twelve) would accumulate in the same place. This made the other parts of the board empty and practically inaccessible, while discouraging players from sowing the big group of workers since calculating your options was more complicated because you had to count more movements than usual.
We decided to put a limit of four workers in each section to see how that worked. Well, it worked so well that we are still using that change today. We had to adapt the game slightly because now sections would be blocked if they had four workers. The simplest and most elegant solution was to ignore the sections with four workers during movement, so the problem became an interesting feature as now the workers’ movement can be longer if several sections are skipped. On the other hand, we also tried to incentivize players to undo those groups of four workers with two “bridge tile” bonuses that give you points or resources when doing so.
Close to the end of the development, we tested a limit of three workers per section. We played many games with that change and in every player count, but after many tests we thought that having four spaces was the best option.
Warehouses with special abilities
I started by designing the warehouses simply as a place to have room to store resources and coins. To give variability, I also added smaller warehouses that awarded points at game’s end. Since the game worked well but had other more problematic parts, I didn’t think of anything else for this part, even though I knew it was a bit boring and plain.
Shortly after several plays with Ludonova, it occurred to them that it would be a good idea to give more personality to the warehouses and make each one have a different ability or bonus — and it was such a good idea that it stayed that way forever. Even so, the first designs of warehouses differed from the current ones as the game has evolved and it has been necessary to adapt those bonuses and abilities, but the general concept is the same.
As an anecdote, the three warehouses that allow you to use white workers as if they were of another color (and vice versa) were initially passive skills that were unlocked in the knowledge tracks. That ability was removed from the tracks because it wasn’t much of an incentive and players almost always forgot they had it. Since it was something I really liked, I wanted to include it in the warehouses. We tried it and liked it, so we kept that mechanism!
Many balance and scaling improvements
Balance, in all aspects, has been the biggest concern for me during the game’s development. Each type of worker had to feel unique and be as interesting as the others. All districts had to be equally interesting. All the different strategies must have the same chances of winning. All warehouses and objectives should be more or less balanced. Lots of changes had to be made to the workers, the actions, the bonuses on the tracks, the warehouses, the temple parts, the market, the game economy, and so on. I think we succeeded with every part, and this was obviously thanks to the joint development with Ludonova.
The scaling, on the other hand, did not worry me much until we approached the end of the development. I have always thought that with a well-developed and solid core, the rest of development will go more or less smoothly. That was the case here, although we needed to make scaling adjustments in order to have a similar game experience regardless of the number of players.
To start, the game has always worked great with three players, and that is mainly how it has been tested. When we started to test it with four and two players, we saw that we had to adjust the temple parts because it was either complicated to complete them or the opposite, and players would lose practically all interest in entire districts.
In the end, as always, after several tests we managed to find the solution, which was to increase or decrease the number of spaces in those parts of the temple, but finding the right number per player count was not trivial. In games where you can carry out actions during other players’ turns, the scalability is almost exponential instead of linear, and from three to four players you can build much more than it seems at first glance.
The same holds true with two players as the chances of doing something outside your turn are much lower, although we solved this with a little addition that suits the game very well (as discussed next). Anyhow, adjusting the scaling of the game has certainly given me a headache or two.
Two-player mode
Even though we thought that the game was pretty good at two players, the voices in our heads were whispering that something was missing. Indeed it lacked the interaction between players between turns that occurs with more than two participants.
In response, we came up with the simple and elegant solution of putting a worker of each color adjacent to the spaces of the maharaja, and every time it moved to a new space, it activated that worker of that color as if it were a third player. In this way, both players can follow that “third player” for free as long as they have actions associated with that color on their board. This greatly improved the two-player experience and also made the game even more strategic, which is something I love.
Solo mode
Without realizing it, thanks to those changes in the two-player mode, we opened the doors to the development of the solo mode.
This is something I’ve always wanted to do, but because of all the interaction in the mancala board and between turns, I never saw it being feasible unless I wanted to complicate things a lot — and very complex solitaires have never appealed to me. However, as soon as we introduced the change to the two-player mode, this enabled me to do the solo mode for the game since now we had a powerful tool to use on the bot’s turn: the meeples in the maharaja spaces.
When I started developing the solitaire, the game was already budgeted, so I couldn’t add more components to the game specifically for solitaire play. Essentially, I had to use the components we already had in the game, and that put me in a situation that I love because I have to try to get as much as I can out of a limited set of components.
[user=ennio_lombardi]Juan Luque[/user], one of the members of Ludonova, thought it would be interesting to use the workers from the two-player mode to determine which actions the automa performs and even put that together with the worker that the player uses on their turn. I really liked the idea and got down to work immediately.
The first idea was to make a flowchart for each worker where, when activated, the bot would perform a series of actions in a specific order. To make it more coherent, the actions of each worker were related to that type of worker. For instance:
• The yellow worker gets resources and donation markers by interacting with the marketplace.
• The blue one gets resources based on the round.
• The green one makes donations following a priority or gets donation markers.
• The white one advances in a track that can give out points, resources, and delivery markers. If it reaches the end of the track, the bot scores points for the remaining resources or coins at the end of the game.
In addition to the actions of the workers, I found it necessary for the bot to try to make a donation to the temple in each of its turns since it is almost what every player is thriving for. I decided to make two action blocks, with the first one the donation and the second one the actions of the workers. These blocks are always activated in this order.
In the donation block, the bot tries to make a donation in a part of the temple prioritizing the ones that give more points per majority first. If it is not possible, it will try in the next one. And if it can’t make a donation in any of the parts, it gains a donation marker instead. At the beginning of each round, the elephant is placed in the district that gives the most points as a reminder of this and stays there for the whole round. The requirements for the donations are the same for the bot as for the players: having the required resources and a donation marker available.
From the beginning it was clear to me that the bot should not use coins because managing its economy would be too complicated. However, I did see the need for the bot to manage both resources and delivery markers, so I gave the bot a pre-constructed warehouse of eight spaces in total and for the donation markers I designed a grid in which all of its donation markers would get placed at set-up. For the markers, I also added several bonuses whenever it would empty a row of the grid to make it a bit more interesting.
As per the resource management, Germán P. Millán, who greatly helped me develop the solo mode, came up with the idea of creating a special reserve for the bot that we called “imperial quarry”. This reserve consists of two units of marble, three of copper, and three of gold. Whenever the bot needs resources, it gets them from the quarry and when it consumes them, it returns them back to its own quarry.
In addition, we established a priority scale so that if the bot needs marble and has none in the quarry, it goes for the next resource on the scale, which is copper; if it has no copper, it goes for gold; and if it has no gold, it earns 1 point. In this way, there is a more or less intelligent system in which, based on demand, the best possible resources are awarded.
We decided to use the endgame objectives that give 1 point for each delivery marker in a particular part of the temple to determine the priority of donations made by activating the green worker. This helped us to have some more variety, but in addition we also wanted to use that objective as if it were an actual objective that the bot has, so it also earns points for completing it. This adds yet another way to score the bot that I think makes it interesting.
For the bot to interact in some way in the market, we decided that when using the yellow worker to get a resource, it would discard that resource from the market, even though the resource is from its imperial quarry, thereby simulating a purchase. In this way, there is a little bit of interaction in that part as well.
About the flow of the white worker, there is not much to add. From the beginning it was a simple way to get points for the bot, but we wanted to give it more variety and balance it against the other worker action-flows, so we added the resource bonuses and delivery markers. In addition, we also thought it was quite coherent to add a way to earn additional points if it would reach the end of the track, and we established that the bot could earn points depending on the remaining resources or coins in its board.
As I said before, the bot doesn’t use coins, but to solve this little need we “drew” a coin in each space of the warehouse so that the bot would have as many coins as empty spaces in the warehouse at the end of the game. This also solved the problem with the endgame objective that asks you to have the most coins since the bot can now also end the game with coins, even if it never touches a real coin.
Production Decisions
In terms of mechanisms, this is roughly all that is noteworthy about Amritsar’s development. I will now briefly discuss some notable production decisions that changed from prototype to final product.
Modular boards to a single center board
I started by making a modular board in which I had the stock mancala on one side, the temple parts on another, the marketplace on a separate side, and the scoreboard also isolated from everything else. I did this because it was the most practical way to make physical prototypes, but obviously it was not the best final solution and I had to change to a single board. This helped us a lot in the ergonomics of the game.
Introduction of the elephants
When we were approaching the end of development, we decided to use elephants instead of the carriages. They will basically represent the players in the game and help with the delivery of the resources to the temple.
I searched for information about how the reconstruction of the temple took place and what was commonly used for transportation at that time in Amritsar or the Punjab in general, but it was hard to find these specific details about that period and that historic moment, so we had to use our imagination a bit there. We knew that elephants were widely used in India for work, riding, transportation, and other purposes, so it felt coherent with our main purpose since we would be the ones riding the elephant, and it would help us deliver the resources to the construction area. We could have stuck with carriages, but we all thought that elephants were way more coherent and also a more interesting and beautiful element to use in the game.
Donation markers on the elephants
At first, unlocked donation markers were placed on the side of one’s personal board, then I added a specific place within the board so as not to have them scattered around, but that was worse as they got confused with the markers that had not yet been unlocked.
Ludonova suggested using the elephants as the place to put the markers as this also makes players more aware of how many markers they have and to associate that it is a necessary requirement to carry out donations.
Knowledge tracks on personal boards
The knowledge tracks started as a separate modular board, then transitioned to the central board when we got rid of all the modules. The good thing about having the tracks on a common place is that players were more aware of the progress of others on those tracks; the bad thing is that permanent benefits tend to be forgotten more often.
In the end, we decided to include the tracks in the personal boards, something that considerably increased the size of these, and thus made those permanent benefits much more present in the minds of the players. It was interesting to know the progress of others, but it was not something that was mechanically necessary, so the change was only for the better in my opinion.
Conclusion
And here ends this very long development diary! I think I have gone on too long, and at the same time I think I have left out a thousand important things. I sincerely hope that you have enjoyed this reading. If you thought it was a boring read, I’m sorry, but I couldn’t help myself.
As I always say, if you have any questions about the game, I will be more than happy to solve it either on BGG or on Twitter. I don’t usually answer private messages, so write me openly in a tweet tagging me; that way I’m more likely to find out about your message.
Speaking of tags, if you’ve made it this far (and want to), tag both @ludonova (publisher) and @davidherasp (me) in a twitter message with the hashtag #TheGoldenDiary and we’ll know you’re real champions. (No cheating, only those who have read the whole thing can use the hashtag.)
That’s all for now. I hope to see you soon in another of my designer diaries, so I won’t keep you any longer, and I’ll try to continue working with my other games.
Best wishes,
David Heras Pino
