This post has been de-listed
It is no longer included in search results and normal feeds (front page, hot posts, subreddit posts, etc). It remains visible only via the author's post history.
First, Iâll say the title of this post is a nod to âSecret Histories of Dominionâ articles written by Donald X Vaccarino. (I highly recommend you check those out if you have played Dominion and are interested in how Dominion came to be) Iâll also say this is focusing on the design and development of MonstaTamaâs mechanics. Illustrations, graphic design and the preparations that went into MonstaTama's crowdfunding campaign are all important aspects of the game, and although I was heavily involved in creating those as well, the mechanics are the area I feel I can give the best insight into why and how they came to be. There are some references to the game as it is today, but for the most part, this presents the design challenges and solutions the game went through in a way that should be understandable even if you havenât played MonstaTama.
Coincidentally, our story starts with a Dominion game 8 years ago; the first time I played Dominion. While deciding on a game to play, someone in the group suggested Dominion, pitching it as the following; âit's like a collectible card game (CCG), but you make your deck during the game.â I played the Pokemon CCG competitively at the time and always wanted to play it with my friends, but they didnât have their own cards, which takes away from the experience (playing against the decks that people tailor to their own play style is part of the appeal of CCGs). The idea of a game that gave all the cards players needed to create their deck and play within the game had me instantly intrigued. We played Dominion and I thoroughly enjoyed the experience (Dominion is still one of my go to games to this day), but it wasnât quite the experience I imagined.
This is generalizing a bit, but when I create a deck in a CCG, I look at the cards available to me, look for combinations that seem to synergize off of each other, identify a particularly strong outcome that can be achieved through those synergies, then try to create something that will consistently be able to achieve that outcome. This is a very rewarding process, especially when you see your unique deck creation in action. I tried to apply this process in my first Dominion game. I remember creating something along the lines of (some Dominion knowledge required to fully understand this example); a deck with Villages, Smithys and Remodels, so I could continually upgrade my cards until I turned them into points. The problem was, unlike CCGs, Dominion is a deck building game so not only do you have to identify synergies, you have to spend resources in the game to get those cards (as opposed to CCGs/deck constructors where you simply just include the synergies in your deck). By the time I was halfway to building my âdream deckâ, one of the other players was buying Provinces every turn with their (in my opinion) far less âsophisticatedâ deck. I should be clear, Iâm not saying I think deck building/Dominion is a worse experience than a CCG. Deck builders add a layer of needing to balance building a perfect engine with progressing your victory condition, which can really add to the deck creation experience. What I am saying, is that deck builders provide a different experience than what I was picturing when it was first pitched to me. This made me want to find that experience I imagined.
At first, I looked at what existed. People would commonly say what I am looking for is a non-collectible card game. While these remove a large part of the monetary barrier that CCGs have, they still expect players to do a bunch of prep work creating decks before play. I wanted to just sit down with people and construct decks as part of the experience. The next solution commonly suggested was âCCG cubesâ. For people who donât know that, essentially curating a large assortment of cards from a CCG, then forming a procedure in which players draft cards from the selection, to make decks with. This is far closer to what I was looking for, but the work that goes into preparing a âgoodâ cube is fairly involved and expensive (looking at $300 ). Additionally, when you factor in the deck construction part and playing the game, CCGs are typically fairly complex. Most CCGs ease players in by offering pre-made decks that players can learn the game with before trying to make their own. The whole point of the experience I wanted was to be able to deck construct with anyone, so needing to first play an entire game with them as a tutorial to the âactual game I wanted to playâ wasnât a very compelling solution. I was an aspiring game designer at the time and was in my first year of a university game design program, so I thought to myself, âif I canât find easily shareable deck construction experience, Iâll make one insteadâ.
From the start, I wanted the game to be focused on the parts of collectible card games that other types of games rarely focus on. While hand management is a core element of nearly all collectible card games, you can find thousands of other games that offer a hand management experience. I wanted to focus on the deck construction, the âmetaâ changing as new sets are released (this is why Biomes exist) and trading cards with other players. Avoiding hand management also significantly sped up gameplay, which was a huge plus. To achieve this, in early concepts, the gameplay where you used your deck primarily revolved around simple 1v1 gameplay similar to the card game âWarâ (each player flips the top card of their deck, the player with the higher number wins), but I spiced this up a bit by each card giving you a special ability when you either won/lost with it and giving each card an elemental weakness that would trump the number comparison. Funny enough, the somewhat recent game, Challengers, reminds me of these early concepts.
Monsters allow for a variety of very distinct looking illustrations, which I feel matches the needs of a game trying to capture the feeling of building decks from a wide variety of resources, so monsters were the theme of the game from the start. Though I was just planning ahead at this point. Illustrations came far later down the line. In the early stages, the Monster theme was just âpastedâ onto the gameplay, there was no story.
At the time, the game was called âNonnonâ, the ânon non-collectible card gameâ. The joke was that it wasnât a collectible card game, but it wasnât a ânon-collectible card gameâ either.
The initial prototypes I was testing werenât really catching on with the people, I did not have the development experience I have now and I became preoccupied with other things at the time, so they never really went far, but there were a few important things these prototypes showed;
- even with simple gameplay, most people are lost when you ask them to create a deck in a game they are playing for the first time
- players almost always ignore the option to trade with others
- matching players in 1v1 matches throughout the game required an even number of players, which was an awkward barrier in some settings
3 years later, I had graduated from the Game Design undergraduate I was in (and had significantly more experience developing interactive experiences) and I was looking to seriously pursue getting one of my own tabletop designs published. I had worked on many prototypes up to this point, but a ânon non-collectibleâ card game was the concept I was most passionate about and the one I felt could offer something that wasnât readily offered in the market already.
I had been playing a lot of Keyforge at the time. Put simply, in Keyforge, the cards you play can be used to generate resources or can be used to remove your opponentâs cards. I was intrigued by the decisions these two options presented, especially when different cards had varying effectiveness at accomplishing the two different things, making each card vary in value depending on the other cards in play. As a starting point to work off of, I created a prototype that simplified and abstracted this concept a little bit: monsters had an amount of points they would generate if they were on your team at the end of your turn (which you would track on a score track), as well as attacks that would remove the opponent's monsters. In an attempt to incentivise trading, I used the idea of âmonster evolutionâ (a well known mechanic in Pokemon). Playing the stronger monsters would require having their earlier âevolution stagesâ, so players would be more inclined to trade to find the monsters that allowed them to play the ones they already had.
Like many prototypes trying something relatively new, this prototype was sort of a flop. One big issue is players could be shut out of the game if other players built up enough aggression. Players also felt like the game had too much variance with only being able to play the top card of the deck, especially when they drew one of their powerful cards early that required other cards to play.
In the next version I stripped the attacks out of the game. Some monsters still offered ways to hamper other players but there wasnât a mechanic built specifically for it. I also gave players a hand of cards to address the variance issue. The starting hand size was 1 card, and you only played/drew 1 card per turn. Effectively this still functioned as if players had no hand unless they used an effect that drew them more cards. This still kept the focus of the game away from hand management, while providing options to players that invested into an effect that allowed them to draw cards. This version mostly solved the locking players out of the game issue, but did little to solve the variance issue. Players having a hand of cards that didnât serve any function half the time also confused people.
In the next version, each card gave the option of playing it as a monster or playing it as a one time effect. This decently addressed the variance problem, ensuring that every card always had a use. However, thinking of every card as two distinct effects increased the complexity of deck construction to a degree I felt unfit for the game.
It was at this point I took a step back from the game and really analyzed the experience these prototypes gave. The variance issue was a clear issue that needed resolving, but even if I did address that, was the rest of the experience what I was aiming to create? One of the things that I felt was the most exciting part of a typical deck construction experience is the moment you execute the overarching strategy your deck was built around in an âexplosiveâ combo of effects. Playing only one card per turn meant that these combos were very drawn out and you would forget about the set-up that got you where you were by the time you got your pay-off. My first thought was âallow players to play multiple cards per turnâ. But how many cards per turn was the right amount? After a bit of mulling over the card count that seemed right, I had this brilliant idea; âHow about all the cards?â
This change would greatly affect the game, so I needed to do some reworks to the game. Depending on your turn order, other players would either have played no cards or all their cards, so cards that affected other playerâs decks or how they played cards wouldnât work well anymore. I could still implement cards that affected other playerâs teams, so long as they waited for every player to play through their deck before activating (Fin abilities). If there is no interaction while playing through the deck, why have turns at all? Simultaneous play!
In prior versions you could cycle through your deck multiple times (the round would only end once a player had the required number of points), but now your round ended as soon as you went through your deck once. This meant you only had one chance to use each card. This really made me see the issue of requiring a monsterâs lower evolution stage to play the later one, so I wanted to make any card playable on its own. I still wanted some basic game mechanism that had players building up to stronger effects. This is the point where I started thinking about the theme of the game. The cards were monsters, but what were you doing to add them to your team? I started thinking of the decisions that went into catching monsters in monster taming games (like Pokemon). In these games you often have the option between capturing the monster you meet or battling them to gain experience. I decided to abstract that concept a bit, giving players the option of either storing the cards they encounter in their âexperienceâ or adding the monster to the team if they had enough cards in their experience.
I created 18 cards and just tested this version myself. Playing through your deck was simple; flip cards until you want to tame a monster you encountered; spend the required resources to add the monster to your team and get its abilities (abilities that trigger when you encounter cards did not exist at this point, so the only way to get abilities from a card was to tame it). Despite the simplicity, the decision of when you spend your resources provided compelling decisions. This immediately seemed like it had significantly more potential than the other versions. As I tested this more myself, I realized that just storing up experience and waiting to tame the highest point monster took away many of the gameâs interesting decisions (and disincentivized monsters that had lower point values but helpful and interesting utility effects). I decided that all of your experience would be discarded when you tamed a monster, preventing you from stockpiling it. This added a nice âpush your luckâ element, where you could just tame monsters when you had enough experience or risk âspendingâ excess experience to tame higher scoring ones. It's probably worth clarifying for people who know the current version of the game; at this time, you could only tame monsters you were currently encountering. If you decided not to tame a monster, it would go to your experience and could only be used as a resource to tame other monsters.
This version was being received well when testing with others, so I began to refine it.
People often ask where the name MonstaTama comes from. While the name was decided on a little later in the process, I was realizing by this time that I was writing âmonsterâ a whole lot on cards, and âmonsterâ was taking up a decent amount of card space. I decided to shorten it to âMonstaâ to save a bit of card space. Other nouns like âTamerâ and âShelterâ later followed this convention.
I removed the elemental types. Types were an artifact of the nonnon versions, and werenât really serving any important purpose in the game anymore.
Gathering information about the order of cards in your deck and rearranging them became a larger part of the game. Decks became âPathsâ and were spread horizontally like they are today to help facilitate this.
As briefly mentioned, from the start, each version of the game had different âBiomesâ of cards, with each Biome having a specific theme or special mechanic associated with it. Each round, players receive cards from a different Biome. This was done to create the same feeling that new set releases give in a CCG. Up until this point, Biomes each had around 15-18 different cards. I tested the game with a friend who I thought, knowing the games we had enjoyed together in the past, would really appreciate the game. To my surprise, they said they felt the game had too much reading involved and asked to wrap up the playtest before finishing the game! I took this feedback very seriously, and pared each Biome down to the closer 9-10 different cards so there were less different cards players would have to read during each play. I also was more cognizant of how many cards players had access to at any one time. Testing various card counts for different parts of the game isnât a particularly interesting story (so Iâm not going to go into detail about it), but I played around a lot with how many cards players were dealt each round and how many cards a Path included.
Trading still felt underutilized (especially after I removed evolution lines that were âforcingâ players to trade). I explored some other methods to make trading more intuitive for players. I provided a central market that provided cards players could freely exchange with. Timing on this was awkward and past snatching a couple of cards when the round first started trading was still mostly ignored. I tried making a turn based trade phase. This was too fiddly and took too much time to resolve. Eventually I decided that trading either wasnât going to be utilized in the game or it was going to be more complex than it was worth, so I decided to just remove it entirely. Players would just use the cards they were dealt.
Before this version, I had only designed a couple of Biomes for each version, just to test a round or two of the game. I fleshed this version out with enough Biomes to play a complete game. Now that I was playing full 3 round games, I had to address players trying to use the same deck every round. I didnât want players just building a strong deck in the first round and using it for the rest of the game. I wanted players to have to go through the deck construction process every round (it was the focus of the game). The first solution was to have âprotected speciesâ. At the end of the round, every player would nominate a Monsta that was on another playerâs team to become a âprotected specieâ, and âprotected speciesâ could no longer be included in decks for the rest of the game. The problem was that newer players often were bad at identifying the Monstas most integral to their opponentâs strategies and would often end up just picking at random. I try to avoid having players make decisions without the information they need to make an informed decision. Additionally, this solution only solved the âyou need to make a new deck each roundâ if players were strategically choosing the protected specie. It also added a political element to the game where players could gang up on one player which clashed with the rest of the gameâs interactive abilities. In the rest of the game, interactive abilities affected all players to avoid these types of political decisions. The next solution was to simply remove all cards that players included in their deck at the end of each round. This was not a popular mechanic among play-testers. I initially chalked this up to âthey think they want more cards to choose from, but they donât realize that means they will end up using less variety of cards as they use the same deck each roundâ, so I stood by my decision to remove all the cards they included in their deck. That was until one of the playtesters (either due to bad luck or misplay) messed up a strategy they were quite excited about and exclaimed âIf I didnât even get to use the Monsta, I shouldnât have to get rid of it!â I realized this was a very good point. I changed the rule to be any monsta on your team at the end of the round gets removed from the game, but you still keep the rest (at this time, points were tracked on a score track instead of a score pile of cards). This caused the unintended consequence of players using utility based monsters less. Since the value of a utility Monsta varied depending on the situation (as opposed to scoring based Monstas that typically provided the player with a consistent amount of points), players would sometimes forgo using a utility monster that would only provide a small amount of utility so they could save it for a future round where it could provide more utility. To counter this, I categorized each card into a âutilityâ and âscoringâ type, and the rule became that only the scoring based Monstas were removed from the game permanently. This adequately addressed using the same deck each round as scoring Monstas were typically what strategies were based around. This split was also used while dealing cards to players, making sure all players got a selection of both scoring and utility Monstas. I still had people complaining about their cards becoming unavailable each round, but I was confident this made for a better game experience compared to players using the exact same deck each round.
Encountering cards still felt more random than I would have liked. You would typically have a few particularly important cards for your strategy and if you didnât have enough experience when you encountered those cards, they had to be added to your experience instead of your team. To alleviate this, the back of each card indicated whether it was a âscoringâ or âutilityâ type Monsta. This meant that so long as all the âscoringâ type Monstas included in your deck were important to your strategy (and you werenât just filling your deck with a bunch of random scoring type Monstas), you always knew where those important cards were, and could plan and use abilities to set up taming those cards, even if you didnât invest into revealing cards in your Path.
Up until this point, I had really only tested the game with a few different groups of friends (and almost exclusively on Tabletop Simulator). Due to the pandemic, I wasnât able to attend playtesting events or conventions (in retrospect, I should have tried to tap into online playtest groups). I knew the game wasnât 100% polished, but felt the game was in a decent spot and wanted to get some people in the industry to give some feedback. I commissioned some illustrations (some of which are still in the game today) and graphic design to mock up a vertical slice of the game (a small piece of the game that would be representative of the final game). I was fairly sure I wanted to self-publish from the start, but marketing really isnât my thing and some publishers offer publishing services to studios with complete games, so I inquired with a few of those. I also reached out to some game specific marketing studios. I got some good reception while doing this, but after some further discussions, it was felt that the game had some underlying problems that needed to be addressed for it to become a success.
This is what the vertical slice looked like!
One criticism that I strongly agreed with, was that players only got to use a third to half of the effects in their deck as the rest would just be sent to the experience to be used as a resource. (Abilities that triggered when you encountered cards were a biome specific mechanic at this point, and were typically negative. You had to tame most Monstas to get their effects.) To a lesser degree, there was still the sticking point of losing the cards you used each round and low player interaction. The biggest concern that others brought up though, was that players receiving random cards each round and the path being shuffled made too much of the game based on chance.
Everyoneâs tolerance for luck impacting a game will be different, but I wasnât entirely convinced the game was as random as people, especially newer players, thought. Regardless, the perception of a high degree of randomness was negatively impacting peopleâs impression of the game, even if the game wasnât as random as people thought.
I experimented with a lot of things at this point to address the concerns. I tried adding the levels of Monstas to the backs of cards, so how much experience playerâs needed to save wasn't a gamble. I tried giving every card an alternative ability it could provide if you didnât add it to your team again (and once again, this adds too much complexity for deck building). I tried giving all players the exact same cards to choose from each round (rather than random), and player specific abilities would drive variance in deck construction. I tried returning to a turn based structure, and having the Monstas be in a shared pool in the middle that players could tame from once they generated enough resources using the cards in their deck (after playing simultaneously for so long, this gameplay felt much too slow). I even tried changing up the theme to robot building, where whenever you added a robot to your team, you would augment it with any cards you used to pay for it (like how Gear works in the game today).
The further I strayed from the version I was trying to improve upon, the less compelling the game seemed to be. I went back to the version I had worked on for almost a year and asked myself, âwhat improvements can I make without changing the core of what I already have designed?â
Adding utility effects to abilities that triggered when you simply encountered a card (Enctr abilities) and making those abilities game wide, rather than exclusive to a specific Biome, was an easy choice. Not only did this mean players would be using more effects of cards they put in their deck, it reduced the âcostâ of utility effects, causing them to be more appealing to use, incentivizing players to build decks that gave them more agency.
I was looking for ways to add more interaction to the game. I went back to the theme of the game to find something that fit. One idea I had was for players to ârendezvousâ at the end of their Journey, interact with each other, then âwalk backâ home (go through their path again, but backwards). This would allow interactive effects to affect playerâs paths. While I was testing this idea myself, I realized that there was a huge decision space as far as whether to tame something during the first or second time through your path (which I did not feel fit what I was trying to do with the game), but once I got accustomed to it, what it was essentially allowing me to do was choose whether I generate experience using Monstas to the left or to the right of the Monstas I was wanting to tame. So I thought, âwhy not let people always do that?â Allow people to store a Monsta they wanted to tame and âpayâ for it with the upcoming cards (as well as previous cards). This was a huge step in making the game feel less random and making sure players were able to play the cards they wanted to play regardless of their skill level. I refined this mechanic into the Vicinity and Sense mechanics that are in the game today.
To address the complaint about losing the cards you used, I decided to frame it differently. Now you have your own personal âSheltaâ where you place all the Monstas you tame. Your score at the end is whatever is in your Shelta. Functionally, this isnât really different from players calculating the points on their team each round and tracking them on a score track, but it feels different when you say you are âscoring those cardsâ rather than ânow that those cards have given you points, they are being removed from the gameâ. I have yet to get a complaint about losing access to cards since I made this change. The score track had an important function though; it gave a sense of how well each player was doing. Now that the score track was gone, I made players count and announce the points on their team each round to set turn order for the next round. What players donât realize is that the important thing here is the âannouncing pointsâ not the âsetting turn orderâ. If I had just told players to announce points, I knew many groups would just forget, or not internalize it, so I tied it to a simple mechanic that would require players to communicate their scores.
Now that players were losing access to their whole team, the distinction between utility and scoring Monstas mattered less. Most utility abilities were now tied to Enctr abilities (meaning that these abilities could be used then discarded so the card would not be lost), so I was less concerned with players forgoing using utility abilities to save them for later. The new draft mechanism (which Iâll touch on in a moment) also helped players âfixâ what they were dealt if they happened to be dealt cards that were lacking in utility or scoring. The game was increasing in complexity with the addition of Enctr abilities, so I decided to cut the Monstasâ classifications to bring the complexity back down again.
To address both the variance and lack of player interaction complaints, I decided to try to incorporate trading again. I knew open trading didnât work, so I tried more direct âtradingâ again. This quickly morphed into more of a draft, but the idea that you give up something of value to acquire something you value more, just like trading, drove the design of this draft. I wonât get into all the details, as that could be a whole write up on its own, and without getting into specifics, it wonât make much sense. I can confirm that Kindomino certainly influenced the draft that made it into the final game.
Part of this rework was making sure cards very rarely felt âuselessâ when you encountered them early on. I wouldnât really call this change to the gameâs design, it was something I would have done if I had decided to stick with the previous version and further develop/polish it. That said, given I was reworking all the cards, this was the time when a lot of cards got âusability fixesâ. On a very basic level, I made the points utility Monstas generated closer to scoring Monstas. The scoring Monstas were still better to score with, but you wouldnât be too far behind if you ended up with only utility Monstas to tame. As a more complex example; prior to the rework, Dragobra would passively give you a resource each time you added a Monsta to your team. This incentivized you to tame as many Monstas as possible, but you needed to find Dragobra near the beginning of the Path for it to be of much use. In the rework I changed it to check how many Monstas are in your discard at the end of the round (which still incentivizes taming them rather than discarding them), so the timing at which you encountered Dragobra wasnât as significant. I was more lenient on effects that were better if they were encountered later in the path, as it gave players the whole Journey to set them up, but I reined in many of those effects as well. Avoiding abilities feeling âuselessâ is the reason you start with a Monsta on your team at the beginning of every Journey. I wanted to make sure that you always had something on your team for effects that cared about Monstas on your team.
A little further down the line, I âcodifiedâ the different things you could do in the Journey Phase into actions. In the prior version, there really was just one action; you encountered things and part of encountering was deciding whether you wanted to tame it. Abilities Monstas on your team gave you were written as passive effects that dictated when you could use them. Now, encountering Monstas and taming them are distinct effects and this caused questions about when passive effects on teams could be used. To help convey all this, I made everything you could do during the journey into an Action and ruled that you canât start using an action until you finish using another. These rules are a little more complex to explain to new players but I felt the better clarity once players were familiar with effects was worth it.
And that, for the most part, brings us to the game that you see and can play today (on Tabletop Simulator or screentop.gg). I am of course glazing over months of testing and iteration all the individual cards and biomes went through, but I feel like those are better suited to have their own write up. There are things about the game that I didnât discuss due to feeling like they were more a part of a particular card/Biomeâs story than the game as a whole (for example the Levelâ counter in the old Dragobraâs ability), or just not a very interesting story to tell (why âreceive wispâ is templated the way it is). That said, if there is anything you are interested in hearing more about, please let me know! I am happy to share what I can about MonstaTama and the process of developing it into what it is today and can go into much deeper detail about many of the things that are discussed above!
Subreddit
Post Details
- Posted
- 1 year ago
- Reddit URL
- View post on reddit.com
- External URL
- reddit.com/r/tabletopgam...