by Dave Chircop
This post includes two diaries: one from David Chircop, the designer of Hamlet: The Village Building Game, and one from Johnathan Harrington, the game’s developer. The goal here is to give two different perspectives and approaches towards a design.
Throughout the post, we have scattered in photographs of prototypes of Hamlet in a somewhat chronological order, so that you can see how everything changed as the game grew and bumped around in the cauldron. Enjoy!
Last-minute update: Copies have started to ship to Kickstarter backers, so Hamlet: Founders’ Deluxe Edition will be available for purchase at SPIEL ’22 in limited quantities for 65€.
Designer Diary: The Thing About Sense of Space
Ever since I started dabbling with making games, a village builder was always a fascinating prospect for me to model. My formative experiences with games in general were deeply rooted in the RTS genre — games like The Settlers, Age of Empires, and WarCraft. I absolutely adored those games, but the thing I loved the most about them was not the battles or tech trees; it was that opening twenty minutes when you are presented with a town hall and a few peasants, and you start forming, shaping a thing from scratch.
I enjoyed the management of the workers, the movement of the workers, the placing of the woodcutter close to a forest so that the workers don’t have to walk too far. I enjoyed the fact that without much thought and almost out of necessity, my village starts organizing itself: houses next to each other, the wood production area, the mining area, the farms placed in a location where I know I can expand it later. All of this, the necessities of the mechanics, combined with the randomness of the map, the sense of distance between areas, their segregation, and a touch of my own desire for pretty organized things eventually allowed a “place” to emerge, a place that I later gave a name — often funny, ridiculous, or childishly lewd, knowing tween David.
And then I zoomed out a bit and just watched my village be alive. The villagers walking, from one cute building to another, carrying things.
This was my favorite part. The other arcs that often accompanied games like these — discovering other villages, the race for building a stronger army, the defense and the opportunistic counter offense — were all secondary for me. I often would bring the village to its operating state, then abandon that save and start over, just to do the build-up again and see what will emerge this time.
This, at its core, is the biggest inspiration for Hamlet. In March 2021, after four years of on-and-off development, through grueling AAA video game work, I had the Hamlet I wanted to publish. By October 2021, I had what I thought was a “finished” version of this game. The game was balanced, smooth, streamlined, short, competitive, easy to explain — it looked pretty. It had the elements that made a good village builder… Yes, of course there is a “but”.
In November 2021, we delayed the Kickstarter for Hamlet. We wanted to re-do some art, we wanted to work a bit longer on the video, we wanted to refine the page. I found myself with a game that I had written off as finished, but also a game that was in some way not fully satisfying me. With a few extra months of time bought thanks to the Kickstarter, I sat down to figure out why.
In David Lynch’s “Catching The Big Fish”, I remember his insistence on servicing the original idea. Making not always the “best” decisions, but ones that service the original idea the most. In media that require a creative process that involves reduction or distillation — like games or film — this adherence to the inspiration becomes both more important as well as harder to achieve.
With the extra time the Kickstarter delay granted me, I locked myself in the “Hamlet” room at the Mighty Boards office and sat for a few weeks. It was a strange time as I barely spoke to anyone, and I think people were afraid to interrupt me. After thought and a few discussions with the people who had access to the game at the time, and a few deep discussions with my dear friend and fellow designer Gordon, I pinpointed the issue: At some point in its streamlining and fat trimming, Hamlet had become a better game, but it had stopped creating “places” — you know, places I can give names to.
A Place with a Name
Why this was happening was not so difficult to figure out. In the process of streamlining the game, we had cut the majority of distance restrictions that the game had, which removed a lot of clunk. This meant that all workers could go pretty much anywhere rather easily, downplaying the importance of buildings that need to be close to each other to be effective. If where you place something does not matter, then even with the engaging spatial puzzle, the different tiles and buildings and their multitudes of effects, they all become mostly symbolic. A sense of place emerges from questioning the “where”. Where will I place this? Where is the timber? If the “where” does not matter, then there is no place.
Movement is likely one of the oldest or most basic of mechanisms in board games. It’s also one of the most rhetorically efficient — I move a piece from one place to another. It is a clear image generator, one that anyone can relate to. It is also, rather unfortunately, sometimes the most annoying, especially in Eurogames.
Since in board games we often abstract our spaces into segments, moving pieces frequently devolves into an exercise in counting. This is fine when limited to a few spaces — “You can move one or two spaces” — and mapped to a timeframe and space that is thematically resonant, perhaps market stall to market stall in Istanbul, or room to room in a mansion in Mansions of Madness. It also makes sense in much larger spaces, say, city-to-city or area-to-area in an area-control game.
But what about that middle ground?
What follows is my thought process.
Worker Placement Is Traversal without Movement
I always imagined worker placement to be the natural response to this movement problem. Most of the early classics of worker placement mapped out spaces that are around the size of the places I wanted Hamlet to generate. I’m thinking Stone Age, Caylus, Agricola. They showed us traversal, while skipping the movement, shifting the restriction instead to the “occupation” of a space rather than the distance between places. Hamlet needs distance — in fact, it needs distance more than it needs movement itself. What else?
Then there are rondel and mancala games, which are worker-placement games re-introducing a touch of movement, with restrictions that dodge the abacuses of counting spaces. These games are a nice middle ground and are usually clever ways of mapping distance with restriction. They are, however, heavily designed, tight systems in which the sequence and distance between possible actions are carefully calculated. Hamlet is largely a sandbox game in which every village is completely different, and the locations of the buildings are all based on the emergent economy and the players’ decisions of placement.
These types of games also usually have an issue with opacity of plan, where one needs to make significant effort to plan a series of actions correctly, resulting in the movement/action-selection mechanism being quite forward and focused-on. In Hamlet, movement is important but cannot interfere with opacity of plan as there are already quite a few moving parts: emergent economies, organic and grid-less village building, spatial puzzles, roads.
At this point I turned my attention to less directly “active” modes of restricting space. Perhaps something that’s slowly built, something that’s a bit clearer to plan. Something that makes sense for medium-sized spaces. My attention turned to train games and network builders.
Games such as Brass and Steam achieve a sense of place not through the movement of their “active” element — in the case of Hamlet, the worker — but through the slow development of their networks, and consequently the movement of goods through said networks.
Enter the Donkey
The solution in the very specific case of Hamlet was to separate the active element from the movement, as many great designers have done in the past when they came up with worker placement. Then introduce the sense of place and movement in a more passive, slow-building manner.
Hamlet now has two different workers: the villager and the donkey. The villager is the fast and active action taker, giving all the good things that come from reducing clunk and restrictions: speed, agility, and clarity of choice. The donkey is the slow network builder and mover of resources, giving all the great things that come with that: slower long-term planning, a sense of distance.
The synergy of the two then constructs the rhetoric in the mind as well as the strategy in Hamlet. The direct actions of the villagers rely on the donkey network for delivery of the resources needed to build, refine, and fulfill deliveries, and the growth of the donkey network relies on the efficient action planning of the villagers to fund their expansion. This forms a satisfying incremental cycle of growth, and suddenly our arrangement of tiles comes alive into a bustling living village — one I can give a name! Perhaps a more creative one this time.
“DAVIDTOWN!”” — ahhh, the creativity.
I’ll pass on the baton to John now. My approach to design and this diary has been very much experiential, so I asked John to chime in with a more technical breakdown of process of how the experience I created was slowly refined to what it has become today.
David Chircop
•••
Developer Diary: OSHA Approved — A Hamlet in Working Order
Do not let David’s light tone fool you. He put a lot of sweat and blood into Hamlet. He chiseled the game’s marble into something very complex, yet elegant. Eventually, when it was time for me to involve myself in the project, all we had to do was polish the marble and make it shine. In this part, that is what I’d like to talk about, sharing my playtesting process and discussing what I felt went well — and perhaps less well — during the Hamlet development process.
There is a lot that goes into developing a game, and external playtesting is definitely a significant part of it. It’s tempting to just over-playtest, cross your fingers, and hope for the best. However, I often find this to be under-productive. I think what’s more important is that each playtest is asking an answerable question; make the question small (so that other people can also help you answer it) and trackable / documentable (if you can’t record an answer because it’s too vague / speculative / grandiose, then there is probably a better question to ask). In this post, I hope to show you how I (and Mighty Boards in general) try to make the most of our playtests.
Introduction
We divided our Hamlet external playtests into three waves. Dividing tests into waves accomplishes quite a few things. First, it makes the workload manageable; saying “We need to just test, test, test” is daunting because it’s unachievable – there’s no final test in sight! Second, it allows us to make each wave have its own unique question. Now, not only do we have a goal (answer the question), but we also have an end in sight. (The tests are over when the question has been sufficiently answered.) Third, it allows us to push major changes in bulk. This is important as each change will affect both questions and answers; it also allows us to process any testers’ suggestions and concerns appropriately (by placing feedback in their correct development version), it helps give natural deadlines (next changes need to be done by the time this round of tests are over), and consequently it makes the project more manageable as it sets milestones both for testing and its dependencies (such as design changes, production, graphic design + art, and so on).
We’re not as organized as this post might make us seem, so these waves aren’t set in stone, but they’re reasonably accurate representations. Additionally, I am including only external tests. I played the game (a lot) by myself, as did David (the designer) and Nick Shaw (the solo version designer). Additionally, by now everyone at Mighty Boards (and our friends and family at other adjacent companies) has played some version of Hamlet. Some takeaways from this post will stand for these internal playtests, but the marketing manager asked me to keep this post under a 15-minute read, so I am going to talk only about external playtests.
So, we divvied it all up into three core waves (with each wave having its own little tides):
• Focus Group Wave
— Feeling tide
— Balance tide
• Mass Wave
– Concept tide
– Break tide
• Blind Wave
– Rulebook tide
– Ease of play tide
Focus Group Playtests
Once we got through the internal playtests, it was time to start reaching out to players outside of the company circle. We kept the sphere of influence small because Hamlet was still in its early stages: the art was largely not there, the written rules were tentative, and so on. We didn’t want a large group of people to get a bad impression of our game just because it was unfinished, so we stuck to groups we know and trust, with two large questions we wanted to answer:
The first question was “Does the game feel balanced?”, which we sectioned into more manageable questions about individual parts, such as “Does the church give too many / too few points?”, or “Which flag buildings score the most points on average?” We had an Excel sheet that we used in real time during the playtests. (We never played in these sessions; we just observed, filled out cells, and nodded our heads pensively.)
The Excel sheet recorded each worker action in each round, how many points that action made, and how many times each action was taken. From a balance perspective, I am really glad we set this sheet up as it allowed me to calculate point efficiency across players, point efficiency across actions, opportunity costs gained through early worker investments, and many other metrics. A lot of numbers changed here, which would not have been obvious had we been playing the game only internally. Each player tends to be set in their ways, so having a few extra hands moving the pieces around showed which numbers needed to be bumped up or down.
It also allowed us to start shipping minor updates during the same wave. If a flag building is too good in the first playtest, we can up the cost a bit or reduce the final point tally a bit, then see what happens. An individual flag building won’t muddy the overall results, but these small changes still gave us the opportunity to figure out the little things before we went to larger groups. This said, each individual change was still marked in our internal change log and feedback forms, so we still kept track. If something broke, we’d know.
The second question was “How does the game feel to play?”, again sectioned into more manageable questions such as “How did you feel about the donkeys?” or “How did you feel about connections?”, or “Was the game length good?” The Excel sheet helped here, too. For example, there was a clear correlation between the actions that felt good / felt intuitive and the number of actions that were taken. This sounds obvious at face value. If making buildings feels good, players will do it more. However, there is always value from having numbers because it allows us to see whether an action is starting to feel better in subsequent tests because the number of times it is taken increases.
We also gathered feedback from the playtesters through Google forms as well as focus group discussions after the playtest. Honestly, we were quite floored by the reception. Usually there is a gigantic hiccup for the playtesting process at this point as there’s often a mismatch between internal playtest feelings and external ones. Internal tests have people you know very well, so the teach is much easier as you can cater to people, not groups. Moreover, people in board game companies are often quite proficient at playing board games, so the weight-tolerance range isn’t as wide as it would be for an external test. Finally, internally, people get you, which gives a larger communication tolerance. External playtesters won’t always understand your intentions for the game.
Hamlet had one big thing going for it: We had already shown an early internal version at SPIEL. I will let someone else discuss whether this was a good thing or a bad thing. One good thing it did was that during the demos we ran for people, we had already quite a bit of information on how the game felt (although not as much about the numbers). However, the bones of contention for player feelings were clear, and before we started these focus groups, we already had a good idea of what worked and what did not.
Mass Playtests
In this wave, the first question we looked at was “Are players getting the Hamlet experience?” I know this question seems quite vague, but I’m going to explain.
At the time, Hamlet was the first game David and I had worked on together. He’s a very talented designer, and I think I’m decent at the whole development thing. However, we still came to frequent impasses on the project. He would give me a design, which was interesting, but clearly had something a little off. In one iteration, I overhauled the economy injection; in another version, I suggested a different bag-building mechanism; another time, we played on and off with the idea of individual player boards; and so on.
After the nth iteration of me removing something and him adding something else, it became clear that our issue was a concept issue. As a developer, I want Hamlet to be a functional game: fair, clean, simple to learn, no rule overhangs, etc. However, as a designer, David had a vision for Hamlet; he wanted to make a game about sharing, about a sprawling town where logistics become harder as the town grows, about organic growth where everything happens because it is time for it to happen. I think we got a version that we were both happy with only when he managed to communicate this vision. From then on, development really started to go smoother, and I could focus on easier things like numbers and game flow.
So, the first question was a very clear one. I finally got David’s intentions, but when external players finally started getting their hands on Hamlet, would they get his intentions, too? Had we cleaned and directed the experience well enough that, while each player might have their own direction (donkeys, roads, refining, building, or something else), all of them will feel the joy of a shared communal board, while managing the burden imposed by a sprawling town. It was tricky getting feedback on this at first, but we were ultimately able to gather some very useful data.
The second question we focused on was “Can the game break in any way?” Games can break in really drastic but also more subtle ways. Sometimes, the game state can become unplayable; an earlier version of Hamlet had a game state in which getting money was impossible if players were playing antisocially. This is an undesirable state, which we thankfully spotted quite quickly.
However, sometimes a game state can simply become less enjoyable to play: is the game dragging on too long, does it ramp up too slowly, are we injecting resources into the game at the right pace, does adding more workers add mental load in an undesirable way, and so on. All these cause cracks in the game, but if having no way of making money is the equivalent of a flat tire, then these latter conditions are more like a slow puncture: air’s going out, but you’ll notice only after the tire has been used for much longer. The best way (maybe even the only way) to find out whether a game is slowly letting out air is through stress testing — playing as many games as possible with as wide a variety of people as possible until the tire goes flat! That’s what we were trying to accomplish with our external tests, and we were very successful in this regard.
Blind Playtests
There are two main questions we look to ask during our blind playtests. The first question is “Is the rulebook understandable?” We think Hamlet is at its core a really simple game that is complicated by players’ interplay as well as an unconventional mechanism. A good rulebook is paramount for Hamlet especially; it can make a 3-weight game feel like a 2. If we manage to communicate the core experience to the players in a clear and efficient manner, then we truly believe that any player can hold their own.
The second question we want to ask during the blind playtesting is “Is there information that players need to be reminded of during gameplay?” This is already something we have kept an eye on, but only within the context of us being there (so questions can be answered easily and concisely). What happens when we’re not there? Will players be able to answer the questions as easily? While we feel the rule overhang is light to non-existent, it’ll be good to gauge whether others feel the same way. Board games are at their core about communication; blind playtests are there to help us make sure that we can communicate our designs even when we’re not physically present in your living rooms (yet).
For both these questions, we met new focus groups and did the hardest thing for us as designers: Shut up and let them play. For the first tide, we have to zip it from the moment they get the box. Let them pick up the rulebook, read it, then time their learning process. We looked at whether they got anything in the rulebook wrong and tried to figure out (after the playtest through questionnaires) what phrasing caused the misunderstanding. For the second tide, we let them read the rulebook themselves, but we clarified any misunderstandings that arose. Then, we stay silent during the playtest to see which rules fall through the cracks during the gameplay.
As opposed to the previous waves, these two tides ebbed and flowed with each other. Board games, especially closer to their release, end up in a lot of people’s hands, whether reviewers or publishers, other designers and developers, and even distributors. Each of these parties want to deal with our game in different ways. Some want to have a pure unadulterated experience (and so, we ask whether we can at least watch), while others want to get a grip by themselves, but also not spend too much time on something unfinished (in this case, the rulebook). Denying ourselves any rules feedback (whether clarity or retention) because the tide has gone definitely felt like folly.
To this day, we are still getting feedback from blind tests, whether we are physically there or not. After all, as soon as players get the game into their living rooms or leave nice comments on BGG, that is another informal blind test under our belt. As recently as last week, a good friend of our company and an even better designer played the game and gave blind rulebook feedback, even though the games are on boats on the world’s seven seas (or at least two of them). This feedback won’t make it into the first copies, but we believe in Hamlet, so we will keep updating both the rolling online rulebook, as well as the rulebook in future copies (perhaps ahead of exciting expansions in the future?). Even so, our most recent changes to the printed copy still feel very definitive. Thanks to our blind testers as well as the great people on our Discord, there are so many QOL changes to not only the rulebook, but also the graphic design, that hopefully your experience with the box will feel smooth like butter made from high-quality milk.
Conclusions
Playtesting could be a book chapter, if not an entire book, so I didn’t go into too much detail here. However, this post hopefully provided some key takeaways:
• Every playtest needs a question (but not every playtest will necessarily give a good answer)
• Help people give you the answer (Guide them, but don’t lead them. Good questions are open questions, with necessarily closed answers!)
• Playtest in waves, and keep your big changes for the end of these waves (minor changes are often fine – if a Sharpie stroke solves it, then it’s probably not a big deal)
• Time your playtests to match with any dependencies
• A game that takes long is an expensive game (your time is an expense too, fellow designers)
• Make your development workloads manageable
• Have easy questions
• Have multiple questions
• Have recordable questions (waves and tides, waves and tides)
That’s it from my end. If you would like to help us playtest our games, you can join our Discord to get in touch with our current testing coordinator. We’re always looking for feedback as well, especially from the sort of people who enjoy reading long BGG posts about playtesting.
Johnathan Harrington
