Octalysis Game Techniques: Why Most Designers Use Them Wrong

Walk into almost any gamification consulting pitch and watch what happens in the first ten minutes. Someone names the engagement problem. Someone else opens a slide deck. And then, almost without fail, the deck cycles through a list of Octalysis game techniques like a restaurant menu. Points. Badges. Leaderboards. Magnetic Cap. Group Quest. “Let’s add three of these and ship it.”

I’ve sat through that conversation maybe four hundred times. Sometimes I’m the one being pitched. Sometimes I’m a silent observer in the room. Almost every time I want to stop the meeting and ask the same question: who told you Game Techniques were where the design starts?

Because they’re not. They come out of design, downstream of the upstream thinking, never as a substitute for it. And if you don’t understand the meta-framework behind how Game Techniques actually come into existence, why some have playful names like “Magnetic Cap” instead of “quantity-limited action constraint,” and why the GT list functions as a reference library rather than a shopping cart, your gamification work will keep flatlining no matter how many techniques you stack into it.

This post is the methodology behind all 150+ Octalysis Game Techniques. Not what each one does individually. How they get born, what makes them worth naming, and the specific way they’re supposed to fit into the Octalysis design flow.

Speed Run Notes

• A Game Technique is a labeled pattern, full stop. Not a building block, not an ingredient, not an item on a shopping list. The bar to qualify is practical: you noticed it works, you saw it shift behavior, and a name lets your team talk about it without re-explaining every time.
• The naming convention itself is a design decision. Vivid names like Magnetic Cap and Torture Break stick in your team’s vocabulary; sterile labels like “quantity-based behavioral ceiling” never make it past the slide they’re written on.
• The single most damaging habit in the gamification industry is reaching for the GT list before doing the upstream thinking. It produces designs that feel assembled from parts rather than grown from a coherent picture of the user.
• The correct flow runs Strategy Dashboard → independent brainstorm → cross-reference the GT library, in that order. The list exists to sharpen ideas you already have, not to manufacture ones you don’t.
• Magnetic Cap and Torture Break both pull from Core Drive 6 (CD6): Scarcity & Impatience. They feel like the same idea until you see them named separately, and once you do, you can’t un-see how different they actually are. Precise naming is what creates precise thinking.
• If a useful pattern in your design isn’t on the GT list, that doesn’t make it invalid. The list is a vocabulary, not a certification. Many of the best mechanics in shipped products never get an official number.

About the Author

Yu-kai Chou is an S-Tier Behavioral Designer and the creator of the Octalysis Framework, the gamification design system now applied to products and experiences reaching over 1.5 billion users. His book Actionable Gamification is one of the most-cited works in the field, and he has been ranked the #1 Gamification Guru in the World.

He has advised MrBeast, LEGO, Microsoft, Porsche, Tesla, Stanford, Harvard, and governments including Ukraine on turning behavioral psychology into product mechanics that actually change user behavior.

Verify: Wikipedia · Google Scholar · Wikidata · LinkedIn

I’m the one writing this because I personally named most of the Octalysis Game Techniques you’ve heard of, and I’ve spent the better part of over two decades watching people misuse them in ways that hurt their products. Magnetic Cap, Torture Break, Group Quest, Hunter’s Mark, Desert Oasis, Glowing Choice: those names came out of my notebook and into the framework because I needed a way to point at things I kept seeing across audits. The post you’re reading is the meta-layer behind every Octalysis certification I’ve ever taught, every Strategy Dashboard I’ve run with a client team, and every certificate submission I’ve graded. The pattern of misuse is so consistent that I now recognize it before the slide deck even loads.

What Actually Counts as a Game Technique

The honest answer is that a Game Technique is a labeled pattern. That’s it. The bar I apply when I’m deciding whether something deserves a name on the GT list is practical, not academic.

Three things have to be true. The pattern has to recur across multiple successful implementations, so I’m not naming a one-off accident. It has to demonstrably shift behavior, so I’m not naming a cosmetic flourish. And it has to be communicable, meaning that giving it a name lets two designers talk about the concept without re-explaining it from scratch every time. If those three boxes check, I want to put a tab on it so I can remember it later.

Notice what’s not on that list. Academic novelty isn’t required. A GT can be a brand-new variation on something that’s existed since arcade games. Many of the techniques numbered above 100 in the Octalysis library are exactly that: foundational mechanics with an extra dimension layered on top. The Magnetic Cap GT, for example, is essentially a usage limit from Core Drive 6 (CD6): Scarcity & Impatience with aspiration-pull dynamics from Core Drive 2 (CD2): Development & Accomplishment layered on top. The cap behaves like a magnet rather than a ceiling, and that second-order effect is what distinguishes it from a vanilla quota.

Equally important is the flip side, and people miss it constantly. Not every useful pattern in your design needs to be an official GT. Even if a mechanic isn’t on the list, it could still be a great idea. A “Mystery Quest” inside a banking app, where surprise missions appear at random intervals tied to a user’s spending behavior, might work brilliantly without ever needing a number. The GT list is a communication tool. It is not a certification of design legitimacy.

I push on this point because I see practitioners get stuck waiting for permission. They have a working design idea, and instead of shipping it, they pause to ask whether it counts as a “real” GT. The answer is that the framework doesn’t grant or deny legitimacy. The user’s behavior does. If your unnamed mechanic moves the desired action, you don’t need the framework’s blessing. You just need to keep an eye on it across enough experiences that you notice the pattern, at which point you may decide it deserves its own tab.

The Naming Philosophy: Why “Magnetic Cap” Beats the Academic Label

The naming convention inside Octalysis is itself a design decision. I picked vivid names on purpose. “Names that are fun make you feel happy. If they’re all very scientific terms, sometimes it feels a little bit dry.”

That sounds like a stylistic preference. It isn’t. It’s the framework practicing what it preaches: the naming convention is itself an application of Core Drive 3 (CD3): Empowerment of Creativity & Feedback. A playful name turns vocabulary into a small piece of cognitive sugar, which lowers the friction of bringing the concept up in conversation. “Torture Break” is more memorable than “Time-Gated Action Cooldown.” “Hunter’s Mark” is stickier than “Pre-Commitment Selection Mechanic.”

The names do three jobs at once.

The first is memory anchoring. After you hear “Magnetic Cap” once, you remember it. After you hear “quantity-based behavioral ceiling” once, you’ll forget it before the next meeting. Vivid imagery sticks to neurons in a way that academic language doesn’t, and a vocabulary item you can’t recall during a design conversation is functionally the same as a vocabulary item you don’t have.

The second is discussion fuel. Compare the meeting friction of “what if we added a Torture Break here?” against “what if we implemented a time-gated action cooldown?” The playful name lets a junior designer raise the idea without sounding like a textbook. The academic label suggests you’d better know exactly what you’re talking about before you open your mouth, which means most of the time you don’t open your mouth.

The third is framework evangelism. Distinctive names make Octalysis GTs quotable on social media, in conference talks, and in product retrospectives. When someone mentions the Hunter’s Mark pattern in a Discord channel, the name is sticky enough to spread on its own. The framework propagates because the vocabulary is propagatable. A scientific taxonomy with 150 items would have died on the slide it was first presented on.

This is why I don’t apologize for the silly names. They’re carrying load.

The #1 Mistake: Starting with the GT List

Here is the sentence I have written in client review documents more often than any other: good design does not come from starting with GTs. And yet starting with GTs is what almost every gamification practitioner does on their first three projects.

The wrong approach looks like this. The team identifies an engagement problem. Then someone says, “let’s check the GT list.” Then GT #7, #13, and #18 get pulled out, slapped onto the wireframe, and called a design. The deliverable looks impressive because it has named techniques in it, but the actual user experience is a Frankenstein of patterns that don’t share a coherent motivational story.

The right approach inverts the order completely.

You begin with the Strategy Dashboard, which forces you to nail down Business Metrics, Players, Desired Actions, Feedback Mechanics, and Rewards in that exact sequence. The order matters because each step constrains the next. You can’t define good Desired Actions until you know the Players. You can’t pick the right Feedback Mechanics until you know what Desired Actions you’re trying to reinforce. Skipping ahead to Rewards before you’ve done the first three steps is how you end up with engagement systems that hit the wrong metric on the wrong segment.

Once the Strategy Dashboard is done, you identify the specific motivational gaps and the phase-based needs of the user journey. You ask: at this exact moment in the experience, what does the user need to feel? Not “what GT could go here,” but “what feeling does this phase require, and what kind of mechanic would create that feeling?”

Now you brainstorm. Wide open. No GT list in sight. Your job at this stage is to let your mind expand to all possible design ideas without the artificial constraint of an existing taxonomy. Some of what you generate will be terrible. Some of it will be brilliant in ways the GT list never anticipated.

Only then do you reach for the library. You cross-reference your brainstormed ideas against the existing GTs to see if proven patterns can sharpen, replace, or combine with what you came up with. Sometimes the GT list will tell you that the thing you invented already has a name, and using the named version connects you to a body of design wisdom about it. Sometimes the GT list will tell you that your unnamed idea is actually new, in which case the framework just got a little richer.

Starting with GTs produces designs that feel assembled from spare parts. Designs grown out of the Strategy Dashboard feel coherent because every part shares a common motivational story, which is why I keep insisting on that upstream order even when the GT library is right there in front of you.

How to Actually Use the GT Library (the Carlos Method)

The best practice for actually working with the GT list comes from the way our consultants run client engagements. Carlos Tan, one of the senior trainers in the Octalysis Group, codified it into something we now teach explicitly.

Step one: define the desired Octalysis feelings and Core Drive priorities for each phase of the user journey. These come out of the Strategy Dashboard. You should be able to write a sentence per phase that says something like, “in the Onboarding phase, we want the user to feel curious and capable, with heavy emphasis on CD3 and CD7 (Unpredictability & Curiosity), while minimizing CD8 (Loss & Avoidance).”

Step two: open the full GT list, all 130 to 150 entries depending on which version of the framework you’re working from, and walk through it one technique at a time as a team.

Step three: for each GT, ask two questions. Should we use this in any phase of our design? And if so, does it fit the Core Drive priorities we already declared?

If your design wants to minimize Core Drive 8 (CD8): Loss & Avoidance, you skip every CD8-heavy technique without further discussion. If you want to maximize Core Drive 5 (CD5): Social Influence & Relatedness in a particular phase, the social GTs get extra time on the table.

This is the correct relationship between designer and library. The Strategy Dashboard tells you what motivation to create. Your GT list then suggests proven mechanics that create it. Either way, the library functions as discussion fuel and inspiration rather than a checklist to be completed in order.

What I love about the Carlos method is that it forces every team member to engage with the full breadth of the framework instead of pattern-matching on the half-dozen GTs they happen to remember. Most designers I meet have a personal favorites bench: maybe five techniques they reach for in every project. Walking the full list as a team breaks that habit, and the conversations that happen around the unfamiliar GTs are usually where the design’s most interesting moves come from.

The Certificate Anti-Pattern: Naming a GT Without Describing It

The most common mistake I see in Octalysis certification submissions reveals the same structural error in a different costume. Submitters list GT names under each Core Drive heading and consider the analysis complete.

The wrong version of this looks like a tidy bullet list. “Core Drive 5: Group Quest. Core Drive 5: Social Church. Core Drive 4: Collection Set.” Three named techniques, organized by Core Drive, looking very framework-compliant.

The right version is a description of how the GT actually plays out in the specific experience. “Members can band together each week to answer quiz questions toward a shared reward (Group Quest). The shared reward is unlocked progressively, and each unlock is announced in the community channel where members congratulate the contributors.” Now I can see the user journey. I can see the desired action. I can see the emotional arc the GT is producing.

The difference between the two is the difference between citing a tool and actually using it. Naming a GT without describing its implementation is what I call throwing words at a problem. It looks like analysis from a distance, but if you zoom in, there’s no design happening. There’s a label sitting on top of an empty slot.

This anti-pattern is downstream of the Start-With-GTs mistake. If you treat GTs as ingredients to assemble, you’ll naturally describe your design as a list of ingredients. If you treat them as labels for patterns you’ve actually deployed, you’ll describe your design as a sequence of behaviors with the labels showing up in parentheses. The latter is the version I want to see in every submission, every consulting deck, and every internal product spec.

GT Taxonomy: From Foundational to Meta-GTs

Understanding that GTs exist on a spectrum of complexity helps practitioners pick the right one for the moment, instead of treating them as interchangeable Lego blocks.

At the foundational tier you have single-mechanic patterns. Points. Badges. Countdown Timer. Status Bar. These are the GTs everyone learns first, and they are also the GTs that get over-applied. A points system added to a product that doesn’t need quantification is a tax on attention without a corresponding payoff.

One layer up are the compound GTs, where two Core Drives interact. Magnetic Cap and Torture Break both live here. Both pull from Core Drive 6 (CD6): Scarcity & Impatience, but they operate on completely different axes once you look at them properly.

Magnetic Cap limits the quantity of an action a user can take, and the counterintuitive research finding is that this cap actually pulls behavior upward. Users who would normally do three or four actions per session will average six or seven once told the cap is ten. The presence of a number to chase activates aspiration, and the cap functions as a magnet rather than a ceiling.

Torture Break limits time instead of quantity. You take an action, you trigger a wait period, and a countdown timer makes the wait visible. The wait creates monetizable impatience: every second the user spends staring at the timer, the value of skipping it forward goes up. Free-to-play mobile games run their entire revenue model on this single mechanic.

Magnetic Cap and Torture Break often pair together. Use all three of your daily actions, and now wait twenty-four hours for them to replenish. But they are independently deployable, and naming them separately is what lets a design team have a clean argument about which one is actually doing the work in their product. Without distinct names, the design team mushes them together and ships an experience where neither lever is calibrated, because nobody can tell which lever is being pulled.

Above the compound tier, you find the advanced GTs, which assemble multiple mechanics. The Social Treasure Probability Booster is the prototype: it combines mystery boxes, probability boosters, and community mechanics into one nested experience.

And at the very top sit the meta-GTs: patterns about patterns. The Double-Edged Sword qualifies as a meta-GT because it can be applied to almost any other GT in the library. Take any choice mechanic in your product, attach a positive consequence to one option and a negative consequence to the other, and the underlying GT now has a richer behavioral footprint. Meta-GTs are the part of the library where the framework starts referring to itself, and they’re the ones I most often see beginning practitioners overlook entirely.

The taxonomy isn’t just descriptive. It’s prescriptive. Foundational GTs are where you start when you’re learning. Compound GTs are where most of the actual product design work happens. Advanced GTs are where you go when you’ve earned the right through ten projects of compound work. Meta-GTs are where you go when you want to inflect the entire system at once, and they reward designers who already understand what they’re inflecting.

The Meta-Lesson Beyond Gamification

The pattern I’m describing here is not unique to Octalysis. It shows up anywhere you have a discipline with a taxonomy of named techniques.

Software design patterns. Rhetorical devices. Plays in basketball. Combos in fighting games. In every one of these domains, novice practitioners reach for the named pattern as a starting point, and senior practitioners reach for it as a label for something they were going to do anyway. The taxonomy exists to describe what experts do intuitively, never to replace the intuition that comes from understanding the problem deeply.

If you’ve ever wondered why senior basketball coaches don’t draw plays from a playbook, but instead respond to what the defense is showing them and then assign a play name to the move they were already going to make, this is the same phenomenon. The play names aren’t where the basketball happens. Reading the defense is where the basketball happens. Play names are how the team communicates about the move afterward.

I want every Octalysis practitioner to internalize this. Game Techniques function as communication tools for design patterns rather than the design itself. The moment you start designing by selecting GTs, you’ve inverted the methodology, and your output will reflect that inversion.

A nameless, unnumbered design idea that perfectly serves the Strategy Dashboard beats a beautifully named GT that doesn’t fit the motivational architecture. That comparison holds across every project I’ve reviewed.

If you treat the GT library this way, two things happen. Your designs get better, because you stop pretending that pattern selection is the hard part of the work. And your relationship to the framework gets healthier, because you stop looking to it for permission you were never supposed to need. The framework is a vocabulary that helps you describe what you’ve built. It is not the substitute for building it.

FAQs

Are Octalysis Game Techniques the same as gamification mechanics?

Mechanics is the broader category. Octalysis Game Techniques are a curated, named subset of mechanics that have been observed across multiple successful experiences and given memorable labels for easier discussion. Every GT is a mechanic, but plenty of useful mechanics aren’t on the official GT list.

How many Octalysis Game Techniques are there?

Roughly 130 to 150, depending on which version of the framework you’re working from. The number changes because new GTs get named as new patterns are observed across audits, and older ones occasionally get retired or merged. The exact count matters less than the structure: the GT list is a living vocabulary, not a fixed canon.

Do I have to use Game Techniques to call my design “gamified”?

No. Plenty of effective gamified experiences contain mechanics that have no GT name attached. The point of gamification is that the user’s motivation is being designed for. Whether the mechanics doing that work are on the GT list is a vocabulary question, not a legitimacy question.

What if my design idea contradicts an existing GT?

Then your design idea is more interesting than usual. The GT list reflects what we’ve seen work historically, but counterexamples exist, and a counterexample that ships and produces real engagement is exactly how new GTs get added. Test your idea, watch the behavior, and if the pattern holds across a few implementations, it might earn its own name.

Why are the names so playful?

Because vocabulary you can’t remember is vocabulary you don’t have. Vivid names anchor the concept in memory and lower the friction of bringing the GT up in conversation. The naming convention is itself an application of CD3 (Empowerment of Creativity & Feedback), which is a quiet little joke the framework plays on itself.

Related Reading

• The Octalysis Framework: Complete Guide
• The Strategy Dashboard for Gamification Design
• What Is Gamification?
• Actionable Gamification (book)

If you want the deepest possible treatment of how the Strategy Dashboard, Core Drives, and Game Techniques fit together, the place to start is the Octalysis Framework page. Once you understand the upstream structure, the GT list stops feeling like a shopping menu and starts feeling like what it actually is: a vocabulary that helps you describe the designs you were already capable of building.

WOULD YOU LIKE YU-KAI CHOU TO WORK WITH YOUR ORGANIZATION?