This is a second little anecdote about game design I absorbed during undergrad, while studying video games, which I think have some crossover consideration with board game design. See the entry “Bonus!“ for the first.
My takeaway from “Bonus!” was that even if you can’t make something work, or there’s a technical hurdle between you and your exact design objective, sometimes a little wallpapering over it with theme or dopamine can make for an even better experience for players.
The story related below is third hand, and so may be apocryphal. If anyone involved in the design choices described ever reads this, please reach out so I can correct my memory and set the record straight here 🙂
When the Quake series of games came out, they were a technical marvel. When the code was open-sourced years later, things were discovered in it that were still considered remarkable at that time. However, for all it brought, “bots” were still an incredibly hard feat to accomplish in first person shooters – there wasn’t a whole lot of “I” in the AI.
The Quake designers wanted to make it appear as if the computer-controlled AI bots were actually communicating with each other in coordinated attacks on player. Which, at this point in game development, was pretty impossible. At least by any standard we’d expect today. True, they were built into the game, thus they had an edge on the player, and could actually read perfect information about each other directly from the game engine. Their algorithms also had access to other shared information about game state, stored in system variables or registers.
But play-testing concluded that having multiple bots attacking the player at once wasn’t particularly fun, because it was just too savage — they’d just come after you en masse and not let up until you were dead. So the developers set a global mutex (short for mutual exclusion lock; i.e., only one resource can use it at a time. Imagine an elementary school hall pass) on the bots: CurrentlyAttackingPlayer
. Any time a bot had it, they would come at the player, assault rifle blazing. If another bot attempted to acquire the lock, but could not (because someone else had it) — it would run around the map at random. The player might encounter them accidentally, but the bot wouldn’t seek to do the player to do damage. So even if there were six or seven bots in a level, only one would be on the offensive at a time. Moreover, a bot which had the lock, had some criteria for when it would give up the lock (allowing another bot to take it, and come after the player). The bot giving up the lock would then flee to run randomly on the map.
As you might imagine, this could have come off with a bit of an artificial feel — why are all these guys just screwing around in the hallways when they could just take me out? Then suddenly the one I’m fighting leaves, and another one always shows up out of nowhere?
The solution the id developers came up with wasn’t to make the bots even smarter, or come up with some other mechanism to make them “go easy on” the player — but a completely superficial change.
Since each bot could have a set of criteria for releasing the mutex, it’s not hard to imagine baking in “below 30% health” being a good reason to give up the mutex (and leave the player alone!). The clever bit… as a bot gave up the mutex, it would cause a clip of audio to play: a voice actor shouting “COVER ME!”, and as the bot gave up the CurrentlyAttackingPlayer
mutex, another would acquire it, and come after the player. The animation of the bot leaving included turning it’s weapon skyward, it appeared to flee… creating the illusion of a coordinated strategy, and of a far higher level of sophistication among the AI units than anyone could have built at the time.
Admittedly, this is a little less applicable to board games than the “Bonus!” anecdote, but that one reminds me of this one and vise versa. Obviously AI is a lot less common in board games, there’s more and more overlap these days (many designers seem to be experimenting with it), whether like XCOM and an actual app, or decks of cards defining non-player heuristics. The common thread is that it needs to work for the player, rather than be perfectly accurate.