Monday, October 23, 2006

The phrase “game mechanics” sends a pleasant shiver down my spine. At the heart of every game are these mysterious whirring clicking mechanisms that deliver to the player pleasure and thrills.

We use them, we build them, but I’ve never seen a good unified definition of game mechanics that gives us a practical base upon which to build great games. Here is one. It is clobbered together from a variety of influences though many of you will recognize some central tenets from ‘A Theory of Fun’ by Raph Koster.

Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.

It is a simple definition, but it offers a good amount of insight into why games work and how we can make them better.

Feedback loopsCentral to the model is the concept of feedback loops that encourage learning. Here is a diagram that should explain the concept in a more visual format:

(click to expand the diagram)

Player performs an action.

The action causes an effect within the simulated game world. The simulation contains public and private tokens and the causal rules that affect the states of the tokens. The player rarely knows all the rules and is highly unlikely to be able to instantly describe the complete possibility space described by the rules. The unknown portion of the simulation is a “black box” that the player must attempt to decipher.

The player receives feedback.

With new tools and information in hand, the player performs another action. Using what we’ve learned, we pursue additional pleasure.

Linking game mechanics to create a system of systemsInterconnected networks of game mechanics make up the game as a whole. You can think of the game as a set of interlinked of puzzles where solutions to one puzzle lead to clues that help on additional puzzles.

The info treats that a game provides to the user need not be used to solve the immediate black box at hand. Humans horde potentially useful information like squirrels horde nuts for the winter time. We’ll store hints in our copious long term memory in the hope that there will be another black box down the line that will yield to our improved tool chest of knowledge.

The traditional metagame that sits on top of a game’s core mechanics is a good example of how one black box feeds into another. In this situation, the game mechanics are arrange in a temporal hierarchy where rapid feedback loops (often part of the basic control scheme) provide tools that enable the mastery of longer term feedback loops. The potential patterns of linking game mechanics together are nearly endless. This is a wonderful area of future study.

Humans are infovoresHumans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.

A key aspect of our model is that games actively encourage learning. I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo.

To turn it into a game, a game designer would need to do several things.

Encourage Discovery: First, make it obvious that the button in meant to be pushed. Humans are naturally curious creatures, but as game designers, we need to explicitly direct them to take certain actions.

Encourage Exploration: Second, the designer would put a counter on the front of the machines that lets the user know that their actions are having some impact on the system. The counter provides delightful drips of feedback and it is up to the user to interpret that feedback

Provide Tool Mastery: Third, the designer would post a note “Payout: 1,000, coins!” Not all games need explicit winning conditions, but hinting at future utility is a highly useful technique for encourage the player to begin interacting with a particular game mechanic.

We’ve turned a gizmo into a simple game of chance. The difference between the two is that our primitive 1-armed bandit is explicitly designed to encourage player learning.

Existing games are richly laden with techniques that encourage learning. A few that come immediately to mind:

Levels take complex systems and encourage players to explore and master one aspect of the possibility space at a time

The use of scores, coin collecting and experience points are all simple feedback mechanisms that let the user know they are making progress towards some future state.

The classic “See the treasure chest you can’t reach” in Zelda acts as a promise of future utility.

A system alone is not a game. A dump of information is not a game. A system that encourages learning through strong feedback mechanisms is a game.

Secondary effectsI’ve just described the foundation of a game mechanic. Now lets dig into several of the secondary effects that immediate appear when you attempt to put this system into practice:

Burnout

Milking

Red herrings

Human factors

Burnout: A definitionAfter merrily harvesting tidbits of information by plunking coins into the virtual pachinko machine, the player will eventually grok the system. The game mechanisms may still serve up information, but the tidbits are not longer as tempting. The info we receive has no resonance with problems that we are solving or problems we have solved. It activates no curious networks in the brain. We begin subconsciously filtering out the feedback from these mechanisms. Burnout is a state of completed learning where the player finally figures out that a particular action no longer yields meaningful results.

In Monkeyball, researchers were astounded to find the the biggest jolt of pleasured occurred when you fell off a cliff and died. People loved it! If you look at falling off the cliff as a huge learning experience, this makes perfect sense. However, when they replayed the animation, people hated it. Same stimulus, radically different response. The animation of falling off cliff lost its ability to teach the second time around. Ultimately, users are subconsciously constantly asking the question “Is this activity worth my time? Does it gain me anything useful?”

Premature burnoutThere are multiple paths that learning can take and not all are ones that game designers desire. We would like to imagine that groking a system results in complete and utter mastery of that system. In reality, ‘grokking’ means that that the user has stabilized on a mental model of the system they no longer feel like improving further. This model can be simple or complex, depending on the inclinations of the user.

A complex model of Black Jack might take into account probabilities of cards appearing based off what has already been played.

A simple model of Black Jack might conclude that cards appear pretty much randomly. There is more depth for the user to explore, but if they are a casual player, saying it is random is ‘good enough’ to judge the game.

A big frustration to game designers is that many users settle on a very simplistic model of how a particular game mechanic works. Players will claim that a game is unfair or too difficult and immediately toss it in a rubbish bin because the designer misjudged their reaction to a game mechanic.

Some mechanisms have highly predictable burnout rates. Most players immediately figure out that watching a cutscene again isn’t going to provide much additional information. Other mechanisms demonstrate a large variation in burnout rates depending on the person who is playing the game and their personal preferences and disposition towards addiction. Some players try a slot machine once and then never again. Others will ruin their lives in pursuit of the next reward, never grokking the simple truth that such machines exist to take money, not give.

The factors that influence burnout are numerous.

Personality.

Personal history.

Practical importance of imagined future rewards that stem from mastery.

The ability for the mechanism to signal that there is additional depth of mastery possible.

The first two factors are not possible to derive by simply exercising your superior intellect. A deep understanding of your target audience’s psychology is most helpful here. The second two factors are very much under the designer’s control and can be refined through heavy prototyping and player observation.

Milking: The transition from learning to tool useThe flip side of burnout is grinding. If burnout is when a player discards a game mechanism because it is no longer useful, milking is when a player continues to exercise a game mechanic long after they’ve reached the state of mastery because the game mechanics continues to provide value.

When a player has learned one system, they will often keep interacting with it. On first blush, this seems mildly demented. The activity no longer provides burst of juicy learning. It is a bit like jawing on a piece of gum that long ago lost its flavor.

However, remember that games are networks of linked game mechanics. Player will continue to interact with a mastered game system in order to create a useful game state for exploring another black box. Mastery gives the player predictable pragmatic tools that helps them advance in other aspects of the game. The learning and mastery that occurs in other portions of the game provide the necessary reward that goads the player into revisiting old game mechanics.

You can extend the time that a player spends with a set of a game mechanics by ensuring that a mastered system still provides utility to the player. Designs techniques that build tools result in more gameplay for less development work.

Red Herrings: Black boxes external the gameThe network of blackboxes that the player considers valid can extend far beyond the systems in the game itself. Often, the player will collect strange bits of info that have no real impact on the game mechanics that the game designer built into the game. These pieces rattle around in our heads like a collection of oddball keys for a set of locks that we may never find.

Game designers can tease the player with hints to systems that do not exist in order to suggest depth to their games. A sly arched eyebrow in a cutscene triggers as massive cascade of meaning alerts. Our brains love people and faces and relationships and the breeding opportunities and politics! Surely, that eyebrow is important? The player greedily stores the memory away.

What impact will the collected information have on their gameplay? None. What impact will it have on their lives? Very little. This virtual person in a cut scene is no one they will ever meet. But our brains were not evolved to deal with such things. As apes, the tale of an arched eyebrow by a potential mate from our little tribe always meant something very, very important. So our brain rewards us with a little jolt of pleasure for noticing such an “obviously” beneficial tidbit.

The designer managed to suggest a system and get some of the benefits of that system without actually building it. It is not going too far to suggest that paintings, sculpture, movies and television all thrive on this simple quirk of our brain’s learning systems.

The downside is that such red herrings burnout quickly. Our brains becomes quite good at recognizing false, useless information. Almost no one watches a cut scene more than once. What would be the point?

My personal bias is to use red herring game mechanics sparingly. As game designers, we have deeper skills at our disposal. We can tailor potent electronic cascades of feedback loops that spin out a complex duet between computer and the player. Such system are highly effective at causing visceral pleasure and encouraging deep long term learning. As game designers, we conduct a majestic symphony of explicit learning and entrancing interactivity, something no static media will ever manage.

Sometimes though, it is worthwhile to suggest great mysteries with broad brush strokes. Setting, character design and plot can be crucial hooks that help make a game meaningful to players before they even press a single button.

Human factors: Emphasizing the humanity of gamesSome folks read about models and immediately see them as reductionist mechanisms that strip the humanity out of the soul out of creating artistic games. The game mechanics I’ve described in this article attempts to avoid this trap. They explicitly include social, narrative and emotional elements in addition to purely analytical problems. All aspects of the human experience, that have an impact on our ability to process and learn from stimuli, fall within the domain of potential game play.

This definition of game design is much broader than the current range of games available on the market. Though it works quite well with hit points, button mashing and high scores, the breadth of the definition is intended to encourage exploration of a much wider range of human learning. Some open questions that I find immediately suggested by the model include:

What are the feedback mechanisms that impact learning about relationships, love, hate or spirituality?

How do we build games around such topics that leverage these feedback mechanisms?

Existing games give us the foundation of practical knowledge that lets us make the same thing in a reliable fashion. A good theoretical framework helps game designers create future titles that are inclusive of a wider range of human experience.

ConclusionThe goal of any model of game design worth its salt is that it both explains existing behavior and predicts future behavior of medium. In my experience so far, this model seem rather robust at explaining almost any existing game on the market ranging from board games to slot machines to social games. There is certainly room for improvement, but it is a good enough for my main goal.

I want a practical model that lets the good folks in this grand industry describe game designs in more exacting terms. The model should give insight into why their prototypes suck. It should allow them to discuss potential issues and solutions with shorthand language that cuts to the meat of the matter. A good predictive model allows for more intelligent design decisions with less waste and unnecessary rework.

So some of aspects of the model that I find useful:

It treats game mechanics as well defined, comprehensive atomic units. These units can be discussed individually and they can also be linked together in interesting ways.

Explicit identification of user value. Fun is not a nigh spiritual activity that spontaneously bursts forth from the ether. It has a testable neurological basis.

There exist clearly inputs and outputs that easily identified. You can easily tell when a specific game mechanic has all component elements such as actions, rules, tokens and feedback systems. Through observation, you can identify the player’s reaction to each mechanism and then adjust its impact.

All and all, the hope is that this model of game mechanics is a good foundation for future discussion. It is one that I’ll be leaning on heavily as I continue to meander through this lovely little series of essays on game design.

A theory of fun for game design: Raph KosterMany of the basic concepts in this essay build upon the ideas in this book. I find it helps my thinking to rework what I’ve read in essay form. Call it a form of active listening if you must. (http://www.amazon.com/Theory-Fun-Game-Design/dp/1932111972

Other loose endsThis essay became too long and started budding little essays. Some have been planted in new documents that may one day emerge in full blossom. The rest are here for your reading pleasure.

Is a book a game? With this big emphasis on learning, there is bound to be a wiseass who asks “Is a text book a game? It too encourages learning.” The problem here is that there are few strong feedback mechanisms evident. The user reads the book and without a doubt they get a burst of pleasure from ingesting the info. However, the act of turning the pages, and interpreting language are skills mastered through other activities ages early. At best, reading the book is an example of milking, where a player uses a mastered technique to advance the grokking of some larger blackbox.

The primary role of content. In this model of game mechanics, content in the game is meaningful only through it’s association with a feedback mechanism. Plot points become reward and hints, Damage becomes a punishment that clues that player into the fact they shouldn’t be doing something. There is no such thing as an inherently pretty picture that exists ‘just because.’ The image is pretty because it activates the brain’s learning systems which in turn feed back into actions.

In order to answer the question “what content does my game need?” you need to first answer the question “What feedback should my game mechanics provide to the user based on their actions?”

33 comments:

I have a theory that the pages of useless description in some books and the long grind of monster slaying in some RPGs serve essentially the same purpose. For both, the idea is to use something mildly fun to space out the really fun stuff, when you get a hit of pleasure from learning about a plot point. The process of enculturation is pretty similar for these two things as well. At first, everyone is bored by the descriptions in Moby Dick and the random battles in Final Fantasy, but after doing it enough, the player gets addicted to the grind because it's so integrally bound up with the core pleasure of learning about plot.

Like you, the whole "game mechanics" issue tends to annoy me, but I think that it's because we over-complicate it a lot. Koster's definition, for example, is still highly vague to my mind.

I prefer a much simpler division between mechanics and rules, which breaks down into two things:

* Mechanics are the actions you can perform* Rules determine the outcome

And gameplay is derived by balancing these two things. So, to take a Tetris example:

The mechanics of Tetris are* Turn a block* Drop a block fast* Destroy blocks by creating a line

The rules of Tetris are* Gravity, which accelerates in a stepped fashion according to score* Score, which increases in a stepped fashion according to created lines* Pile reformation, which determines the effects of a destroyed line on the blocks above.* The lose condition of whether the pieces reach the top* The next piece determinant, which selects what new piece will show after the previous one has landed.

And I think that's basically it.

My problem with trying to break things down into the more holistic Koster-style view (or complicated diagrams of feedback loops) is that it rarely translates to reality when it comes to actually designing something. It's too esoteric, and that inevitably leads to people talking at cross purposes. Communication is the biggest roadblock in successful game design, and simplicity is usually the cure.

Are you familiar with MDA? It stands for Mechanics, Dynamics, Aesthetics. You can find more info here:

http://www.8kindsoffun.com/

MDA posits that feedback loops are dynamics that arise from core mechanics. For example, a mechanic would be that you get more power-ups as you become weaker. The resultant negative feedback loop is a dynamic arising from that mechanic.

MDAI've looked at MDA quite a bit and actually had a section I removed comparing and contrasting this 'atomic' game mechanics to the more siloed approach used by MDA.

Both talk about similar things, but they take a different cross section of the game. MDA lists the big activities that go into making a game. MDA states that there are mechanics (my actions), there are dynamics (my systems), and there are aesthetics (roughly my feedback and synthesis stages). The model I'm proposing says that instead of just having three big buckets of stuff in a game, you can create networks of atomic game mechanics that include appropriate doses of all three elements. It explicitly describes how those elements relate to one another and generate user value.

The benefit is that it is easier for the designer to analyze what is going wrong with a particular section of the game by being explicit about what the inputs and outputs for each atomic mechanics involve and how they are interconnected.

The mention of “MDA” does remind me that I need a flashier name for this particular model so people can refer to it without saying "But I have my own definition of game mechanics!"

"Atomic game mechanics" Hmm...it has a good ring.

Simpler definition of game mechanicsTadhg, I too went down the path you are proposing. However, I ended up with a collection of parts that did nothing to describe the value that the player experiences. One thing I like about some of Raph's ideas are that they include potentially measurable customer value.

The atomic game mechanic model make it clear to the game designer that they need to take into account the player's cognitive response to stimulus, not just as general wishy washy ideal, but as a practical cog in making the game mechanic work correctly.

I can't recall ever offering a definition of game mechanics, actually.

You're right that much of this is reminiscent for me of AToF, but also of the next step from there, which was actually started long before the book was written. Have you seen the presentation I did on "Grammar of Gameplay"? Your flowchart is very directly related, though it starts out at a higher level than the grammar stuff I did.

I'm supposedly working on the Grammar book now. If I ever really get going, I would love to adapt your chart.

One thing I noticed, as a player, is that I hardly ever look for solutions in-game anymore. I just take for granted that whatever problem I'm presented with is meant to be resolved, then work the mechanics backward to attain optimal result. Or I try to do things I'm not supposed to. It's like I'm playing a game by proxy with the makers, if I make sense.I've been dreaming of a game mechanic that would allow to include that kind of meta for a long time. Now that would be fun.

I can hardly picture reading narrations alone as a game (I can, but it demands very particular conditions... harder to get collisions in a one dimensional space :) ). But reading + writing... now we're talking. You can make great games out of that.The learning mostly encouraged by books is data learning, while the real specific learning encouraged by games is process learning. Even when a book teaches you a process, you have to re-compile the data into a working process, so to speak... which is where I can start picturing reading as a game.

On an unrelated note, it's strange to see how hard it seems for people to re-import into real life processes learnt via games. Or to acknowledge that some hated real life processings are the same as loved in-game ones, but presented in another light.

Tadhg, I too went down the path you are proposing. However, I ended up with a collection of parts that did nothing to describe the value that the player experiences. One thing I like about some of Raph's ideas are that they include potentially measurable customer value.

A fair point. I guess what I'm saying is that in the active day-to-day of doing the job is that that sort of approach becomes too abstract for most. I can sit in a meeting with my team and talk feedback loops and responses etc, but it very quickly becomes a highly abstract conversation. On the other hand, the ability to cut to the chase and just talk cause and effect seems to work better in those situations.

The other thing about just having unit parts is, as you say, the difficulty of seeing them beyond their rawness. This is where context matters, and whether we get into the idea that mechanics and rules are universal or not. i.e. Is one kind of game mechanic always fun, while another is always not fun, or does context play a role.

The atomic game mechanic model make it clear to the game designer that they need to take into account the player's cognitive response to stimulus, not just as general wishy washy ideal, but as a practical cog in making the game mechanic work correctly.

In theory, I semi-agree and semi-disagree because there is a place for high level debate and prototyping. In practise, it is also a potential avenue for lots of airy talk and little progress. As with all methods, the real problem is teams that embrace a bit of a method, but retain their usual negative psychology in all other respects. That reduces many methods to lip service. I suppose that's why I prefer to keep things simple if I can.

The question “Is a book a game” intrigues me. While I agree that the actual skills necessary to ‘read’ a book are fairly static for the average adult, since we learned them years ago, wouldn’t you agree that actually comprehending a book requires learning ideas and tools unique to each book? After all, the skills used to interact with a video game - interpreting visual data and manipulating our hands and fingers – were learned long before we ever learned to read.

For instance, while reading a Harry Potter novel most readers are constantly thinking about several questions, such as “What is the extent of Harry’s connection with Voldemort? Has Snape truly repented his Death Eater past? Will Ron and Hermione end up a couple?” The information in the books (character descriptions, plot reveals) gives the reader explicit answers to these questions piece by piece, thus allowing the reader to further extrapolate further answers/possibilities, develop new questions to solve and gain greater insight into the complex thought processes of each character. This gradual reward system and ability of the reader to increase his/her understanding of the social dynamics and history of the characters in the story sound very much like the foundation of a great game. The only difference I see is that with books, the game is taking place entirely within the reader’s mind as opposed to on a television screen. Even then, I would argue that much of the ‘game’ aspect of a video game occurs in the mind of the player, especially when considering story elements (the most important element for some genres, although nonexistent in others).

In other words, I would compare the text of a book to the written code of a game. Both mediums require learning and advancement to take place within the reader’s/player’s mind, although video games also allow a great deal of interaction via the graphical/tactile interface (tv screen and controller). This in turn can be compared to movies or television, which visually represent written stories, although no interaction takes place when viewing one of these mediums. I believe this added level of interaction that video games possess is one of the biggest reasons video games have become an entertainment juggernaut.

Definitely call these something other than simply "mechanics", since that already is in common enough use that it's understood to mean something. The definition in MDA is pretty close to how I've seen it used in industry.

As for books and games, I'd say the same thing. In common use, it is understood that a book is not a "game", and any definition of game should take that into account. For what it's worth, I'd say that a book isn't a game because there's no interaction: you have no control over the outcome. Nor are there any rules. You could layer a game on top of the book by adding these things: subtract the page number when you first guess whodunit from the page where the murderer is revealed, and that's your score, for example.

Back to the "Game vs Toy" argument. Books (in general) are not games by any definition I can agree to, but can be used as toys, for example when the reader tries to guess what's going to happen. He is not interacting with the universe and story (which is fixed), but with his understanding of it (which is not fixed, and depends heavily on his own experience and attitude towards it). That's about as close as I can see a book to being a game.

Contrary to Tadhg's vision of mechanics and etc as "esoteric" abstractions, I consider them as valuable tools and frameworks for structuring and organizing the knowledge of a design. As with any tool, they can be misused, and they can be so fascinating as to become the goals of a designer. As a programmer, I see that all the time. "When you have a shiny new hammer, every problem looks like a nail" and all that.

It is great to approach design as a purely tactile experience, building and shaping through instinct it as you go along. But when a game has a large number of elements and relationships between them, you need a certain level of infrastructure to support and communicate that design.

Contrary to Tadhg's vision of mechanics and etc as "esoteric" abstractions, I consider them as valuable tools and frameworks for structuring and organizing the knowledge of a design. As with any tool, they can be misused, and they can be so fascinating as to become the goals of a designer. As a programmer, I see that all the time. "When you have a shiny new hammer, every problem looks like a nail" and all that.

I feel that I'm being misread here. I didn't say that mechanics themselves are esoteric. What I said was that the discussions that surround what is and isn't mechanics is esoteric and very easily gets derailed into grade A waffle.

It is great to approach design as a purely tactile experience, building and shaping through instinct it as you go along. But when a game has a large number of elements and relationships between them, you need a certain level of infrastructure to support and communicate that design.

Yes you do, and an important part of that is that you have to have a certain means of communicating that structure. In practise, having a few mechanics and rules a la Tetris is easy to communicate. When you have tonnes of them, a la World of Warcraft, then you need your communicative structure to be very clear and concise and leaving no room for misunderstanding.

It also really helps if you can conceive of the mechanics and rules in logical groups because that then makes them easier to convey to other disciplines in the team. Overall, the goal of a design should always be to reduce obfuscation and bring clarity in as short and concise a form as possible.

Completely off-topic, but couldn't find an e-mail link to go straight to the source... Danc, for your attractive diagram, did you just use a vector illustration package (Illustrator?) or do you have some diagramming software that actually produces diagrams that "clean" and attractive?

One thing that I always find missing in discussions on game mechanics is thorough discussion on time. To me, a good game mechanic creates a structure with overlapping rythmic figures in much the same way a song does. While this can be achieved in many ways, it's the almost rythmic jugling of many different smaller puzzles that keeps me interested in a game mechanic - rarely a single mechanic by itself.

Using tetris as an example, one mechanic (placing pieces) happens at the beat level, like a walking base line requiring constant attention - but not the forfront of your thoughts. Another mechanic (the levels) acts as the chord structure, outlining the songs form. While the third mechanic, clearing lines and planning your approach on the blocks which arn't cleared, is the melody, grabing your main thrust of attention and requiring the most thought.

Time even exists as a powerful force in turn based games, where we messure pacing by clicks or moves instead of absolute clock time (as in tetris).

I find it most helpful to pace out my mechanics and see thier structure in time. If two mechanics are in the same time domain they often overload the user - but if they occupy different areas of the time spectrum, the brain seems to autopilot a shorter mechanic while thinking about a longer term one. Longer term mechanics can usually have larger consequences tied to failure, while shorter term ones are usually more forgiving..

Anyway, I could babble on. Point is, I think time and pacing are so intrinsic to any mechanic, and are often not considered in game design theory. I wrote a blog post on this a while back, which is still relivant enough to link below, but one of these days I'd like to produce a more thorough essay on the topic.

Hi Dan, I'm a fellow Seattleite (of nearly 20 years) and a HUGE HUGE fan of your blog :) I work on websites and social apps, and would love to pick your brain on combining game mechanics into web applications. I couldn't find any contact information for you on the site, but is this something you'd be willing to bounce a couple e-mails over?

I know just a skosh, but I've learned it very casually, not really putting much effort. It's been very slow going. I recently came upon a game that purported to teach me. It's at >http://zabon.com/jrpg<.

The heart of the game is really simple. You fight "monsters" (Japanese characters and phrases) which you must "attack" (by typing their readings). If you're correct, the monster is defeated, and you gain experience points; if you are incorrect, the monster attacks you, and you lose hit points. You're also you're given information about the monster: translations, readings, it's use in a sentence. Then you fight the next monster, each in turn.

I found this really quite addicting. Setting up things to learn as though they were to be defeated really motivated me somehow. I just had to defeat the blasted things. I'd be interested to learn your thoughts about integrating pedagogy into core game mechanics.

I always thought game mechanics were the methods you used to achieve a character action.

Just a random thought here: I am a huge zelda fan, and i have noticed something interesting about the gameplay, specifically, defeating stalfos knights. In both Windwaker and TP a huge part of defeating the foe is getting behind him, which you can do with a dodge roll. The weird thing was, the dodge roll was only fun because you needed it. You could use the dodge roll on any enemy in TP, but it wasnt fun then, even though it still decreased your chance of being hit.

So I guess my question is, is dodge rolling fun because of perceived usefulness? If so, then why isn't it fun to use it all the time?

Also, Jason, your game notation only shows reward, when we all know games are about overcoming obstacles. Why not add notation showing the difficulty of the action that lead to the reward?

I have a horrible class that I'm in currently. I had to do a timeline on game mechanics and I used candyland for color recognition. I had to describe the mechanic that taught the skill, so I said in my slide that color recognition was taught by the player flipping a card up and moving to the color on the board that was closest to them of the same color on the card, they marked points off because I was "describing rules, not mechanics". So here is my question, if mechanics are the way you use the tools that the game gives you, how would they not be the way you play the game, which in turn would be the rules of the game as they set the parameters, I didn't go into the rule that states that if you land on the lose a turn orange square after drawing an orange card you can't play next turn. I am just hoping for more clarity as it seems maybe I missed something apparently

A very interesting framework, which moves game design from the realm of myths and legends one step further towards being a true science.

One question: are stories really "useless"? One could see them as the motivator for practicing the skills and avoiding burnouts. Recently I played "Waking Mars". At a very late stage of the game I experienced kind of "burnout" on planting the seeds and manipulating the environment, BUT: I continued playing, because I wanted to know how the story ends.

Why people read this blog

About Me

I've been a game designer, pixel artist, toolmaker, physicist and MBA. My first job in college was on a game called Tyrian at a tiny company called Epic Megagames. These days, I'm the Chief Creative Officer at Spry Fox.