Creating the Core Gameplay Mechanic

So far, this course has emphasized the importance of a clear, fun, well-balanced central mechanic in creating casual games. Now it’s time to create it. But perhaps even more importantly, it’s also our chance to follow one of the most important lessons of this entire course—testing our game with real, human users, as early and often as we can.

Our plan for this lesson is simple: keep working on the core mechanic until it tests well with players. Don’t proceed to polish and features until then. Now, to visualize this extremely simple concept, here’s a totally unnecessary flowchart. You’re welcome:

To demonstrate this, I wanted to create a simple but plausibly fun game mechanic that could turn into a complete game if successful, but, on its own, is simple enough to create quickly.

Inspired by a painful memory of a childhood birthday party that I do not want to talk about, I came up with the idea of a mechanic in which the player uses a slingshot to shoot rocks at colorful balloons.

It’s important to be clear that this is isn’t game idea, but a game mechanic idea. And that’s the point—we want to test the core of a potential game, rather than wasting time on the game itself.

Here’s the creation wish that got it started. Note that I’m focused almost entirely on the mechanic itself, with just enough detail to be playable:

So we’re ready to test. Now what?

First, let’s talk about in-person testing. Try to arrange a scenario something like the following:

• Pre-load the game: Hand them the device with the game already open and on the start screen. Do not make them navigate links or menus. (We aren’t testing download times or UI yet, so get the game ready to play.)
• Say nothing: Tell them you’d like to watch them play something, but don’t explain any of what they’re about to experience. Tell them that because this is a test, you can’t answer any questions, but encourage them to think out loud as they play.
• Positioning: Sit next to them, slightly offset. You need a clear view of the screen and their hands, but you need to see them too. Remember, their reaction is at least as important as what’s going on in the game, if not more so.

Next, if you’re doing this via Discord:

• Start screen sharing first: Before anything happens, ask them to share their screen and, if they’re on desktop, share a single browser window with a blank tab. Send the link only after they’ve done this. This ensures you can watch every step from the very start if anything goes wrong or doesn’t load right, you’ll see it.
• Say nothing: Tell them you’d like to watch them play something, but don’t explain any of what they’re about to experience. Tell them that because this is a test, you can’t answer any questions, but encourage them to think out loud as they play.
• Mic on: They won’t be able to type while playing, so it’s important they keep their mic on and share their reactions as vocally as possible.

Whether online or in person, here’s what to look for once testing begins:

• The first impression: What’s their immediate reaction? Do they hesitate (bad), ask you for help (bad), or jump right in and explore (good)?
• Time to fun: Track how long it takes them to figure out what to do. Remember, it’s okay for your players to be confused for a moment or two—what matters is how quickly they become un-confused.
• The Failure Reaction: When they lose, do they immediately try again (good), or do they act as if they’ve finished a chore and wait for you to say something (bad)?
• Unprompted Vocalizations: Even if you’re silent, your tester might talk. Listen for the difference between a frustrated "Oh come on!" (good—they sound invested) and a confused "Wait, what?" (bad—they sound confused).

After two to three sessions, you should have enough information to make an initial decision about your game mechanic. Is it awesome as-is? Does it need improvement? Or should it simply be abandoned?

We recommend organizing your observations into the following three categories:

• Comprehension: How well they understood what the game expected them to do
• Control: How well they carried those actions out
• Engagement: How much they seemed to enjoy the experience

Here’s what to look for when evaluating comprehension:

• What to look for: The time it takes the player to execute their first intentional, meaningful action. Watch/listen for hesitation, random screen mashing, or, if in person, physical signs of confusion (squinting, tilting the head).
• The Conclusion: If the player hesitates for longer than you expect, the objective or the interactive elements are not visually legible.
• Next Step: Adapt. Alter shapes, contrast, or camera angles so the interactable objects stand out. If the mechanic is so complex that visual changes cannot explain it without text, it might be worth abandoning for something simpler.

Here’s how to evaluate you game’s controls:

• What to look for: Mismatches between the player's physical instinct and the game's requirement. Watch for players trying to swipe when a tap is required. Listen for vocalized frustration directed at the game ("Bro I pressed it!", "It didn't jump!").
• The Conclusion: The inputs are unintuitive, the physics parameters (gravity, friction) are incorrect, or the hitboxes are too exact.
• Next Step: Don’t try to argue—the player's physical instinct is always right. Tune the physics variables to match their expectations, expand bounding boxes, or remap the controls to match the gesture they are naturally trying to perform.

Most importantly, here’s how to figure out if they’re having fun in the first place:

• What to look for: The immediate physical and emotional reaction to the first fail state. Do they rapidly tap the screen to try again, suggesting genuine interest, or do they break focus, relax their posture, and hand the device back (or, if testing via Discord, simply stop and wait for you to react)?
• The Conclusion: The core loop either successfully triggers the compulsive "one more try" loop, or the underlying verb is inherently boring and feels like a chore.
• Next Step: If they compulsively restart and blame themselves for failing, you are good to go! Build that game, because you might have a hit on your hands! If they look relieved that the round is over, Abandon the mechanic entirely and start over.

To test Balloon Busters, I asked three of my coworkers here at Astrocade—@olivia, @manvi, and @cap—to test the game over Discord. In addition to taking notes, I also recorded the sessions to show exactly what a productive test session is like. Note that in just a few minutes, each subject played through the mechanic repeatedly, discovering new details each time, and providing me with a ton of useful information.

All in all, I consider the tests a successful validation of the game mechanic. Although I got a lot of great ideas for how to improve it, each player seemed to more or less understand and enjoy it—two requirements for any good game experience—telling me I should feel confident building a full game around it.

So far I’ve tried to be as clear as possible about one thing: refinement, features, and polish should come after you’ve successfully prove that players like your game mechanic through real testing.

But there’s one important exception to this: polish and refinement is necessary when it fundamentally changes the appeal of that central mechanic. For example, a game mechanic that involves firing a bazooka may only “feel right” when there’s a huge recoil that sends the player flying backwards with each shot, adding to the challenge of the game. Likewise, a physically accurate explosion with flying shrapnel and falling debris may also be an essential ingredient in the experience. On the other hand, a level select screen or realistically billowing hair on your main character are likely not required and simply waste time and effort that could be spent validating the mechanic itself.

Here are some examples that will hopefully make it easier to decide which forms of polish are worth including before testing, and which should be saved until after:

Game mechanic type: Launching Rockets

Game mechanic type: Growing vegetables

Game mechanic type: A block-breaking puzzle

Here’s the bottom line when it comes to deciding whether a given refinement is worth including before or after testing:

If a detail feels like it’s part of the reason why the game is fun from one moment to the next, it’s probably worth including before testing. But if it adds to the game’s visual beauty or long-term engagement, it’s likely not.