Meriam's Trial Design Story
One of my traditions as a designer is to wait a few months after each major game I finish and then write a long & meandering retrospective to share the story of its design journey and place in my life. Now I will be respecting that tradition with Meriam’s Trial. With Ambivalent Aggression I had the luxury of telling a clear chronological story, here I’ll be jumping from topic to topic while vaguely following a chronological progression. This will be quite long, since I believe in sharing as much of my perspective as possible.
Meriam’s trial is a puzzle focused solitaire videogame where you arrange tiles into sets that satisfy 2 specific constraints. I highly encourage beating the game before reading this, both to ensure you have proper context and because I’ll be spoiling some of the intended player epiphanies that I’m pretty proud of. It’s free and playable in browser. To set some time expectations, a first win usually takes 45-90 minutes.
.
.
.
If you just came back from trying the game, I sincerely hope you did not give up after 7 minutes of attempting to wrap your head around it. That’s what happened the last time I sent the game to someone, it was pretty crushing to my morale. Meriam’s Trial feels like a finished project that I’ve moved on from, yet also feels frustratingly unfinished. I never conquered the great challenge that I was struggling with throughout the entire design journey. Releasing the game felt more like giving up than a celebratory milestone. Perhaps someday I’ll return to the game and take another shot at making the *correct* new player experience. Overall, I’m quite proud of the game, but I’m left with the lingering feeling that I failed it in an important way.
Now that I’ve gotten that off my chest, I can properly start.
.
.
.
Zachtronics is one of my favorite video game studios. They released so many incredible games and I’m grateful that they made my favorite genre popular (programming/engineering puzzle games. I’m always amused by the commonly used genre label “Zach-likes”- because my name is Zach, and I do indeed like these games.) Starting in Shenzhen I/O, Zachtronics designed a solitaire* minigame for each of their commercial releases - this is what got me hooked on the genre of so-called “games of patience”
*When I say solitaire, I am referring to a genre of games that are traditionally played by yourself with a deck of playing cards and has recently been expanded in scope by modern game designers. They frequently feature mechanics like packing [ex: moving cards around in a spatial tableau of columns] building up a foundation [ex: make a pile for each suit that ascends one number at a time], choosing pairs to eliminate [ex: mahjong solitaire], and storage spots with limited space [ex: free cells]. Often solitaire style games are characterized by mechanics that define what is exposed and having to ensure you don’t block yourself from making any more moves. I have to write this footnote, because the term “solitaire games” is commonly used in the boardgame community to refer to any game that is played with just 1 player. Here I will be exclusively referring to solitaire in the former sense, not the latter sense
Many people are familiar with solitaire from implementations of Klondike that came pre-installed on old windows PCs. I tried that years ago, and utterly dismissed it as an uninteresting game. The Zachtronics solitaires showed me that solitaire wasn’t a specific game- it was a genre, a family of games with exciting design space to explore.
My favorite part of playing solitaire games is the journey of cracking open an interesting ruleset. I love going through an arc of mastery where the frequent losses at the beginning slowly transform into more and more consistent wins. Solitaires are puzzly in two ways at once. In an individual game, it’s interesting to analyze my next move. in aggregate, it’s fascinating to deepen my understanding of the rules, develop clever tricks, and invent heuristics.
The release of the Zachtronics Solitaire Collection is what pushed me into wanting to design a solitaire myself. Playing a compilation of games always puts the concept of a designer’s voice and style in my mind, and that feels like an invitation to wonder about my own voice. Designing a solitaire specifically intrigued me, because it felt strange and alien. Where would I even start in making one… especially since I only have an interest in making a game if it feels distinct?
My hyperfixation on the Zachtronics Solitaire Collection compelled me to write an extensive critique on the games within it. The designer of those games, Zach Barth, read my critique and DMed me out of the blue saying they enjoyed reading it! I’ll always treasure that I got to have a brief conversation with my favorite game designer.
Over the course of that conversation, he encouraged me to make a solitaire myself, gave some advice and insight on their process, and recommended an excellent book for further research. I will now do my sacred duty and pass those 3 things onto you
- You should consider making a solitaire, it’s quite a fun challenge! If you make one, I’d love to try it 😊
- The Penguin Book of Patience by David Parlett is a great read and useful reference for any designers who have interest in the solitaire genre. Collected in this book are the rules for countless solitaire games, a reference for traditional solitaire terms, an interesting system of classifying these games, and surprisingly witty commentary.
- According to Zach, the first step to making a (videogame) solitaire is to design it with real physical cards first. Additionally, he explained that a lot of his process was about finding the right vibes, and that the journey contains a significant serving of trial and error. I was especially interested in how aesthetics seemed to be a dominant force that drove a lot of his solitaire design.
Both that conversation and book left me still at square one in designing a solitaire myself- despite the overwhelming motivation they created. Reading about so many solitaire games was interesting but didn’t generate any ideas for me. I let my desire to create a solitaire chill in my thought cabinet in the background and continued with my life.
.
.
.
For Ludum Dare 51, I made Magic 281: Intro to alchemy- a game about struggling to keep up with a fast paced lecture explaining a silly magic system. This game left me with a magic system and world that demanded further exploration. The alchemical laws I had come up with felt like they had a lot of good potential.
I eventually had a cool idea for a sequel to magic 281 that would expand the scope to be an entire course on this alchemy system. The vision for this was quite ambitious. I was going to make several power point lectures, write textbook excerpts, design worksheets where the problems were puzzles, program an alchemy simulation sandbox, and construct an elaborate open-ended challenge that players would creatively tackle as a final project. I’ve done none of those things, I never even started this project. Maybe someday I’ll actually make this, it sounds awesome.
Yet I did do a significant amount of brainstorming for this. One night, I was utterly overwhelmed by a rush of ideas for this magic 281 sequel, and one of them was a solitaire minigame. That’s how Meriam’s Trial was born! This was a pretty physically intense night for me, I got so many ideas all at once that I couldn’t sleep. At the time, the solitaire was of the more minor ideas, funny that it’s the only one that has currently seen the light of day. [The more major ideas were making a variant of Hashi puzzles with my alchemy laws , ecosystems where alchemy played a central role in natural processes and organism biology, exploring how this world would make computers, and an expansion of the alchemical concept of friendship to include rules for building molecules] {That last one is probably the original inspiration for the meta-laws in Meriam’s Trial now that I think about it}
The solitaire soon kicked the magic 281 sequel out of my brain, and Meriam’s Trial became my main project for the next few months. These roots are why I always say this game is alchemy themed-despite its abstract nature. It’s also where the title comes from. It’s a shame that the game is so clearly thematic to me, but I don’t really share this with the players.
At least I can share the flavor with you. I’m glad I’m writing this design story, so I have an excuse to share my worldbuilding!
In the Universe of Magic 281, Alchemy is incredibly dangerous. If you break any alchemical laws, your solution explodes. The alchemical laws aren’t intuitive- they had to be discovered by scientists. This means that Alchemy initially had a reputation for being random, unfair and chaotic magic.
Many of the early pioneers of scientific alchemy had to fight against this reputation in order for alchemy to be taken seriously. Modern alchemists now consider their art deterministic and stand by the assertion that all explosions are caused by skill-issue or lack of understanding.
Many of these pioneers of scientific alchemy designed strategic dice games as propaganda. They often made games which seemed like they were purely determined by luck, but after gaining a deeper understanding of the game, players would realize that it was actually driven by skill.
Meriam’s Trial is named after the in-world character Meriam Qluix- who discovered the first law of alchemy. She devoted her life to helping alchemy become a scholarly field. As part of these efforts, she designed Meriam’s Trial as a game in-universe, and it became a traditional activity to give to beginner alchemy students. It became especially popular as a way to practice the basic principles of alchemy- without the risk of anything exploding. I also imagined that some teachers would use the game itself as a test- to see if you should be allowed to attempt more physical and practical trials
Meriam’s Trial was designed based on my real-life design intents as a priority, but I quite enjoyed imagining its context as a fictional game- and surely that influenced me somewhere. I always love when worldbuilding includes the role of games in a culture.
.
.
.
My very first experiment with the mechanics was with standard playing cards. After no more than 3 minutes of messing with my deck of cards on my table, I realized that wouldn’t work at all. A few days later, I had the idea which led to my first actual prototype- making the game dice based.
[I had wanted to make specifically a dice-based solitaire for a while too, but I couldn’t do anything with that fragment until I paired with a core mechanic- in this case my established laws of alchemy]
There are several reasons I was excited to be working with dice. Firstly, I like them as a container for two properties: die color and face-up pip value. I’m a big fan of how these two properties work together- it’s a great dual constraint. Color gives you flexibility as the designer because you can decide the proportion of each color you include in the game. The set of possible die faces worked great for my core mechanics- 6 variants intuitively felt like a great number for the constraints of my alchemy law mechanics. Both die color and face are also very easy to randomize.
With the cards, I was stuck in the mindset of making the player add up the values of different suits. As soon as I moved to dice, I immediately realized that the game wanted to be about counting instances of stuff [ex: how many reds, how many 3s]. It’s worth noting that this direction had a significant clarity cost: the playtesters had to internalize that the numerical meaning of each die face was irrelevant- since the game was treating each die face as a unique symbol instead of a count itself. This is a significant abstraction which was hard to find intuitive given how much of the rules involved counting. The game required the player to be extremely comfortable with stuff like “here I have two 1s and three 2s so it would be safe for me to place one 4 here, and that means this group is now size six “ A lot later in the development journey of Meriam’s Trial, I moved from using the standard die faces to just 6 different letters- that was an incredible clarity change despite how sad it made me to abandon the player perception of dice.
The next exciting innovation that dice brought to my thinking was the fact that they can come together to form a large visual structure. This is a memorable part of many traditional solitaire games, which often have pictographic layouts. While playing with my dice, I realized they were stackable and that opened up an entire new dimension. It seemed like it would be quite interesting to center the game around a 3D structure [like mahjong solitaire]
One of the best purchases for my boardgame design component library has been the excellent game Sagrada [designed by Daryl Andrews & Adrian Adamescu]. That game comes with 90 small D6 in 5 different colors, which I’ve frequently borrowed to use in my physical prototypes. The first version of Meriam’s Trial used 85 dice- thanks Sagrada!
Here are two pictures of this first version I brought to a local playtest meeting
As you can see above pictures, this first version involved a 3D pyramid of dice. It had quite the memorable table presence and was pretty successful at attracting the attention of other designers while I was setting it up before the meeting.
I distinctly remember saying “I hope this idea doesn’t actually have that much potential because I never want to build this pyramid again”
Unfortunately, the vast potential of the game was immediately obvious after the first playtest. I was shocked by how much I liked the implications of the core mechanics- it felt like a clever mathematical discovery that I had coincidentally stumbled into. I was testing the game mostly as an experiment that I was curious to see the result off, so I was very pleasantly surprised when the rules naturally created a series of interesting discoveries for the player. Watching this happen was wild, since I had no idea that the rules prompted such discoveries. Remember that the “laws of alchemy” constraints were originally made as random details to memorize in my magic 281 slideshow game, I can’t believe that slapping them onto a solitaire led to such an interesting puzzle!
Making games teaches you to not expect the first playtest to be a hit. So, it was extra jarring how interesting Meriam’s Trial was out of the gate. My previous game Ambivalent Aggression went through a series of utter redesigns while I made it, while Meriam’s Trial maintained so much of its identity throughout its journey.
.
.
.
I still have my google document describing the rules of my first prototype. Having stuff like that is great for writing these design stories. Here’s how it worked:
The game required a set of 16 dice in five different colors, along with another “special” color that had 5 more dice. In my prototype I was using the base sagrada dice and the clear dice that came with the passion expansion. I had to include the special dice in order to have a balanced number for the pyramid.
The pyramid had the following layout:
Layer 0: 1-3-5-7-9-7-5-3-1 dice
Layer 1: 1-3-5-7-5-3-1 dice
Layer 2: 1-3-5-3-1 dice
Layer 3: 1-3-1 dice
Layer 4: 1 die
The goal of the game was to extract all 16 of one color from the pyramid. {I suspected that having to clear all the dice would take way too long and that pursuing a particular color would lead to interesting decisions in deciding what to take from the pyramid}
The pyramid had rules for which dice were exposed- you could only take a die if it’s top face was revealed and at least 1 other face was not covered by another die. [This was incredibly intuitive because both of these things have to be true in order for you to physically grab a die without disturbing the rest of the pyramid.]
The core gameplay was organizing the dice you had taken from the pyramid among your experiments. Just like in the final game, you were always allowed to freely rearrange your dice among your experiments but could only take new dice if none of your experiments were unstable.
You also had 4 free-cells which could hold a single die and be consumed to give yourself more experiment slots. If you obtained all 5 of the special dice, then you were granted an extra storage cell
The alchemical laws were exactly the same throughout the entire development journey. In case you have not played Meriam’s Trial and are still reading this, I will explain them now by copying slides from their slideshow of origin
Within the context of Meriam’s Trial, these alchemical laws apply in 3 separate ways [that’s the part that makes the game *evil*]. First, the alchemical laws apply as color constraints. This means that an experiment can’t have an equal amount of two different colors or a majority with any color. Then, the alchemical laws apply as value (symbol) constraints. This means that an experiment can’t have an equal amount of two different die faces or a majority with any die face
Then there’s the spicy twist, the alchemical laws apply as meta constraints which consider the size of each experiment. This means that among your experiments, you can’t have any two experiments that have the same number of dice in them and you can’t have any experiment holding the majority of your dice
Experiments that break any laws are considered unstable, having any of those prevents you from taking new dice. In order to make these constraints possible to follow, I also included the provision that they only apply to experiments which had at least 3 dice. [And the meta-constraints would only apply once you had 3 such experiments]. This gave you some time to get some dice before you were forced to follow the constraints
Making 3 the magic number to make something active was another case of just grabbing the mechanics I had arbitrarily made up in my slideshow game [in that game Alchemy requires weird water to function, and water only becomes weird if it’s contact with at least 2 other alchemic components]
.
.
.
In the last section I mentioned that the various ways the constraints apply are what makes the game evil. Now I will elaborate on my design vision and what I mean when I say a game is evil by talking about the games that I consider to be the closest to Meriam’s Trial
My strongest inspiration in the solitaire world is Zach Barth’s Fortune’s Foundation, a tarot themed solitaire where each round feels like an entire ordeal. The deals are massive, and you have to fight for each bit of space. To make things even more interesting, the rules and mechanics are quite constraining. You get exactly 1 free-cell of storage, and when you’re using it you can’t build up your minor foundations (an important action for clearing away cards). You can pack cards in ascending or descending order, but you have to match suit and can’t simply move the cards as a unit. [Instead, you move cards like stacks, where you invert the order each time you move them, thus needing extra space to move a stack without modifying it]
All of that comes together to make a solitaire that is quite the accomplishment to conquer. In many solitaires, it feels natural to play multiple rounds per session. In Fortune’s Foundation, it feels natural to depart in satisfaction after just one successful round. The game even leaves you with a fortune to take with you out of the game and into your life. [This is my favorite part of Fortune’s Foundation; you get a screen of philosophical advice text based off which major arcana you ended with. The writing for each of these is incredibly evocative, several of them have become quite personally meaningful for me]
Trismegistus: The Ultimate Formula [designed by Federico Pierlorenzi and Daniele Tascini] is one of my favorite heavy euro boardgames. First of all, I love the alchemy theme, but more importantly I love how complex the decision making is here. The game is full of masterfully connected systems and decisions with multiple implications. There’s so much to consider in making and optimizing your plan, so it feels satisfying as a brain-burning session of analysis.
The core dice drafting mechanic is the central interesting decision which everything spirals off of. You draft dice that have a "potency" based off the size of the pool you grabbed them from. That potency translates into a number of action points you can spend before you have to take a new die, and you only are allowed to take 3 dice per round.
The interesting catch is that dice have two properties: a color and symbol. The actions you take care a lot about the color and symbol of your current die. This makes the decision of which die to take quite hard- it’s the lynchpin of your next few turns and will constrain you until you pick a new one.
The game is full of things you want to do and you only get 9 dice to make it happen. You have to fight the complex possibility space for as much efficiency as possible, it takes an immense amount of skill and foresight to realize your hopes and dreams
Calico [designed by Kevin Russ] is a cozy quilt themed boardgame that centers a devilish puzzle of tile placement. It achieves this through several overlapping constraints. Each tile you place has two separate properties: a color and a pattern. These properties become relevant in several different ways to score, making each tile important. First you have three design goals, pre-placed tiles which score if they are surrounded by a set of patterns and/or colors which follow their rule. Then you score a small number of points for each 3+ tile group of one color. Finally, there’s the cats- who want groups of specific patterned tiles in certain layouts or sizes.
If that wasn’t hard enough, you are also forced to adapt to the limited options of your hand- which will only have 2 tiles in it at any given time. Every turn you have to place one of those tiles, whether you want to or not. An empty calico board is brimming with possibilities, each turn you feel the agony of binding yourself to a more and more constrained board. You can’t wait for the perfect tile in every spot, so you are forced to make compromises and abandon scoring possibilities.
Popcap’s Alchemy is a casual videogame where you place runes on a board with the intent of filling rows & columns to make progress transmuting each tile on the grid. Each placed rune has a random symbol and a random color which serve as the main constraints in the game. Each turn you must place a new rune, and the spicy catch is that the rune you are placing has to be adjacent to a rune with a matching color or matching symbol. This makes the entire game about how you plan your arrangement of tiles- to leave yourself room for the various possibilities of upcoming runes. Of course, eventually space gets tight, and you have to start making the hard decisions to stay afloat. You’re juggling so many different colors and symbols that you can’t have a good spot for everything and sometimes have to drop things in unideal locations. The game becomes a challenge of planning and constantly adapting to each random tile pull.
All of these awesome games are great examples of what I consider evil design in this context. These are games with design choices intended to make achieving your hopes and dreams more difficult, where the constraints and mechanics frequently conspire to make decisions hard for you. When I call a game evil, it’s almost always a compliment, it’s a sign that the game is interesting.
I love modelling the designer as an antagonistic force against the player, someone who introduces intentional complications in the path of the player’s goal. In a sense, it’s a friendly competition between both parties; In a peak evil game, the player should be able to imagine the designer as a rival committed to personally thwarting them. I consider this dynamic to be one of my favorite ways to generate compelling and memorable play.
This is a long way to say that the primary design intent for Meriam’s Trial was to create an evil game. The primary foci for achieving this was the use of dual constraints, a notable feature of all the games I mentioned in this section. The goal is to force you to consider multiple things at once with each move, it is impossible to only affect one variable at a time [this is also a reflection of my experience with game design].
In order to compound complexity, there are multiple layers of dual constraints. First, the objects you are placing have two relevant properties, much like the tiles in Calico and Alchemy. When you make an experiment in Meriam’s Trial you must simultaneously consider two sets. Then, both alchemical laws push your structures in a different way, preventing a majority often creates equalities, and preventing equalities often creates majorities, so you have to discover configurations that simultaneously satisfy both constraints.
I added the meta-constraints as yet another layer for two equally valid reasons.
- I wanted a mechanic that forced the player to juggle multiple experiments instead of making a single one
- I thought it would be funny to subject playtesters to this absurd layer of complexity
To elaborate on that 2nd reason, I consider first prototypes to be a special opportunity. I know that the outcome of that first playtest will either be trashing the idea or completely redesigning the game. Either way, I’m confident that I’m making systems and content that I know won’t see the light of day. So why not take this as a chance to do crazy experiments? Further down the design process I’ll be too burdened by trying to make the game good, while at the beginning I can just go wild and test out cursed design ideas. Many designers like to test out the most distilled versions of their ideas to see if they have any potential, I instead prefer to test a jumbled mess and then scavenge through the ruins to see what had potential {Sorry to anyone who ever plays the first version of any of my games. I make the experience rougher on you intentionally just to satisfy my curiosity}
It was quite a surprise that meta-constraints was actually a good mechanic, since it was half intended as a cursed mechanic. Well that’s part of why I do experiments like that, because sometimes I stumble onto unexpected results. Meta constraints don’t just successfully force the player to juggle multiple experiments, they also pretty much form the heart of the game. They are what makes the game interesting after you pass the introductory puzzle of “how the do I even make a stable experiment.” Without them, the game is incomplete and would not function as an interesting solitaire.
.
.
.
Meriam’s Trial has always had a key difference from games like Calico and Alchemy. The latter games emphasize binding decisions, while Meriam’s Trial leaves you with the freedom to arbitrarily rearrange your experiments. The only binding decision in my game is what tiles you take. This wasn’t a strong design intent in the same way as making an evil game was. It feels more like an early decision that survived the whole development journey.
I don’t think I actually gave enough thought to this aspect of the game’s identity while designing it, I never even thought to test a version of the game where tiles were permanently placed in experiments. My instinct is that flexibility is necessary due to the complexity of what you are doing and tyranny of the constraints, but since I didn’t try without it, I can’t know for certain.
This makes Meriam’s Trial quite a departure from a lot of the solitaire genre. Those games often require you to have available space to do any rearrangement or movement. It’s harder to block yourself in Meriam’s Trial, since you hold the power to fix many game states by utterly reorganizing all of your experiments. You’re a magician who can get out of any bind if you try hard enough- emphasis on trying hard because restructuring your experiments is so much mental effort. In practice, this power becomes a “in case of emergency break glass” that most players avoid due to the sheer work it takes. It was quite rare to watch playtesters ever resort to this. This makes me wonder if the ability to do this really adds anything to the game, do most players prefer to just reset to a new deal?
It also means that you can play in a pretty short-sighted fashion, always simply focusing on your next step for expansion. In this way, I think Meriam’s Trial fails to be evil. It’s too forgiving and doesn’t force you to truly plan.
It’s tricky because forcing the player to make more binding plans might be going overboard given the mental ram that the game already uses. It’s a hard balance, one that I might ponder more if I ever make an expert mode.
Most of my playtesting was watching first-time players. I’m satisfied with the arc of discovery that the rules prompt as you struggle through that first deal, but I have much less satisfaction in the game’s overall depth if you play more deals. Given that the game is designed around the former experience, the forgiving flexibility makes sense.
It’s also worth noting that realizing there is no easy next step and putting in the effort to create one by restructuring experiments can be an immensely satisfying experience. One of the major appeals of playing an evil game is the feeling of Fiero {a term that some game designers use for the thrill of conquering a difficult and intimidating challenge}.
Meriam’s Trial is generally successful at evoking Fiero. Given that Fortune’s Foundation is such a huge inspiration to me, I at least consider that a significant accomplishment. I do think games like Calico might have hit the sweet spot of decision making and enjoyable complexity better than Meriam’s Trial, but I’m happy that I nailed that feeling of doing battle with an overwhelming possibility space and coming out on top.
{Also, fun fact, I didn’t play Alchemy or Calico until I had already mostly designed Meriam’s Trial and was in the middle of developing it. That’s fascinating to me because it was so easy to spin a narrative of those games being inspirations and drawing a line of similarity from them to my game. It feels even more perfect given that Alchemy even shares a theme with my game. Discovering that game while working on Meriam’s Trial was a crazy coincidence. [Shoutout to my friend who randomly blogged old Popcap games.] Meanwhile, I played Calico specifically as research}
.
.
.
I already mentioned that my first playtest was a success to me, but what was the experience like for my first brave playtesters that night at the Kansas City Game Designers meeting?
The game was incredibly mentally demanding and overwhelming to play! The first tester opted out of continuing the game once they broke the initial barrier presented by the meta constraints- they told me that it would strain their mental effort beyond what they would enjoy giving to a game [although they didn’t doubt that they would eventually be able to solve the whole thing].
I also had to spend the entirety of both playtesting sessions validating that each game state was following the rules. Even when a player would make a move with the express intent of creating a stable experiment, they would still ask me if they were breaking any of the alchemical laws just to be sure.
I knew when explaining the rules that players would ignore the meta constraints at first. I used my role as an observer to remind players of them just as they get comfortable with making experiments- giving them enough time to tackle that as a problem before it was too late. Normally, I’m not an advocate for interfering with a playtest as the designer, but it worked out very well here. I wouldn’t have learned much from watching my playtesters lose the moment meta-constraints became relevant- seeing how they tried to prepare for it as the next level of challenge in the game was incredibly worthwhile.
I had chosen 3 active experiments to be the magic number for activating meta constraints because 3 dice was the number I was using to determine if a single experiment was active. It felt right to use the same number for both of those things. Turns out that 3 experiments is the perfect threshold for meta! It gives the players room to learn how to make a valid experiment and practice one more time before things get a lot more complicated. This is one of my favorite surprising results from the playtest- I had naturally made an interesting progression arc that eases the player into the game.
.
.
.
After my first night of playtests, I ended my friendship with physical prototypes for this game. The dice pyramid was a pain to build and way too fragile during play. At this point, I was still conceptualizing the game as a tabletop game, but I decided to move to digital prototyping for a while.
At the time, the only digital tabletop prototyping tool I was familiar with was Tabletop Simulator, so that’s where I built the game. I would like to make clear that I do not endorse Tabletop Simulator as a platform currently and am happy to see other tools have started to become dominant in the tabletop world. That said, I do consider it worth discussing as part of the history of making my game despite the fact that I have no desire to encourage others to use TTS
I’ve always hated how much of Tabletop Simulator’s identity is in being a 3D engine and physics toy. I don’t like the friction and overhead that adds to testing out a boardgame. TTS just happens to be a tool that designers can use to test their prototypes- that doesn’t feel like a development priority for Berserk Games
Ironically, Meriam’s Trial is a game that needed the 3D features of TTS because of the pyramid of dice. So, this is actually a case where it felt like a good tool for the job. It absolutely served the role I needed.
Once I painstakingly made a digital pyramid of dice, it was nice to have a saved version that I could load to start a new game. This means that both playtesters who played this version of the game experienced the exact same deal.
It turns out that the pyramid was still fragile on TTS due to physics simulation, but there was the glorious undo key, and it was obviously a clear improvement from the physical pyramid. What turned out to actually be a downgrade was having to use a camera to inspect the pyramid (as opposed to the position of your body and head irl)
My favorite part of prototyping Meriam’s Trial with TTS was the power of making saves during a playtest. Despite my opinion that screentop.gg is a vastly superior platform, this is one thing that TTS really brings to the table for me. It’s great to have the capability to return to a finished game for further analysis, it’s nice to be able to jump back to previous states, and it is incredibly handy to be able to return to the same game later if a playtester runs into time concerns. Now that I think about it, I didn’t actually utilize these features much in practice, except for the fact that I did have to save one of the playtests for him to return to later. [Also In my head the power to analyze saved game-states from playtesters sounds amazing, but I just can’t be bothered to actually do it]
Another huge advantage of digital prototyping was being able to send the game to online friends and fellow designers that I’ve never met in person. Tabletop Simulator is one of those games that you can reasonably expect most of your steam friends to have, like Portal 2 and Terraria. The friend I was most interested in getting the opinion of had Tabletop Simulator so that was convenient. Once I began working on Meriam’s Trial as a videogame, the advantage of being able to just send the game to online people grew much more powerful- although I couldn’t support as many platforms as Tabletop Simulator did. I removed the need for someone to have purchased specific software, but I was only building for windows and web. Web sounds like it would be peak accessibility, but it turns out that Godot 4 web games don’t work on MacOS due to a so-called “upstream error”.
I only did 2 playtests with TTS (one synchronous and one asynchronous), but those were quite helpful on my journey. Also, TTS allowed me to humor the 3D pyramid a little longer, so that was fun.
Here’s a picture of the TTS version
[Now that I am looking at this picture, I do have to shoutout one more thing about Tabletop Simulator- infinite pouches are the best feature, I love them]
.
.
.
My major takeaway from my first 4 playtests was that Meriam’s Trial wanted to be a videogame. I’m a designer who makes both tabletop games and digital games, but this is my only project so far that’s switched medium. This was not a decision I made lightly, because programming a video game is a lot of work.
I’ll list the reasons why I made the switch
In each live playtest, I spent a significant portion of my attention ensuring that the player was following the rules. I don’t want to do that! In the asynchronous playtest, the player realized they had cheated at a certain point post-mortem and they also kept playing after they had won due to misunderstanding the goal. Then even in the games where I acted as an administrator, the players were still spending a significant amount of Mental RAM on validating game states. It was obvious that automated logic to check the alchemic laws would free up valuable attention for both me and the player
Building and interacting with the pyramid was a pain- both irl and in TTS. Even if I got rid of the pyramid, the game still required a heck ton of dice. Not everybody owns a copy of Sagrada. [My tabletop games are generally intended to use components people have on hand rather than a box of components you would purchase]. Not even Warhammer 40K players would be likely to have the exact dice on hand, because the game required several different colors
Speaking of requiring different colors of dice, that’s a form of inaccessibility. I love the mechanical implications of colored dice, but they aren’t color-blind friendly. Making a videogame ensured that I could make some kind of pattern or image to distinguish different types of dice
Then, a surprisingly important factor was that I simply wanted to work on a long-term video game project! This was during the summer of 2023 and there were a few factors that were converging to make this desire strong. First, I had finished working on Ambivalent Aggression a few months earlier and wanted the balance of working as the other kind of game designer. Additionally, I was mid-way through my computer science degree and had confidence in my programming ability for the first time in my life- I wanted a long-term project to put it to the test. Furthermore, I had recently decided to dive into learning the game engine Godot [I had been using Unity all my life] and wanted to start a project with it to start truly learning it. {Important timing note: I wanted to jump ship from Unity *before* their announcement of pay-per-user-install. That just made me feel vindicated that I had already spent a couple months investing into Godot}. Finally, I had been having a string of failures in video-game jams where I had to give up without making anything, so I wanted to prove to myself that I was a videogame designer
The obvious price to making a videogame was spending hours of my life implementing it, but there were 2 other significant drawbacks.
First, videogame design is less free than tabletop design. It’s harder to justify redesigning the entire thing because you lose so much work and once the project gets big enough, you’re guaranteed to be constrained by assumptions made when programming. A videogame designer is bound by their past decisions in a way that tabletop designers don’t have to be. You can see this difference in my games Ambivalent Aggression and Meriam’s Trial- the boardgame went through like 7 complete redesigns and the videogame kept the same core throughout the entire journey.
Then there’s the other drawback- suddenly I was struggling to get playtesters.
I had spent the last 2 years finally getting into game design communities- for tabletop games. Every single community I was in had rules prohibiting testing videogames at their events. I understand why these rules exist, but wow this was frustrating. All of my playtesting opportunities simply evaporated. I’m not a social or well-connected person, so I rely on designer mutual playtest events to get my games play tested. Unfortunately, those events are part of tabletop designer culture- not videogame designer culture.
This is one of the most jarring experiences I’ve had as a designer of both worlds. To rub salt into the wound, during this time I went to the amazing Protospiel Online for the first time, which really reminded me what I was missing out on because I happened to not be working on a boardgame at the time. Ever since then, I’ve tried to ensure I’m always working on at least one boardgame project at all times to avoid repeating this awful feeling.
.
.
.
My games are consistently like nothing else I’ve played, it’s a prominent aspect of my style. This means that a major part of their design journey is simply my quest as a designer to understand what I’ve made and what it wants to become. Often, even my core design intents are things I discover along the way. This does make writing retrospectives like this a little difficult- since it’s harder to recall how my conceptualization of something has changed over time than it is to share my current understanding.
With Meriam’s Trial, I quickly discovered that I was working on a puzzle game despite my primary intentions to create a solitaire. I don’t really have any experience designing puzzles and just stumbled into the arc of discoveries that define Meriam’s Trial.
I have a high interest in puzzle games, although I generally consider making them to be outside of my expertise and strengths (Most puzzle games emphasize scenario design which is one of my weak points as a designer). So with Meriam’s Trial, there weren’t any levels to be designed (outside of my attempts at a tutorial), but I still felt out of my comfort zone.
At this point I realized I’d need to find a new game design community, so investigated the world of videogame puzzle designers and joined the thinky-puzzle-games discord server. I intended to just observe there- since I didn’t want to be that guy who joined just to talk about my game. That ideal did not last very long… the first major conversation I had on the server was asking for help on my game.
The discussion and feedback from that conversation were incredibly helpful (in fact rereading them now, I’m thinking about how I ignored a suggestion that might solve a problem the game still has. This keeps happening while I write this retrospective, something lets me ponder jumping back into active development… wow I sure am frustrated with the final game I currently have) I got a lot of UX insight from this conversation as well, including this cool mockup someone made to show an entirely different way of representing the game. I never pursued that path, but it was fun to think about
(Drawing by Noa from the thinky-puzzle-games discord server)
Eventually I felt like I was engaging enough with the community to justify posting my game in their playtesting channel. Here I had 2 helpful playtests… wait I’m starting to notice a pattern. I had 2 playtesters from Kansas City Game Designers who played the original physical version, 2 playtesters from thinky-puzzle-games, 2 friends tried the TTS version, 2 people took interest in the game after I posted it on my personal discord blog, and I shared the in-progress game to 2 of my close family members. [Also breaking the pattern a little bit, I did shove the video game version onto another member of KCGD at one point]
Anyway, the thinky-puzzle-game discord server has ended up just being a cool place I lurk in. They were an important part of this game’s journey, but now I mostly engage with them as a source to discover cool games and occasionally observe interesting discussions. I think it’s become clear to me that I am neither a hardcore puzzle fan nor a puzzle game developer- although it’s still fun to keep the community on the periphery of my attention
.
.
.
The way meta starts irrelevant and then becomes relevant makes it an expensive complexity barrier when people are first learning the rules. From my first playtests, I immediately got the feedback that I could experiment with a game structure where new rules and complexity are unlocked as you progress through a deal.
This is a design direction that I’ve pondered all throughout the game’s journey. I abandoned and rediscovered it multiple times. I never actually fully committed to it on any iteration, but it was a recurring consideration. Meriam’s Trial was very close to having a student mode, which would emphasize the unfolding nature of the game. I still let myself wonder if the more traditional solitaire style of dumping you with the rules was correct for this game.
As it stands now, it’s quite jarring to be hit with the opening puzzle right after you read all the rules- because that’s the point where you’re still trying to wrap your head around how the game works. One path I did heavily explore was moving the opening puzzle [learning to make a 1-2-3 experiment] to *before* you read the rules and start a deal. The idea was to start the new player experience with a screen that explains the 2 laws of alchemy and ask them to make a valid experiment. Then after passing that the actual game would load and they could read the rules.
I think the game in that form was a lot more approachable- but it introduced a few annoying problems, and I simply found designing a tutorial to be a pain. The most significant problem was that it felt like I was taking away an interesting epiphany and handing it to the player on a silver platter.
If the last person I sent this game to played a version with this 1-2-3 experiment tutorial, I don’t think they would dropped the game after 7 minutes. Yet even with that experience fresh in my mind, I still can’t bear including it. If I was a better scenario designer, I think I could have made the pre-rules tutorial a good puzzle, but as I see it right now there’s no way to include it in a way that would have satisfied me. [Also the tutorial meant that players would end up making 3 basic stable experiments before considering meta instead of 2. This was redundant and felt bad for players- the Mario Bros rule of 3 is overkill and I will die on this hill]
As it stands now, I paid a significant price in approachability. This decision to remove the 1-2-3 experiment tutorial will ensure that many more people will bounce off the game, all I can hope is that some people appreciate working for that starting discovery themselves.
.
.
.
One of the fascinating things about my journey with Meriam’s Trial was that I avoided playing it myself for *months*. This is especially amusing since it’s a solo game and thus would have been trivial to play a session of while at home.
The very first prototype of the game was finalized during my drive to the playtest meeting, and also was intentionally designed as a wicked experiment to subject others to. Both of those were good reasons to have not done a self-playtest, but then I continued to not play my own game. Soon it became an amusing challenge, how long could I avoid playing Meriam’s Trial? [It was disappointing when I had to break the streak shortly after starting the videogame version, since I thought it would be wise to do a full playthrough as a way to catch bugs.]
Recently, I’ve realized that I want to make this a tradition that applies to all of my designs. I was talking with another designer, and they told me how important it was for them to design games that they wanted to play. That was an interesting perspective, considering that I hate playing my own games.
A few weeks ago, I played a round of Ambivalent Aggression to show it to some friends, and that turned out to be quite the unpleasant experience. While playing and driving home, my mental monologue was on par with what I have to deal with trying to get out of bed and eat breakfast on one of my bad days. All that for a game that I know that I’m proud of!
I consistently don’t see the value in my games when I play them, it’s a strong case of “I’m my own worst critic.” When it comes to my own games, I trust my evaluation from observing way more than my evaluation from playing.
Reflecting on this and hoping that Meriam’s Trial was a lesson worth following, I’ve decided to generally avoid playing my own games early in their design process. The intent behind this rule is to protect my games while they are still vulnerable, since if I play them in that state there is a significant chance I could simply lose all my motivation to work on them. {This just happened with a videogame I’ve been developing off & on for the past couple months}
Many game ideas have a pretty intense emotional hold on me where thinking about them just fills me with energy and momentum. It’s incredibly jarring to be reminded how fragile that feeling is- that it's very easy for me to utterly stop caring about them. I could have that power sustain me for hours of working on a game and then after playing just one round it’s all gone. I am curious to see if applying this rule of avoiding playing my early prototypes will be any help against this- it did seem to work well for Meriam’s Trial after all.
.
.
.
In Meriam’s Trial, building a new experiment requires foresight. An experiment can’t possibly be stable until it has 6 tiles- so you need to ensure you’ve taken those 6 tiles beforehand or you’ll lock yourself out while the new experiment is in progress and be unable to take the rest of needed tiles.
Due to this property of the game, I think that there must be some sort of storage mechanic. There needs to be some way to hold tiles that aren’t under the constraints of the alchemical laws (or you grab multiple tiles at a time instead of one tile at a time and I haven’t figured out a good way to make that approach work).
For this reason, I had a rule where experiments weren’t active until they had at least 3 tiles in them. This rule was always interesting to me, because experiments would still become active before they could ever become stable. [There is no possible way to use 3,4, or 5 tiles to make a stable experiment]. I purposefully avoided changing the active threshold to 6 tiles, both for thematic reasons and to not give a hint towards making 1-2-3 experiments. Perhaps the latter justification was a mistake in reasoning, since in the final game I included that hint anyway as optionial text on the game’s webpage.
As per solitaire tradition, there’s 2 types of open space in Meriam’s Trial. The explicit storage mechanic that can hold anything and the space you free up by building experiments.
Regarding the former, deciding what capacity to make the explicit storage is a pretty interesting question. It needs to give the player enough room to take a few unnecessary tiles- so inexperienced players have an important safety margin and experienced players can dig for specific tiles. If the explicit storage is too big, then I lose the solitaire game essence, and it just becomes a puzzle on how to arrange the tiles without any concept of making moves [I ended up including this as a practice mode a few months ago]. The first prototypes had 5 or 4 storage cells, at some point I experimented with larger sizes like 12, then the magic number my intuition landed on was 8, finally I decided to bump 8 up to 9 once I got rid of the implicit storage in empty experiments.
[The thresholds for experiments to be active meant that in practice in-active experiments were implicit storage. I ended up removing the concept of active thresholds as one of my final changes to streamline the rules. Notably, 1 more cell of storage is not equivalent to 4 experiments which can each hold 2 dice before you start using them, so this change to streamline the game also made it significantly harder. I was satisfied with that side effect]
The other type of space in this game is a lot more interesting because the player has to discover it. As you build up larger experiments, you gain more degrees of freedom that you can slot excess tiles into. The constraining effect of the alchemical laws has an inverse relationship with the size of the experiment, it’s incredibly easy to just dump stuff into a large experiment or sneak a tile into a mid-sized experiment. This is one of my favorite mechanical discoveries in the game, because of how it reveals itself quite naturally while still making the player feel really clever. It’s also elegant as a feedback loop that gives you power as your board gets more complex.
In fact, this power is probably too good. Once an experiment gets large enough, you can especially go wild with adding elements to 1st and 2nd largest sets, and not be scared of the equality or majority laws. The design has two forms of defense against this playstyle- meta constraints and the victory condition requiring you to clear everything. Unfortunately, meta constraints are themselves vulnerable to this approach- once your board gets large enough you can go wild with adding tiles to your 1st and 2nd largest experiments. I also have no idea how to prevent this because it’s an implication of the core alchemical laws and those are a pretty untouchable part of the design.
This leads to one of the most significant problems with the design, the late-game is a lot less interesting than the mid and early-game. [The final few moves are the worst, as you can just trial & error placing the last few tiles]. I never found a way to fix this, so my best attempt was to just reduce the length of the late game by making the player win faster. All throughout development, I’ve been shrinking the number of tiles in the game. The first version had 84, the current version has 50.
.
.
.
Most of the time spent on this game was as a programmer, my progress was measured more in implementing functionality and quality of life features than design revelations. Surprisingly I don’t have much to say about that. The project was in the sweet spot of being comfortably within my skill level but still involved enough to be great practice (and a good way to learn Godot).
I didn’t run into any significant skill-issue blocks the same way I always used to on my old videogame projects, and I was able to debug problems much more efficiently. It’s satisfying to know that I really have grown* as a software engineer.
*my code is still a mess though. Enough time has passed that I fear ever opening the project again. I need to start giving personal projects the same documentation I give school projects.
The main takeaway is that Godot was a pleasure to work with. This project convinced me to make it my primary game engine. I’ll go ahead and list some of the highlights: They provide so much convenient built-in UI functionality; Godot has some really solid features for debugging; GDscript is a nice language [the dictionaries go hard]; The whole environment is light-weight; It’s not Unity; The documentation is great; I like core design decisions like Scenes and Signals; Then of course, I’m happy to be using open source software.
The biggest problem I have with Godot is that when you run into its limitations you run into them hard. I’m going to snap If I see another forum post where someone suggests circumventing an engine limitation by going in and implementing your desired functionality yourself since it’s open source
Anyway, speaking of code that you can just go and look at, here’s the github repositoryfor Meriam’s Trial.
It’s too messy and uncommented to be seriously useful for any learning, but I have a certain satisfaction in having public source code- that’s something I currently intend to do for all of my personal videogame projects. If you are interested in the journey of how I built the game, as opposed to the journey of how I designed the game that I’m writing here, than uh feel free to check out my commit history. [I doubt that will be very informative since I only wrote titles and not descriptions for my commits. Look, documentation is a habit I have to force myself to learn and I’m not quite there yet.]
.
.
.
My greatest enemy in videogame design is UI sizing and screen real-estate usage. I hate thinking about how to position screen elements and in every engine I’ve ever worked in I’ve struggled with how to do dynamic UI scaling. I am always afraid of sending a game to someone and they have screen elements cutoff for them.
In my first version, there was explicit controls for scrolling the screen and changing the zoom- the former necessary because of the height of the research tableau and the latter being a fail-safe against thing being cutoff. It was immediately obvious that the game should fit on one screen. Frankly, I shouldn’t have even entertained the idea of a scrolling screen for this game.
That does lead to an important question though, how much of the screen should be taken up by the research tableau, how much should be experiments, and how much should be taken up by other elements like storage and reference. I hate thinking about this question!
I settled on the answer that the experiments are the most important part of the screen. They are the most complex structure to keep in your head and your interaction with the research tableau is ultimately determined by the demands created from your experiments.
I currently have an information panel on the right side of the screen. I think most people would tell me that it should be a pop-up menu, and the game state should be the entirety of the screen. I don’t entirely disagree with them, but I also don’t really feel like doing that. I like the side panel for having a visible notes tab for one, I don’t want to watch a playtester open up an external program like notepad to play my game. [Making experiments is mentally demanding enough that some players naturally make notes to help themselves, the game isn’t designed as something that is intended for you to need personal notes]
The biggest thing keeping that information panel always on the right side of the screen is that I don’t want to implement something more sophisticated. It could work well as a draggable and closable window, but that sounds like too much pain to make. I’d rather just take the user interface hit here and spend that time on other projects. It is a significant hit though, because the way it eats space kills a lot of the aesthetic potential of the game screen.
I was also particularly annoyed by the way the information panel interacted with whatever UI scaling settings I cobbled together. To this day, I’m still not confident that it won’t be cut-off for some players. For my own sanity, I’ll pretend that the information panel behaves properly on all screen sizes.
.
.
.
At first, I wanted to make a game where the Research Tableau was the most important part of the player’s attention. This was a desire to be part of the solitaire tradition, games in which analyzing the board and planning your next moves are the core focus of the gameplay. That’s a big reason why I liked the original pyramid and win condition that wanted you to clear a specific color from the structure. [The former died because the interesting decisions and presence it offered didn’t justify the cost for me to implement it or the bandwidth it imposed on the player. The latter died because the ending wasn’t very satisfying or intuitive, and players felt like the game wanted them to clear the board, a sentiment that I now agree with]
As I continued to understand the game’s identity as a hybrid solitaire-puzzle game, I shifted focus away from the randomized board. The mechanics force constructing experiments to be the main attraction and engaging with the structure of upcoming tiles to be a secondary attraction. In the final game, the Research has been so deemphasized that there isn’t enough interesting variety between deals. You don’t feel like you are playing a specific situation, and I’m not convinced the random layout actually meaningfully matters to decision making.
[Sidenote: Perhaps a mechanic where you simply draw new random tiles from a bag would work well in this game, but I’m just so attached to the idea of a structure that you take tiles from. If I ever return to working on Meriam’s Trial, then drawing hands of tiles will be one of the first new ideas I test.]
The fact that the research tile layout feels irrelevant means I’ve failed to make a proper solitaire game, although it’s in service of the puzzle game component. Unfortunately, I’ve also burdened the puzzle game half with being procedural, which makes it harder to design around the core discoveries and questions. Such is life when making a hybrid game, although overall I consider this dual nature to be a large part of what makes the game interesting.
.
.
.
In my Fall 2023 Semester, I had a school project where I resolved to make a videogame with color-blind accessibility as a core design consideration. {This was for my Human-Computer-Interface course}. I had all semester to work on it, but then I didn’t! On the very last day before the project was due, I had still not started it, so I decided to go for some desperate measures.
I borrowed the work I had coincidentally been doing on Meriam’s Trial for the past few months and then slapped on a system to customize the colors. You could change the color of the icon, background, and text individually for each element type.
Shoutout to Godot for making this incredibly easy to implement. They really saved me in my hour of need!
Anyway, you might notice that this feature is not in the final game. That’s because I had to commit an act of terrorism against my project to implement the feature so quickly. In order to make it so the assets could simply have colors applied to them from Godot’s system, I replaced every icon with an all-white version.
Including the all-white versions as separate files and properly integrating the system to not be destructive towards the project probably would have taken another hour at most. I didn’t have it to spare that Sunday night and was happy to take any shortcut available to me. The entire system was built on a new branch which I immediately discarded after midnight.
While I’m here, I’ll mention that the only reason I gave the tiles art was to make the game color-blind friendly, that’s one of the first things I worked on after I got the initial version working. That’s part of why it worked so well to borrow the work I had been doing with this game for that school project, because color-blind accessibility was already a consideration that had been part of my dev journey.
Making the different tile types have unique shapes instead of just unique colors is an improvement that benefited all players- a great example of the curb-cut effect. The game is much more aesthetically pleasing, and the tiles are way easier to tell apart, all because I didn’t want to rely on color as the only way to tell the tiles apart. Always try to avoid communicating anything with just one channel of information , that’s one of the golden rules of game design usability.
.
.
.
Before final section of this design story, I’m going to rapid fire through some stray thoughts that don’t deserve their own section
-For most of the development, there were 5 experiments. Removing the 5th experiment was one of the last balance changes I made. The intent was to make the game tighter, and it felt like a reasonable change since I had often seen playtests end without ever using it. This change had a side effect of making the screen layout work much better, because an even number of experiments means that both rows will be the same size. This allowed me to expand the size of the right info panel which is what convinced me to move the game rules into that panel instead of in a pop-up window from clicking a rules button
-My intuition is that every deal is solvable, but I have no idea how to actually prove this. It feels like I gave the player so much flexibility that I’m not sure how the research board could effectively conspire against you.
-I hated writing the rules for this game, they were something that I constantly found myself redoing. The alchemical laws are hard to elegantly explain because of the way they apply to the set of letters and the set of shapes in an experiment. I also didn’t want to have visual examples that spoiled how to make a valid experiment, since that’s an intended puzzle for starting the game. I ended up adding visuals that serve as examples of law violations (instead of examples of following them), which was a satisfying way to supplement the explanation without betraying the puzzle
-It’s quite natural for me to use thematic language in my games. From the beginning, I was calling the player’s groups experiments and the structure you take from research. Once I no longer considered the game’s tiles dice, I started calling them essences.
I strongly recall giving someone Meriam's Trial as a blindtest where I couldn't watch (since I was busy playtesting another designer's game). I figured I’d be able to get their feedback afterwards and it'd still be helpful. When I came to interrogate them, they had apparently understood absolutely nothing. Like they had no idea what the game wanted from them. When I walked up, they immediately asked me "Zach, WTF is an essence?". I promptly renamed essences to "tiles". I keep this as a strong lesson to remind me that the purpose of game language should be primarily to help players understand the rules
-The game has no audio. Maybe someday I’ll learn some basics, but currently I’m fine with limiting the scope of games I work on to get away with not needing sound. As a child, I put a lot of stock into the idea of being a generalist game developer- someone who could do design,programming,writing,art,sound. Nowadays I’m satisfied with just wearing the 3 hats of designer, programmer and writer. I took some digital art classes in school, but the main thing I learned was that it wasn’t a path I had any interest in. Music has always felt like a gaping hole in my knowledge, it’s an area where I’m just so clueless. It’s a field that interests me, but right now I accept that I don’t have room in my life to dive into it.
-I got a couple of requests to add an undo feature. It’s hard to avoid my kneejerk response of saying “skill issue”- that’s a terrible mindset to have as a designer. I do hold the opinion that most solitaires play better without an undo, since realizing you’ve blocked yourself is a good teaching moment. That’s interesting, because normally I’m a huge advocate for allowing undos in games. It would be fun to do an analysis of why solitaire games are an exception to that for me.
Anyway, I stand by not including undos in Meriam’s Trial due to the vast flexibility of being able to freely rearrange your experiments and large size of the storage. I also wanted to ensure that the player always had specific intent with the tiles they took from research. It is worth noting that Meriam’s Trial is much more mentally demanding than most solitaires, so it invites mistakes more easily. Playtesters also got very invested in the first round they played, it felt like they were allergic to simply trying a new deal. These factors both suggest including an undo, but I concluded that the game’s design supported player driven recovery efforts well. Ultimately, I feel like the satisfaction of rearranging your experiments to continue despite a mistake is an experience worth designing for even at the cost of annoying some players.
-During the last portion of development, I toyed around with many ideas for an expert mode. I prototyped some Transmutation mechanics as a way to reinforce the alchemy theme and introduce a new layer to decision making. I love the idea of a tile that once placed in an experiment changes the tiles in that experiment in some way. I stopped working on the game before I seriously began any expert challenges, so they are mostly just what-if ideas that haven’t had any iteration. It’s yet another path that will demand my exploration if I ever return to this game.
.
.
.
The final leg of making a game is the part that is the roughest on me. I always get hit with that feeling of wanting to move on and stop thinking about it while there’s still important work left to do. I usually force myself into a crunch as an attempt to escape the power a game has over me. During these periods, I find it hard to focus on the work I want to do, but unable to convince myself that I want to be doing anything else with my time.
I have yet to learn how to avoid this inevitable outcome. With Meriam’s Trial, this effect coincided with an intense build up of frustration regarding the new player experience and my desire to preserve the cool discovery of how to build a valid experiment. I started to find the conflict between the puzzle and solitaire halves of the game overwhelming. I scrapped the tutorial, then got excited (again) by the idea of making an unfolding new player experience that introduced new game elements and mechanics as you made progress. I scrapped that too, and ultimately decided to just make the player read the whole ruleset before playing- following the style of solitaire videogames (and boardgames)
I spent the last day of 2023 making final changes to Meriam’s Trial. I was annoyed that I had to cancel joining a friend’s new year plans, so I resolved to use that time to ensure I was entering the new year free from this project. I wonder if anybody has noticed that I released this game on 12/31/2023- that’s the kind of release date that videogame databases use as a placeholder… What kind of person would actually release a game then?
Apparently, me. That’s how much I wanted to move on from the project.
The more I write this retrospective, the more it becomes clear that Meriam’s Trial really is unfinished in my head. I don’t have enough confidence in the final design, I still see new paths that beg to be explored. I’m so tempted to rip the band-aid back off and pretend the 8 months since I released was just an extended break.
Yet I also remember what it was like in the last few days of working on this game. Why would I let myself return to that? Could I bear making Meriam’s Trial an officially unfinished game in my head? Is it worth chasing all these ideas when I could just be working on other games? Do I want to go through the pain of trying to find new playtesters, when the vast majority of my connections are still tabletop designers?
Most importantly, I’m not convinced that my code would *allow* me to return to active development. I know it would be unrecognizable to me because I’ve let it leave my head and didn’t bother to leave proper documentation for my future self. As the saying goes, it’s easier to write new code than understand existing code. That’s definitely another cost to my decision to make a videogame, it’s harder to simply take a long break and return to it.
I hope you found this design story interesting. It sure took me a long time to write.
Now I am just left with the question of whether to jump back into the fire and resume active development on Meriam’s Trial
Leave a comment
Log in with itch.io to leave a comment.