What's 12 + 4?
My guess is that most of you did that pretty instantly and got sixteen, a few pondered briefly wondering what the catch might be, but by now it's probably clear that I'm leading up to some sort of point. Let's try something a little trickier:
What's 12 + 5?
Here's hoping people managed seventeen. An extra point to anyone who figured that 'four' had been changed to 'five' and added one to their previous answer rather than calculating again. I could make an argument that the capacity to perform calculations in this way has impacted board game design, but this is more a question about iteration.
Whats 12 + 6? 12 + 7? 12 + 8? 12 + 9? 12 + 11? 12 + 12? 12 + 13?
I figure that few people will bother with all of those. They're no more demanding than the first question, which I predict that most people answered willingly or even automatically. The point of today's post is that people don't mind wasting a tiny amount of time, but will look for ways to avoid larger tasks that feel unrewarding and that a tiny task repeated several times is perceived as a moderate task rather than several tiny ones.
This is a chart from xkcd which shows (for example) how long it's worth spending in order to make task a second quicker. It's more of a joke about how the engineering mind will put itself through great discomfort for minor improvements than it is any sort of practical guide, but I think it says something worthwhile about game design.
One question that a designer should ask themselves often is "Is there any way that I can put in a large amount of effort now to save everyone who ever plays this game a tiny amount of time." If a game does well it'll be played by many people many times, so even if a task isn't performed too often shaving it down by a second does a lot of good overall. Of course it's important to make sure that the parts being removed aren't parts of the game that you want people to experience - but I started with a simple addition example for a reason. Lots of games involve some amount of calculation but the core experience of the game is rarely about simple arithmetic.
Let's use a couple of editions of Britannia as an example. Board Game Geek tells me that there have been several editions of this game, I've only played two which I'm going to refer to as "The old one" and "The new one". Don't get too hung up on which is which or whether any of the things I say about the old one are just indications that I ate some of the pieces when I was a toddler, it's just to illustrate a point.
In the old edition to expand your population, you counted the number of territories you controlled and for every three you got a new guy. Mountains and other stuff only counted for half. This is a huge improvement on a simulationist approach, where you might calculate how much food you have, the logistics of getting it to where it's going, what proportion of people are likely to have kids, how old they're likely to get, etcetera. An important design decision is to determine the key aspect of the world you want a game to model and pull that out without keeping any of the rest of the junk. As a model of population growth, this approach is simple to calculate and works well.
The new edition only made one change to the process. You get two population points for every field and one for every mountain, it takes six to make a new guy. Human brains are very marginally worse at handling fractions; 1.5 + 2.5 takes us slightly longer than 3 + 5. It's a very simple change and a very small change, but it satisfies the criteria of taking some small amount of development time to make a small task performed many times by many people very slightly smaller. I'm not sure if the change was even undertaken for this reason, it could well be that someone just felt that the half values look ugly, but the reason that we see some numbers as ugly is that they're hard to process. Who ever heard of the physical appearance of a number being a serious aesthetic consideration?
Another example, very quickly, is in counting score. The old edition had players write down points as they scored them, adding them to a running total, requiring a great many small calculations. The new edition gives scoring counters in various denominations and has a single calculation at the end. One could argue that you could add up your score at the end in the older edition, but really it'd be a long form addition consisting of several smaller calculations. The advantage of tokens is that they are easily grouped (and are different sizes to facilitate this) so a calculation can be (25 * 2) + (5 * 3) + (2 * 1) rather than summing an unordered column of digits.
On a personal level I abide a philosophy of not wasting time. I do plenty of things that are unproductive but generally because I want to be unproductive and have something to gain from that. I don't like waiting at train stations so I tend to try to leave so as to arrive at the station with the train, which leads to me sprinting out of the door rather more often than is dignified. I want to apply this to games that I work with, which is why I worry about things like visual search efficiency and watch playtesters to see if they're ever doing admin tasks that I can remove from the game or at least make easier. I don't always feel like I'm winning in this respect, but I wanted to write about it to make the concept stick in my memory during today's playtesting and to encourage folks to call me out on it when prototypes have too much busywork.
Tomorrow I'll introduce the other game I'm working on, until then I hope that reading has been a valuable use of your time and please let me know if I could refine the experience