top of page

Get emailed new posts

I’ve decided on some of the themes for this card game. I think the players will be craftsmen who create different art, homes, weapons, and technology, and they’ll be selling them to different kinds of people. The placards will be Buyers who want to purchase things from your store, and your score is how much money you’ve collected. The countdown cards will be Events that periodically happen, that everyone attends. I don’t think these are the most creative themes of all time, but I think they get the job done. I still haven’t figured out a name for the game yet though, or a logo. 


As for coding, the main gameplay is done, and now it’s just designing the cards. I’ve gotten a lot done actually, I have 27 Buyers and 12 Events. I’m planning on having 40 Buyers and 20 Events, which means I have 21 cards left to design. A lot of the Buyers of course are copied over from the original Antiquitus, although many of them didn’t make it. As for Events, they want to be things that you have to plan and prepare for to get the maximum reward, although I think I’ll allow a few to just be free bonuses. There are some obvious tricks to making more cards, such as making easier or harder variations of existing cards, or making cards that intentionally combo with another card. Now considering the cards I have left to make, and giving them names and art, and other things to do, I don’t think I’ll be able to release the game next week, but hopefully 2 weeks from now.


From designing cards (and writing the rulebook), I have discovered tricky rules that I had to figure out. There are a few rules that I think are intuitive enough to not really affect too many cards. The 1st rule is: if you try to upgrade a token up to level 7, you fail and the token stays at level 6. I think this will mostly be fine for regular players, as your grid is clearly capped at 6 levels, and then no one will try to do it. The 2nd rule is: if you try to create a token at level 7 or higher, you instead create one at level 6. This is a little bit less intuitive, since I think some people may think that creating a level 7 is impossible and then you get nothing. The 3rd rule is: if you’re told to create a token at level 0, you fail and you don’t create any tokens. This I think will also be ok, as there’s no space for level 0, although it’s possible that some cards need reminder text that you can’t create tokens at level 0. 


But the hardest question is, what happens if you downgrade a token that’s at level 1? I think the most intuitive options for most people are: either the token is removed, or you fail to downgrade and the token stays at level 1. I don’t want “lose a token” and “downgrade a token” to mean the same thing (I want different Events to play differently from each other), which means ideally it’s the second ruling. But I worry that if “downgrading a level 1 means you fail” will read as “you can choose to downgrade level 1 token, fail, and cheat the card.” Which means the ideal ruling, gameplay-wise, is: “you can’t even choose to downgrade a level 1, you must choose something else.” And I think this should also apply to upgrading too (you cannot choose a level 6 token and fail to upgrade it). The bad part is, this feels like one of those sneaky rules. Good game design wants to minimize these kinds of rules, as they’re very hard for anyone to figure out on their own, and they’re also hard to remember (even if you read the rulebook). And this ruling directly contradicts games like Dominion, where you’re allowed to choose to do something even if you know that you’ll fail it. 


However, there is a way to avoid all of this. When a card tells you to downgrade, it explicitly tells you that you have to downgrade a token that’s level 2 or higher. Now there’s no way to downgrade a level 1. I don’t think there’s a way to avoid the upgrading 6 situation, since on your turn you always upgrade a token. But given how rare it is to want to fail to upgrade something, I may not need to do anything about this. A rule being mildly annoying on a rare occasion is way better than a rule that’s confusing most of the time.

Last time I tried to figure out a mechanic that fit all these requirements: they had to be cards that trigger at different times during the game; they shouldn’t be too difficult to remember; ideally have player interaction built into it. I also decided to add a new constraint to that list: the game mechanic has to also work in single player. This is because online multiplayer games are harder to playtest/show off than single player games, and if a game can work in single player mode, it should be able to. This is why Donald X. took steps to let Moon Colony Bloodbath be played in single player, because it wasn’t hard to do for that game. The tricky part is, I still want this game to have player interaction in multiplayer, and there’s very little overlap for “has player interaction” and “works in solitaire”. Like for Territorial March, the mechanic of controlling areas doesn’t make sense in single player, because the game is about having more troops and scouts in an area than each other player.


Then I realized the perfect mechanic for it. Long ago I was inspired by the hourglass zones in Temporum: Alternate Realities. They start with 1 counter per player; when you visit that zone you remove 1 counter from it, and when all counters are removed, you add them back and the zone does something for all players. The idea is that players have to plan for it to happen, and the bonuses are tied to requirements (like having money to pay, or having no cards in hand). I had always wanted to make a game with that mechanic, where there are countdown cards associated with each action. It works great in this game, where the “actions” are choosing a token to add/advance. The mechanic also has player interaction for multiplayer and works just fine in single player too. Another thing is that this mechanic works best if you will want to use the actions in equal amounts, and this game is perfect since you will want all the tokens. It just solves every problem perfectly. 


The countdown mechanic has a few finer details to work out. The first is, how strong should the countdown cards themselves be, and how strong should your regular turns be? Since the countdown cards affect everyone, and take time before they happen, they can be as strong as they want. Putting power into the countdown cards means that the turns should have less power, because 1) to make the countdown cards stand out more, and 2) if the turns were equally powerful then the game goes too quickly. But I also don’t want progress to feel too slow (especially since it can take a while before a countdown card ever triggers). To speed the game up, you now do twice as much on your turns: you choose a token type, then add a token of that type, then advance a token of that type (could be the one you just added, or a different one), then you may submit tokens and placards. Doing the math: if adding + advancing a token equals 1 VP, and a countdown card effect is 2 VP, and on average 1 countdown card will activate once every 2 turns, that means the game takes 10 turns to reach 20 VP, which seems like a good length.


Another thing is how to have these countdown cards not feel extraneous. Technically you could play the game without any countdown cards, but that game would be boring, as there’s no player interaction and much less planning. I also had the problem of, when/how do players get more placards? I solved both issues by having it so, when a countdown card triggers, everyone also draws 2 placards, and this is (mostly) the only way to ever get placards. The only issue is that it may be hard to remember to draw the 2 placards (as the countdown cards themselves draw your attention the most), but I think I’ll just let that be (plus I’m making a computer game). 


Other minor notes: I found several optimizations for coding online multiplayer games (some out of necessity due to making a game that isn’t strictly a 2-player game), and along the way found some bugs I had to go back and fix in Swords vs Shields. I also renamed the tokens to fit the advancing theme. They are now: art, homes, weapons, tech. It’s possible that weapons want to instead be tools, but upgrading your weapons is a very recognizable thing in games. Finding an icon to represent "art: was hard, since there are many forms of art, but my temporary placeholder icon is a painting palette. I also have to give a theme to the placards and countdown cards (“placard” in particular is an outdated term).

After some more thinking, I’ve ended up with a game that’s much different than the original Antiquitus. There are still some issues to work out, but I like the general idea a lot, so I’ve started programming it. 


Instead of taking tiles at random from the excavation site, you now have a grid. There are 4 rows for coins/bones/weapons/texts, and 6 columns for values 1-6. During your turn, you choose to either: add (any) token of value 1 to your grid (i.e. column 1); or increase the value of 1 of your tokens (i.e. move it to the next column). Then you get the chance to submit tokens and placards, except that you’re required to submit a minimum of 2 placards at once (to force you to juggle multiple placard rules at once). And of course the placards will require you to get tokens of multiple suits and values. I like this a lot because it gives you full control over what tokens you want, and it makes the different values actually mean something, as placards that want higher values will be worth more points. I also like that the different types of tokens don’t trigger things when you get them, since those were easy to forget in the original game. 


That being said, there are still some gameplay issues for me to work out. A major one is how to add extra cards that shake up the game and give it variety. The first possibility is that there can be cards that sit out on the table and tell you what changes in this game. This allows the cards to change basically anything in the game. The second possibility is through a progress deck like in Moon Colony Bloodbath, where there are cards that let you take a turn, as well as some twist cards that get shuffled in at the start. At first I heavily favored the progress deck because there’s nothing to memorize or forget (which is very easy to do if you just have cards sitting on the table, far away from you). The thing about MCB though is that cards are constantly being added into the progress deck, while in this game I don’t think there will be. But then that means creating and shuffling the progress deck may feel like it’s not doing enough to be worth it.


There are a couple solutions to this (other than not using a progress deck). One is I could tie the end of the game to shuffling the progress deck. Right now the current end condition is when someone reaches a certain number of points, but it could very easily switch over to: after 4 shuffles, the game ends. One thing is, after the last card in shuffle 4, there has to be one last chance to submit things, because I don’t want it to be possible where cards let you add/advance tokens, but it’s all pointless because there are no more chances to get points. Another idea is something I mentioned months ago: players draw a twist that they’ll add into the deck at some point, and there are multiple twist decks. That could also work, but is a lot more complicated. 


Other issues. How and when do players draw more placards during the game? Antiquitus tied it to taking Coins, but this game doesn’t have that option. The progress deck can start with cards that let you draw more placards. But if I’m not having a progress deck, then I’m not sure what the solution is here. Another thing is, none of these solutions have any interaction between players, which I still want. Finally is flavor, since the game is no longer about digging up artifacts and is now about upgrading tokens, which means the history theme and the 4 tokens probably have to change. Which is good for me, because I’m not knowledgeable enough at history to be able to give the placards more names (my teammates came up with most of those names).

bottom of page