What Can the Player Actually Do

I remember sitting in a cramped dorm room at 3:00 AM, staring at a combat prototype that was technically “perfect.” The math was flawless, the frame data was tight, and the hitboxes were precise, but playing it felt like filling out tax forms. I had spent weeks obsessing over damage scaling when I should have been obsessing over the actual movement. Most tutorials on how to design player verbs treat them like math problems to be solved, but that’s a lie. A verb isn’t a variable in an equation; it’s the specific way you ask a human being to spend their limited time on earth. If your “attack” command is just a rhythmic tap to clear a progress bar, you haven’t designed a mechanic—you’ve designed a chore.

I’m not here to give you a lecture on high-level theory or academic game design jargon. I’m going to tell you what happens when you get it wrong, because I’ve spent the last three years building a solo project and breaking my own heart with bad design decisions. We’re going to look at how to design player verbs by focusing on the tension they create and the choices they force. I want to show you how to stop writing boring sentences and start building actions that actually make people want to stay.

Why Your Gameplay Loop Design Is Lying to the Player

The problem is that most developers mistake a sequence of actions for a gameplay loop. You might think you’ve built a loop because the player kills a mob, gets gold, and buys a better sword, but if that entire cycle is just a way to mask a lack of actual player agency and interaction, you aren’t designing a game—you’re designing a treadmill. When your core mechanics development focuses entirely on the “reward” part of the loop and ignores the “doing” part, you are lying to the player. You’re telling them that the action itself is worthless and that the only reason to engage is to reach the next dopamine hit from a loot drop.

This is where the distinction between verbs vs mechanics in game design becomes vital. A mechanic is a rule; a verb is what the player actually does with that rule. If your loop is “Kill $rightarrow$ Loot $rightarrow$ Upgrade,” but the “Kill” part is just a mindless click-fest, your loop is a lie. You’ve promised an adventure, but you’ve delivered a chore. You aren’t providing meaningful player choices; you’re just asking them to sign a contract that says, “I will trade my time for these digital numbers.”

The High Cost of Hollow Core Mechanics Development

The problem with rushing through core mechanics development is that you end up building a house on a foundation of sand. When I was first trying to solo-dev my current project, I thought I could just “add features” to make it fun. I thought if I added a crafting system, a mounting system, and a skill tree, the game would suddenly have depth. It didn’t. It just had more chores. I was mistake-making in real-time: I was confusing mechanics with verbs. A mechanic is just a rule, but a verb is what the player actually does to feel like they are playing.

If your verbs are hollow—meaning they don’t actually lead to meaningful player choices—then every other system you build is just dead weight. You might have a complex economy or a massive map, but if the primary way a player interacts with that world is “click monster to make number go down,” you haven’t built a game; you’ve built a spreadsheet with combat animations. You’re essentially asking the player to invest hours into a loop that offers zero genuine agency. That’s a debt you can’t just patch away later.

Stop writing chores: 5 ways to make your verbs actually mean something

• Every verb needs a meaningful trade-off. If “attacking” is the only thing a player does to progress, you haven’t designed a combat system; you’ve designed a clicking simulator. A good verb forces a choice—do I spend my stamina to dodge, or do I spend it to strike? If there’s no cost to the action, the action has no weight.
• Watch out for “phantom verbs.” These are the actions you think you’ve given players, like “exploring” or “socializing,” but which are actually just side effects of moving from Point A to Point B. If a player can’t meaningfully interact with the world through that verb, you haven’t given them a tool; you’ve just given them a walking animation.
• Design for the friction, not just the flow. Developers get obsessed with making everything “smooth,” but smooth can easily become mindless. A little bit of resistance—a cooldown, a resource constraint, a tactical repositioning—is what turns a mindless loop into a conscious decision. You want players thinking, not just reacting.
• Check what your verbs are competing with. If your “crafting” verb takes thirty seconds of menu navigation, it isn’t competing with the “combat” verb; it’s competing with the player’s desire to go check Discord or grab a snack. If the verb is less engaging than a quick trip to the kitchen, your loop is broken.
• Stop using “grind” as a verb. In most bad designs, “grind” is what happens when the only way to use a verb is to repeat it until a number goes up. If your players are performing a verb just to satisfy a progress bar rather than to interact with a system, you’re not designing gameplay; you’re designing a job.

Stop Writing Bad Sentences

At the end of the day, designing player verbs isn’t about adding more buttons to a controller or more icons to a hotbar. It’s about realizing that every time you ask a player to perform an action, you are making a claim about what is valuable in your world. If your core loop is just a series of repetitive, hollow clicks, you aren’t building a game; you’re just imposing a tax on your players’ time. You have to look at your mechanics and ask if they are actually saying something meaningful, or if they are just filler used to mask a lack of direction. If your verbs don’t force a choice, they aren’t really verbs—they’re just mechanical noise.

I know how easy it is to get lost in the weeds of math and spreadsheets, trying to balance a system that feels fundamentally empty. I’ve spent many late nights staring at my own broken code, realizing I had accidentally designed a “grind” instead of a “challenge.” But that’s where the real work begins. When you start treating your mechanics as a form of communication, your design changes. You stop trying to trick players into staying longer and start giving them actual reasons to care. Build something that says something worth reading.

Frequently Asked Questions

If every verb is a sentence, how do I know when I've accidentally written a run-on sentence that just confuses the player?

You know you’ve written a run-on when the player stops asking “What should I do next?” and starts asking “What am I even doing?” If your combat mechanic requires a dodge, but that dodge is tied to a stamina bar that’s also used for sprinting, and sprinting is required to reach the next quest marker, you haven’t designed a loop—you’ve written a paragraph that never ends. If the player feels exhausted rather than engaged, your sentence is too long.

How do you balance a verb that feels good in a vacuum but completely breaks the economy or the social loop once players actually start spamming it?

You’re describing the “God-Verb” trap. It feels great in a sandbox because the feedback loop is tight, but in a live environment, that verb becomes a job. If a mechanic is too efficient, it stops competing with other systems and starts cannibalizing them. You haven’t just designed a fun skill; you’ve accidentally written a sentence that says, “Ignore everything else in my game and just do this one thing.” You have to introduce friction that scales with efficiency.

At what point does "adding more depth" to a verb just become "adding more friction" that players will eventually resent?

It’s the moment the mechanic stops being a choice and starts being a chore. Depth is when a verb offers different meaningful outcomes based on player skill or setup—like choosing which cooldown to burn in a rotation. Friction is when you just add more steps to reach the same result, like a sub-menu or a way to fail through bad RNG. If the player is thinking about the interface instead of the impact, you haven’t added depth; you’ve just added tax.