Sidequest: too long; didn’t write
Welcome again to another Sidequest, which is consequently the first article of 2021 for me. And boy oh boy, after what an absolute shitshow of a year 2020 was, it’s only fair to start off with a Sidequest.
I’ve touched upon a few different topics with the articles I’ve written so far, and as always, there is even more stuff that’s yet to be said. However, most of the time it’s hard to go off on a tangent without derailing the entire article, so this is where this Sidequest comes in: things I’ve wanted to talk about that I don’t have enough to say about to warrant their own article, but I can’t keep my mouth shut about either way. So, without further ado, let us begin:
Randomized Resources
To start this thing off, I’m gonna go with a few thoughts on randomized resources in games. This was prompted by playing Ashes: Rise of the Phoenixborn for the first time, and I can’t say I’m much a fan of the method, though I do understand its merits. In short, Ashes uses dice for its actions. Each dice has 3 different tiers of faces on it, where a face of a higher tier can be used as one of a lower tier (tier 2 can act as tier 1, and tier 3 can be spent as any).
This way—without taking any randomness mitigation effects into account (which Ashes does have)—you have a completely randomized set of resources each time the resource pool refreshes. This forces players to adapt to the resources they currently have, and create strategies that play around the possibility of (not) having a certain resource available at a later point in time. However, constantly reshuffling the available options isn’t the only approach to randomizing resources.
Taking a page out of Magic’s book, one could have the resource cards (lands, in MTG’s case) be distributed randomly in the deck same as the cards that need resources. Now, even though I personally dislike randomized resources—and I’m pretty sure a lot of people would agree with me on the MTG side of things—there’s nothing inherently wrong with the mechanic*. Randomized resources might seem like a mechanic that is more applicable to casual games than to more serious/hardcore/competitive systems, and while there is truth in that, it mostly depends on execution there.
*As long as the game is designed around the mechanic. Just, please, don’t repeat Magic’s mistake with how it handles lands.
An upside of using randomized resources is the fact that it forces the players to constantly adapt to the new set of available resources, and as such can prevent situations where players would either gain an unfair advantage through stockpiling the resources, or where the play pattern created by that would just not be any fun. If the players must make do with what they’ve got until the resources get refreshed, it makes for completely different gameplay situations even given the same board state (assuming that the board state isn’t directly tied to the randomized part of the game).
All in all, randomized resources are better suited to certain types of games than others—usually, in more competitive games, you want to eliminate as much of the randomness as possible so that only the players’ skill affects the game’s outcome. But, even then, it’s a pretty useful tool to have in your arsenal. Just make sure you’re wearing safety gear when you’re using it.
Tracking across turns—paper vs digital
I tend to be pretty vocal about my animosity towards tracking in tabletop games. An article can’t go by without me mentioning how it’s the worst thing ever and how it will ultimately lead to the downfall of humankind as we know it etc. etc. But, being self-aware doesn’t mean that I’m necessarily wrong—necessarily being the operative word here.
To that end, I’d like to bring up an example of where tracking can absolutely shit on the game’s flow, and where it’s better left to the computers, because humans kinda suck at it. Generally, every game has triggered effects. Whether it’s start/end of turn/phase effects, things that happen when a certain action is made or when a certain condition is satisfied, triggers are absolutely unavoidable in games.
Ubiquitous as they are though, there is a bad kind of triggered effect though, which is bad regardless of the medium—delayed triggers. I ranted about these for a few sentences in my article on optimization, and I’m gonna rant about them here for a few sentences more. Basically, humans suck at remembering things that are yet to happen. That’s why we have sticky notes, reminder software, alarm clocks, countdown timers etc. If people were good at that, a pizza cooking in an oven would never turn to charcoal because 10 minutes somehow turned into 37. Long story short, people get distracted very easily. And, in the middle of a game, there are nothing but distractions. Missed triggers happen all the time, and depending on the game, the consequences of those misses can range from minor annoyance to completely breaking the game’s state.
Computers, on the other hand, don’t really forget much. So, in digital games, the only tracking that exists is the stuff the player still has to actively be aware of, which mostly boils down to resources. You don’t have to press a button every 0.3 seconds for the damage-over-time effect to work—we offload that to the software. Because of this, a lot of digital tabletop games (at least digital card games, from my experience) do a lot of things that would just turn into an absolute clusterfuck on paper.
Digital games can do things like persisting an object’s state across zones just fine, or can handle as many triggers as they want without any real tracking required on the player’s end. They also tend to do a lot of stuff with randomness, as determining a random outcome is pretty much trivial in software. As a result of this, I’ve actually seen quite a few people who have more experience with digital games than physical ones try to apply the digital tracking philosophy to physical games. Suffice it to say, it doesn’t usually work that well. Even though it’s technically the same gameplay, the design space changes a lot depending on the ‘weight’ of the tracking in the game.
Remember, unless your target audience are AIs, people still have to do the bookkeeping in physical tabletop games (and there is still plenty in digital ones, too). Less tracking = more playing.
“How to win” at the back of the rulebook
This one’s short and relatively dumb. Don’t do this. When describing a game, you should put the actual objective of the game as one of the first—if not the first—pieces of information that the players encounter. It doesn’t even have to be at the literal back of the rulebook to be bad. Without the extremely important context of what you’re actually supposed to be going for, most of the mechanics will either make little sense or none at all, and if a player has to read the rulebook twice to actually understand the game, it’s pretty much failed at being a rulebook. You’re writing an instruction manual, not a sequel to Inception.
“Tl;dr effect descriptions” or “How to be laconic with rules text”
Ironic title aside, this is a major pet peeve of mine, but it needs to be approached with a bit of caution. See, there is a time and a place for long, flavorful descriptions of things—mostly in RPGs. But, this isn’t about those cases. This is about trying to do the same in a non-RPG card game or board game, though from experience, most of the examples I’ve seen have been from card games.
In my opinion, rules text shouldn’t be flavorful or poetic. This is why a very neat invention called flavor text exists. The key with rules text is to give information about the effect in question. Flavor text, on the other hand, can do things like describe how that effect works in the game’s setting, or what the in-universe outcomes of it are. Most importantly, having one doesn’t mean you can’t have the other. Turning rules text into some pseudo-flavored mess is often just going to make it fail at its most basic job—conveying actual game information to the player.
If I have to work to untangle what something actually does from a 7-line story about the legendary wizard who came up with the spell, I’m still gonna get the info, but come out of it pretty annoyed that I had to put in the extra mental effort. Split that into 1 line of actual, laconic, understandable rules text and 6 lines of the wizard’s autobiography, and you’ve increased the parsability of the effect by a lot. As a neat bonus, the fact that they’re now physically separate in the text box means that the players can just scan the part they want to reread and skip the thing they don’t.
Why ugly prototype visuals are so good
For the last entry, I chose to tl;dw about something I actually like. Let me preach to you now, dear reader, about the glory and wonder of really shitty board game prototype pieces. It’s not necessarily that I prefer the look of them compared to actual realized product—on the contrary, the benefit lies in their horrible appearance. The point here is that it’s just a case of minimizing distractions. If you don’t have anything nice to look at, you’re gonna make damn sure that the game is actually interesting, because otherwise there is zero point to the playtest… at least theoretically.
Not saying you shouldn’t actually work on getting your game to be presentable, but if you’re in the prototype stage—massive emphasis on that—you’d just be wasting time. Prototypes are generally so volatile that mechanics rarely survive the entire playtest, let alone multiple. And, if you spent a couple hours counting pixels so that the font is perfectly aligned and the color palette is just perfect—only for it to be completely irrelevant because that text box no longer exists in the next version, congratulations! You played yourself instead of playing the damn game.
//TODO conclusion. ha!
This is InvertedVertex, signing off.