The Rule of Firsts in Game Testing -- DQ2 Progress Report for June 2021

The first thing you tell a player to do in your game will become the default way they expect to interact with everything, and this pattern repeats fractally through every one of your game's sub-systems

The Rule of Firsts in Game Testing -- DQ2 Progress Report for June 2021

Howdy Defender's Quest fans!

Way back when I was still testing Defender's Quest 1, I encountered a phenomenon I call "The Rule of Firsts," which is:

The first thing you tell a player to do in your game will become the default way they expect to interact with everything, and this pattern repeats fractally through every one of your game's sub-systems
Image CC-BY-SA-3.0 courtesy of Oldbeeg (source)

In DQ1, I learned this by designing the very first tutorial level around the "Lightning" spell – an ability Azra uses to take out enemies directly at the cost of PSI energy. The game is actually all about summoning defenders, which wasn't introduced until the second tutorial level. Lightning is a secondary ability, an intentionally inefficient safeguard meant for when enemies leak past your defenders. By introducing it first I was accidentally teaching players that it was the main thing you're supposed to do. Thus, testers would try to beat every level by zapping enemies until they ran out of PSI and lost. Worst of all, they never realized their mistake! It never occurred to testers who had been primed in this manner that the game was about summoning defenders.

That's how powerful the "Rule of Firsts" is.

There's a few corollaries that naturally follow:

  • Be extremely careful about the first verb you introduce the player to
  • Don't introduce a special-case or secondary mechanic before your primary mechanic
  • Make every item/character/ability's purpose extremely clear the first time you introduce it

For instance, if your game is not fundamentally about combat, but it does have combat, you don't want to introduce combat first lest your players instinctively try to kill everything they come across.

There's even more to it than that, though, because this sort of relationship fractally repeats itself through each of your game's subsystems, as I've been encountering throughout DQ2 testing.

For background, every once in a while I grab a fresh tester or two from our discord, twitter, or email and run them through the latest build of the game for a supervised testing session. This is where they play the game and share their screen with me via Zoom, Google Meet, Discord, etc. I highly recommend this testing method, which is a derivation of the one outlined in Steve Krug's Book Don't Make Me Think. I tell people to play the game, then I shut up and don't help them with anything, leaving them to figure it all out for themselves. This simulates what the experience would be like for someone playing the game in its natural environment, without the designer passing them hints about what to do and what everything is supposed to mean. All I can do with the tester is prod them to self-narrate as much as they can to reveal their internal mental state, being careful to avoid leading questions. Example:

PLAYER: Okay, I want to jump so I'm going to push A, okay that makes me jump – but whoops! My character jumped a second time in mid-air. That surprised me, I didn't expect that.

ME: What did you expect?

PLAYER: I expected to only jump once. I think I pushed A a second time in mid-air, and I would have expected for that to do nothing.

ME: How do you feel about what happened instead?

PLAYER: I like it! It's cool that I can double-jump

I'm allowed to sparingly prod the tester with "What are you thinking?" or "What did you expect?" or "How do you feel about that?" to get them to open up, but I need to avoid, "Okay you see in order to beat this boss what you really have to do is..." or "Have you tried clicking this thing?"

So here's a few practical examples of how testing has exposed some "Rule of Firsts" problems in recent builds, and how I'm addressing them.

Boosting is Really Important

In a Tower Defense / RPG like Defender's Quest, the player has two basic ways to spend their battle money (known as "PSI" in DQ1 and "Juice" in DQ2) — summon additional units for more map coverage, or boost existing units to make them more powerful. Boosting not only gives you better power for your money from boosting units than by summoning new units, it unlocks your characters' more advanced skills.

The importance of boosting is not necessarily obvious to players new to the series or to Tower Defense games in general. Here's a couple extra factors that complicate things in the context of DQ2:

  • DQ2 does not have generic "recruits", instead every character is unique
  • DQ2 has slightly smaller party sizes than DQ1 for comparable points in the game
  • DQ2 has bigger maps than DQ1

All of these subtly push the player – absent any other prior experience or priming – to naturally reach for more map coverage over boosting. And of course, the Rule of Firsts emphasizes this, because you have to summon a unit before you can boost it, so summoning gets introduced before boosting.

This problem isn't new to me and I've been addressing it since DQ1 – the tutorial levels explicitly tell you to boost your first character almost right away, and will let you fail if you don't. However, I recently had a DQ2 tester or two who muddled through the early game and got stuck later because of a puzzling and persistent reluctance to boost their characters. I was puzzled at first since this wasn't a common problem in DQ1, but eventually the tester revealed the root cause during their self-narration: they were assuming boosting was temporary and would run out after X seconds. So instead of investing spare Juice as soon as they had it as a permanent upgrade, they were waiting for "the perfect moment" to purchase what they thought was a fleeting bonus.

In the post-mortem after the session where I was allowed to "spoil" the test and explain everything, the tester explained that they had no idea why they had assumed that boosting was temporary, they just did for some reason. But now that I had found the faulty assumption, all I needed to do was clarify the permanent nature of boosting and not be shy about emphasizing its importance.

I also realized that DQ2 actually has less tutorials about boosting than DQ1. In DQ1 the mechanic is introduced in the first tutorial level, then re-emphasized in the second; in DQ2 the second reminder is left out entirely. Obviously I need to fix this.

As a first step, I'll add a second reminder tutorial in DQ2 and include specific language that makes it clear that boosting is permanent for the life of the defender. Spelling everything out with text is a fine dance though – players won't always read it, so it has to be short, clear, and only appear at the exact moment it's needed; ideally at the exact moment when a player is wondering to themselves how that specific mechanic works.

Another reason this is so important to get right form the start is that confusion about it cascades into confusion about how to use different characters.

What is this Character For?

The one thing DQ2 testing has absolutely driven home is that if I don't make a character's central purpose crystal clear the very first time they are introduced, players will be forever confused about their identity.

A good example of this is the "Bouncer" character class. The Bouncer's purpose is to protect other units by drawing aggression and buying time with crowd control – a classic "tank" type unit. They do this in three ways:

  • Their base attack triggers a "taunt" status on themselves that makes any nearby enemies prefer to attack the Bouncer over all other targets
  • The Bouncer has a high natural defense stat and a lot of HP, so they can take hits
  • The Bouncer's second-level boost ability, "bounce", knocks back a large crowd of enemies

In later levels where you get positively swarmed with overwhelming numbers of enemies, it's absolutely critical to place the Bouncer in a key position that holds back the tide while the rest of your team focuses on dealing damage.

Several testers missed this, however, despite the game putting up the Bouncer's purpose in a fancy introductory screen when you first get them. This isn't the testers' fault so much as human nature, because you just can't tell people anything. You need to show them.

I must therefore design that character's introductory level in such a way that:

  • The player is naturally guided to use the character in a way that obviously reveals their purpose
  • Using them properly is the only way to beat the level

This is easier said than done, because in Defender's Quest each character has a series of stacked skills:

"Bounce" here requires the defender to be boosted to Boost level 2. So now you see my problem – if a player doesn't understand that boosting is a thing you can feel comfortably doing right away, it's entirely possible to judge a character entirely by their boost-level-one skill alone, the only attack that's available as soon as you place them on the map.

The naive solution is just to make sure that every defender's initial skill is as "central" to their purpose as possible, and I've certainly tried to do that where possible, but there's some situations where you really need to move a powerful attack to boost level 2. Another naive solution would be to have everyone start with two unlocked skills, but that causes other problems. I'm in the fortunate position to be able to look back at Defender's Quest 1's success to know that the basic boost system works, I just have to make sure people know to use it. In tests where users figure out that boosting is important, they get the identity of a character pretty quickly.

So the lesson I learned from this is:

  • Emphasize boosting in general
  • The introductory level for a character should make it impossible to beat without understanding a character's purpose

This brings me back to the Rule of Firsts. The problem with the Bouncer's introductory stage is that it's more than possible to muddle through it without truly understanding what makes the Bouncer special.

Well, can't I just rig the level so unless you do exactly what I want, you'll lose? Well, sorta, but that's confounded by the fact that by the time you get the Bouncer, I've already introduced another character, the Long Shot, a powerful ranged unit. By throwing the Long Shot into the mix, a player has a lot more room to "cheese" through.

I also noticed that a few testers were unsure of what the difference between the Zerk and the Bouncer were, some mistakenly believing that the Bouncer dealt more damage!

And this is the point where I realized the fundamental mistake at the root of all these different confusions, tied back into the lessons from the Rule of Firsts – I'm introducing characters in the wrong order.

Fixing Character Introductions

Here's the current order I introduce white hat units in:

  1. Zerk (a short-ranged, high-damage melee unit)
  2. Long Shot (a long-ranged, high-damage ranged unit that does more damage at long range)
  3. Bouncer (a short-ranged tank + crowd control unit)

Zerk is very easy to understand. You place them, they attack stuff. Boosting them unlocks an additional attack so they attack faster and harder, but it's not a different kind of attack.

Long Shot is also very easy to understand. You place them and can see that they have a special range giving you a bonus for hitting targets at distance. Boosting them unlocks a more powerful attack, but it doesn't behave fundamentally differently.

Bouncer is tricky to understand. You place them and they seem a lot like Zerk. Their base attack is a single-target strike that causes some little speech bubble with an icon to appear next to the Bouncer. Boosting them causes them to perform a dramatic attack that hurls enemies backwards, but if you don't boost Bouncer you won't see this.

The best way to make Bouncer's identity and purpose crystal clear is to introduce them in a controlled level where you don't have the Long Shot, and where it's easier to contrast them specifically with the Zerk.

This isn't in the current build yet, but it's the next thing I'll be working on. My new plan is to swap the Long Shot and Bouncer introductions. This will become a natural place to first introduce attacker enemies and showcase how the Bouncer can be used to protect other units by soaking up the damage. Later in that level a rush of incoming enemies will try to overwhelm the player, and that's a natural point to prompt the player to boost the Bouncer (if they haven't already) and demonstrate their ability to hold back a tide of enemies. Meanwhile, the Zerk will deal the majority of the damage.

This brings me to my next problem – feedback.

Clarity & Feedback

Tower Defense games naturally suffer from degenerating into a chaotic soup of clashing enemies and defending units. Good tower defense games make it easy to "scan" what's going on at a glance, but this still relies on the player being carefully trained at each stage of complexity what kinds of things are even happening in the first place. If the player doesn't have a solid mental model of what's going on , no amount of highlighting stuff with shiny callouts and obvious sound effects is going to work.

Once a player knows about a certain mechanic they can take it for granted and let the game play itself out, but if they don't know that e.g. their players can be attacked by enemies at all, they'll be surprised when all of their defenders are suddenly missing.

This leads me to believe we need to do better callouts the first time any noteworthy interaction happens in the game. For instance, one of the features that has met with universal appreciation from testers is the "spotlight callouts" that pause momentarily whenever a new enemy type first appears. The enemy's icon scales up, takes center stage, and points out what this new enemy is about:

All of these little introductions will eventually be collected in a "Bestiary" that the player can consult any time. This seems to turn the mere act of facing a new enemy into a miniature reward in and of itself.

I'm thinking of doing the same thing for new interactions. Things that are important to note the very first time they happen so they don't get lost in the soup. Here's a proposed mockup:

These interaction notices, perfectly timed for relevance, should help give the player the knowledge of how the game works so that when they return to more "soup-y" play they naturally understand it and know what to look out for. These notices will also be collected in the "Bestiary" (or whatever I finally call it), and this will be a subtle hint to the player to try to discover more interactions. For instance, if you freeze an enemy, after freezing they'll become wet, and if you electrocute a wet enemy after that you'll do extra damage. I'll need to strike the right balance of what things are worth calling out  – freezing turning into wet for instance probably doesn't merit a notice, but igniting an enemy drenched in oil with fire probably does.

The main reason behind this is that I find time and time again that what really matters to the player is evidence that their choice did something. We try to do that in big and in small ways. Electrical attacks cause the enemy to have a cartoony "zap" animation frame where their skeleton appears in white over a black silhouette. Frozen enemies halt and appear light blue. Knocked back enemies fly backwards through the air. This combined with a specific callout notice the very first time you do something cool should help drive home what the tools available to you are, and what specific threats enemies pose.

(And yes, in longtime Defender's Quest tradition, we'll have options that let you suppress and skip these notices entirely for the portion of people who already know everything already and just find this stuff annoying.)

So that's what I've been mostly working on this past month. There's been other tweaks under the hood, but I figured this kind of look behind the curtains of how my design process works might be a little more interesting to folks than a dry list of updates.