ZBoth MDA [the Mechanics-Dynamics-Aesthetics framework] and my “game fundamentals” framework (I’ll call it GFF here) are useful in different contexts, depending on the problem you are trying to solve or the question you are trying to answer. I’m obviously biased, but for my own projects I find GFF more helpful for focusing on specific areas while iterating on a new game. MDA is a better lens for thinking about players. Essentially, GFF compresses [MDA’s] Dynamics and Aesthetics into a single “Interaction” category, while Mechanics is spread across the other elements (start, goal, opposition, decisions, and rules).—Stone Librande

Stone Librande (pronounced Li-brandy, like the drink), a Senior Designer at Riot Games, and Marc LeBlanc, a Principal Software Engineer at Riot Games, co-ran a daylong hands-on video game development workshop at this year’s GDC Festival of Gaming that was held in March in San Francisco, CA.

I found their workshop inspirational, fun, and eye-opening. What follows is a summary of the workshop, plus additional context about Librande’s broader approach to game design that’s based an email exchange we had before and after GDC week. It’s important to note that Librande and LeBlanc were flanked by a handful of talented assistants that helped herd the 70 or so of us “cats” who participated in the workshop’s exercises.

Stone Librande (left) and yours truly at GDC 2026.

Librande has been a Senior Designer in Riot Games’ R&D org since 2014. In this timeframe, he’s also taught a semester-long in-person and/or virtual game design workshop to graduate students in Carnegie Mellon University’s ETC program.

Regarding his day-to-day responsibilities at Riot, Librande told me, “I write design specs for experimental features, tune game data based on player feedback, work with engineers on large-scale systems, and attend many meetings with producers, artists, QA, and other designers to discuss problems and propose solutions.”

“When I first started at Riot,” he continued, “the design org was smaller and I had more opportunities to consult and share ideas across the product teams. Now, there are more than 100 experienced designers at Riot working on dozens of prototypes, pre-production games, and live-service updates. It’s impossible for one person to keep up with everything. We hold biweekly design meetings where anyone can present a design topic of their choice to the group. Personally, I present something about twice a year.”

Prior to Riot, Librande was a Creative Director at EA/Maxis from 2005 to 2014. There, among other projects, he was the Lead Designer of SimCity and made big contributions to the design of the iconic game Spore.

Before that, Librande was a designer/programmer on what became the action RPG-defining Diablo III. That game had a long gestation period. It didn’t launch until 2012, but work on the game started in the early 2000s with Librande contributing design[1] work. Blizzard North was shuttered in 2005, at which point Librande departed for EA/Maxis[2] and Diablo III’s design/direction duties shifted to Jay Wilson.

Between Librande and the rest of the “faculty” at this GDC 2026 workshop, I and the other workshop participants—most of whom were half my age and either students or game designers/programmers with a few years of experience under their belts—were in excellent hands. We barely scratched the surface of how the sausage is made in the video game industry but it was still an insightful treat to spin in the proverbial meat grinder for a day.

Read on for a summary of:

• A paper prototype that my tablemates and I distilled from an existing video game

• A game system balancing exercise that culminated in a surprise PvP mech deathmatch

• More color on Librande’s approach to game design, particularly as it relates to the MDA framework used in the workshop—and how these frameworks connect to broader design-focused efforts.

Don’t forget to subscribe and restack if you enjoy this!

Making a Paper Prototype of an Existing Video Game

Knowing your audience and what they desire is necessary to make informed design decisions.—Stone Librande

After a round of introductions and general housekeeping pointers were out of the way, participants in GDC 2026’s Hands-On Game Design Workshop dove into the morning’s main exercise: taking an existing video game and making a playable paper prototype out of it that (hopefully) preserved its soul.

How did we do that?

We used a process that Librande and company spelled out for us:

1. Divide ourselves into tables of 4-6 designers each, choose a specific video game we all enjoyed—I joined the Doom Eternal table—and then choose one core gameplay feeling we’d aim to convey in a paper prototype version

2. Work backward from the core feeling we sought to convey to identify gameplay systems that would help engender that feeling in players of our prototype

3. Break the most essential systems that we’d identified into specific mechanics, or sets of mechanics and player actions, and build those into our prototype.

Let’s unpack how each of these steps played out at my table.

Stuck On a Feeling

After sitting at the Doom Eternal table and introducing ourselves, I and my four tablemates turned to task #1: choosing the central feeling that the popular 2020 first-person shooter from id Software and Bethesda Softworks engendered in us. Using pens and sticky notes, we wrote down the feelings we’d experienced while we were playing this game. We then discussed the relative merits of these sentiments.

I and another, for example, both wrote down “anxious.” Ultimately, our table settled on “powerful” after contemplating the overall experience. This was the fantasy and the core feeling that we’d aim to capture in our paper prototype version.

Step one: Identify the main feeling that an existing video game evokes in players.

Once we’d agreed on an emotional north star, our table began discussing Doom Eternal’s systems and general gameplay environment. We noted its confined, dungeonous spaces and hellish milieu. We talked about the ranged, short-range, melee weapons, and ammo that the game’s hero, the Doom Slayer, ran across and can loot from slain opponents. We talked about some of the demon types the hero must defeat to clear a level. We noted the game’s HUD, power-ups, killing streak bonuses, and more.

It wasn’t too long before we’d conceived of a prototype with a series of lanes that featured oncoming demons that each had distinctive speed, hit point, and fighting characteristics. For those familiar with classic arcade games, we pretty much kludged aspects of Space Invaders, Tempest, and Tetris into a sticky note-based lane system that 6-8 notes/blocks in length and had baddies descending toward the hero. The Doom Slayer could switch lanes and fire up them. A roll of the dice determined if, and what kind of baddie appeared at the top of a lane. In the Doom Slayer’s turn, he could choose to shift lanes or shoot/melee.

We’d already gotten a head start on step two.

Ready, Set, ACTION (Verbs)

To identify the gameplay systems that we’d want to include in our prototype, Librande and company instructed us to start by specifying action verbs that players performed in the source video game. Ideally, these verbs lined up with some aspect of the overarching feeling we wanted.

Our table was soon covered in a few dozen sticky notes that had words like “shooting,” “Glory Kill healing,” and “running” written on them. We compared notes again after we couldn’t think of any more. We settled on several common verbs and actions that we agreed were essential to replicate in the prototype. Verbs and actions were moved off to the side if they missed the emotional target or couldn’t be replicated with notecards, dice, markers, and figurines.

Step two: Identify action verbs players performed and that could be translated into gameplay systems that pointed in the direction of the core emotional goal.

I’ll come back to this topic later but, at this point, I was struck by how important it was to understand what was going on in the head (and the heart) of “the player” with great specificity.

High-quality game design and behavioral psychology are inextricably linked.

After more discussion about the prioritization of our action verbs list, we pared our turn-based prototype game back to two lanes. These were populated by three iconic Doom baddies: the Cacodemon, the Revenant, and the Marauder. These demon types had 1-3 hit points each and they could move 1-2 blocks/spaces toward the Doom Slayer in their turn, or they could fire or melee (and deal 1-2 damage points).

The Doom Slayer had 3 hit points and could heal one point by slaying 2+ enemies in the same turn (by shooting or meleeing). To recap, the Doom Slayer’s choices were now to (1) switch lanes, (2) shoot all baddies in their current lane for one point of damage, (3) “instakill” any/all opponents in the square/block in front of no matter their remaining hit points, or (4) advance one block/square down their current lane. Winning here was also defined as the hero reaching the end of either lane alive.

We failed fast. We rapidly prototyped, tested a new version, analyzing the results—especially its emotional impact—agreed on a new tweak, and played again. The design changes came fast and thick. It was fun and we collaborated. We started to get some joy/laughter around the table…and some anxious, potent, Doom-esque feelings also started flowing.

It became a two-person game and we traded off chairs. One played the Doom Slayer. Another was the, er, Dungeon Master (DM). If a random demon was rolled into existence, the DM could choose their entry lane and what actions the other existing baddies took (move down the lane, shoot/melee). The remaining three watched from the sidelines, offering advice when an unforeseen circumstance appeared, and corrected errors. New rules were made up on the fly.

We’d created a working tabletop variant of Doom Eternal’s core game loop…if one squinted hard and had a vivid imagination…because the game’s systems and dynamics did generate some intense moments and feelings of heroic power.

We weren’t done though.

Trust Your Mechanic

I didn’t take photos of our “game board” because I, like my tablemates, was lost in the moment. Suffice to say there were a bunch of color-coded cards arranged on our table between the Doom Slayer and the DM. These cards had hit point markers on them if they contained a demon. The Doom Slayer’s hit points were noted by markers off to the side. A roll of the dice determined if a new demon spawned in at the top of a lane. The DM directed the demons on the board to move or shoot/melee. The Doom Slayer moved, or shot, or meleed during their turn. In the parlance of game developers (and well-informed players), the specific actions that either player could take in their turn was a game mechanic.

We’d barely pulled together a roughly-balanced prototype when the twist was introduced: A noob player from another table was brought in to play the prototype. In our case, she played the Doom Slayer and squared off against a practiced DM. We blitzed her with existing rules and explained the mechanics within two minutes, then the dice started flying.

Our playtester got the turn-based lane-switching and shooting mechanics down right off the bat…but missed the “advance down a lane” option. During her first several turns, she kept shooting baddies at a distance and she advanced not a single square/block down either lane.

Time was up.

So much for our playtest!

Based on our mechanics, this prototype could go on forever in theory. If the Doom Slayer sat back and picked off newly spawned baddies before they got too close, the core loop could be endless.

Hmmm…

Perhaps we needed to add a level/round turn limit to ensure the Doom Slayer understood they needed to advance up one of the lanes?

We didn’t get a chance to test this change.

Step three: Take the prototype’s core gameplay systems and break them down into a set of actions (mechanics) that players and opponents could take, given the bounds of the rules.

We’d drunk from a firehose called the Mechanics, Dynamics, and Aesthetics (MDA) framework in this exercise. Before we began, Librande asked how many participants in the room were familiar with the MDA framework. A clear majority of hands went up.

The MDA framework made its debut back in the 2000s and—surprise, surprise—one of our faculty co-leaders, Marc LeBlanc, helped to create it while he was at MIT! (For a deeper dive, a free hourlong MDA overview class from MIT is here.)

MDA appears to be taught in many college programs that have a game design curriculum. The tool is used to analyze games, create design documents, connect a design to development/production/coding processes, and, yes, to prototype game designs.

As alluded to earlier, Librande also developed a game design framework in the 2000s, which he refers to as the game fundamentals framework (GFF). Librande has presented this model many times at GDC, most notably in 2012 (the associated deck, Designing Games for Game Designers, is available at Librande’s website for noncommercial purposes).

Being aware of this framework before the workshop, I was surprised Librande’s GFF barely came up and clearly took a backseat to MDA.

It turns out that this was partly due to time constraints.

MDA, Librande explained, “is a helpful way to think about the relationship between game systems and player actions. In many ways, MDA is more about the relationships between mechanics, dynamics, and aesthetics than it is about the individual pieces,” and there simply wasn’t time in the morning exercise to drill down into Librande’s GFF. His framework can be used to assess games in terms of more specific elements that are nearly always present, as the figure below illustrates.

An overview of Librande’s GFF per his 2012 presentation; a video replay of this excellent session is in the GDC Vault. The GFF allows a game to be assessed from six different angles: its Start state, its Goal (endgame) state, the Opposition players face as they navigate between the Start and Goal states, the Decisions players make as they playing, the Rules of the game, and its Interaction system (the UI). The sliders that are next to or under each element in the figure above are meant to convey the idea that each of these elements can and should be tuned, and the designer’s job, in fact, is to maximize the potential of each element while ensuring these elements also work harmoniously and in balance together (all of which contributes to a game’s UX—its user experience, and the core feeling the gameplay conveys.)

In Librande’s experience, advanced designers rarely draw on either framework in their day-to-day activities.

Librande said that most professional “game designers internalize MDA, making the framework intuitive and automatic. We don’t need to call out obvious things like, ‘This is a mechanic’ or ‘This is a dynamic.’”

“Secondly, the large projects I work on often have dozens of specific frameworks built exclusively for that project. They are created for focused problem solving and discussion. (And quickly forgotten when they are no longer useful.)”

Wow.

So, MDA and GFF are in the kiddy pool of game design. Or, rather, they’re just the tip of a much larger and deeper framework iceberg. The elements that make up MDA and GFF are so well understood by most pro video game designers/developers, Librande implied, their lessons tend to melt into the ether, making advanced/pro developers like fish who’ve lost awareness that they’re swimming in water.

The MDA framework, Librande added, stresses the importance of “catering to players’ aesthetics and observing their emotions.”

His GFF shines when it’s important to reach “precise statements, like ‘This rule is hard to understand’ or ‘This obstacle is too frustrating.’” That level of understanding can then be converted into specific design improvements.

GFF can also be used to improve the balance between mechanics, Librande said.

“A rule change that increases a slider for a competitive player might be perceived as a decrease for a social player.”

There just wasn’t time to apply GFF given the workshop’s time constraints.

Different tools for different purposes.

One of the most interesting insights coming out of the morning’s MDA framework review for me was that game designers and players come at games from opposite directions. A designer starts with an emotional, psychological, and/or aesthetic goal they want to achieve for the players. They work backwards from there to identify the systems, activities, and gameplay dynamics that will support the aesthetic/emotional experience they’re after. From there, they drill down to describe and detail the player actions and mechanics that will feed into the larger-scale systems that support their aesthetic goal.

A noob player has the opposite experience: first, they experience a game’s basic mechanics; over time, they gain a better sense of a game’s larger systems and how they interact and are balanced (or not); only after they’ve played the game for many, many hours, and in some cases weeks or months, do they finally understand the game’s “message,” its central aesthetic point, and plum the depths of its emotional range. If a player makes it this far, that’s when he/she/they are in a position to decide if they love a game, hate a game, or feel something else (or nothing at all about it).

As a market analyst who primarily covered the financial ins and out of AAA studios and hardware makers in the video game industry for 15 years at IDC, this morning workshop reacquainted me with a basic truth: a successful video game always and everywhere starts with a high-quality design. Many, many things derail video game projects. Many, many things cause even well-designed games to fail commercially (and we’ve seen it happen a lot in recent years). Coming out of this workshop exercise, I was convinced that it’s impossible for a video game to succeed commercially if its underlying blueprint is badly flawed.

Game design work happens so far upstream in the process that it often gets lost in the shuffle, at least from outside of a studio looking in, by the time a game is commercialized. Its genre and game comparisons, I suppose, become shorthand for a game’s design process. The specific quality of a game’s design—as abstracted away from its production process, and its post-launch support process—is almost never discussed.

Yet how important it is!

No amount of money can keep a game afloat if it launches with holes in its hull and a rudder that sticks. A few hours in the “meat grinder” made me appreciate, anew, the quiet, essential, seminal work that game designers do. If this workshop was any indication of how the sausage in this industry is generally made, then game designers also work with joy in their hearts. These young adults were having a blast.

A corollary of this takeaway: gamers don’t pay money to keep a video game studio/publisher afloat. Gamers pay money for games they love to play, for the emotions they engender. Both of those things point straight back to design work.

The morning’s exercise touched on what Player Driven is all about in this sense: It took an incredibly player-centric view of “the market” and stripped the subject down to its essence—a psychological and emotional experience that happens between the ears of individual gamers—and endeavors to get that framework working well, and builds up and out from that foundation.

Game System Balancing, With a Side Order of Mech Deathmatch

Often, I choose to build a game because I want to learn something and grow as a designer—and as a person. It's not about mechanics first and theme second (or vice-versa). It's about discovering what works and what doesn't through lots of playtests. Change and inspiration can originate from any part of the framework at any time.—Stone Librande

After the lunchbreak, participants in the Hands-On Game Design Workshop at GDC 2026 engaged in an exercise to balance the various elements of a predefined game that Librande and company deposited on each table.

I won’t get as far into the weeds of this game as I did for the morning exercise but, hopefully, the pictures below help convey the essential points. It was a two-player game. It was asymmetrical in that one player controlled four tanks that could move/fire in certain predefined directions. The other player controlled a relatively powerful robot that ran specific set of 10 actions/mechanics during its turn.

Each tank had four hit points and the robot had ten. The goal of the player with the tanks was to defeat the robot by getting its hit points to zero. The goal of the robot’s player was to get to the other side of the board with at least one hit point (beyond which a city would get obliterated).

I knew what this exercise was right away because it’s in Librande’s 2012 deck. It’s called Us vs. It.

The Us vs. It exercise started with a pair of participants tuning the balance between the damage that a large robot could deal to four smaller tanks, and vice versa (we repeatedly adjusted the numbers in the squares in the boxes at right above).

The early goal was for the robot to be destroyed just before it gets to the line into the city. The point was to adjust the math of hit point damage in a way that led to an exciting climax: ideally, one tank would be left with one hit point that takes out the robot that’s near the victory line.

A small twist was introduced. Each team of two players were tasked with coming up with a novel mechanic that would replace one or two of the steps in the robot’s preset list of 10 mechanics (they’re shown at the bottom center of the photos above).

I and my partner, George Zou—a first-year graduate student in USC’s Interactive Media and Games (IMGD) program and super chill dude—decided to make our robot transform into a tank (rendering it invisible to enemies but also unable to deal damage in that turn).

We were back in the failing fast cycle. It only took 3 rounds for the robot to either reach the other side of the map or be destroyed. We innovated, tested, analyzed, and revised fast. Numbers were adjusted in each round.

After about 30 minutes, we got what we wanted: each of us had played both sides and gotten the robot destroyed with one tank remaining near the finish line. That’s what Librande and company called the “Hollywood ending” goal.

Then the big twist came.

Our table had four teams of two players. Now we were asked to pit our semi-custom robots against each other in a 4-way deathmatch.

The clever part of the exercise’s set up was that since our robots had been balanced against the same four tanks, our mechs were now balanced against each other.

Us vs. It goes deathmatch.

The custom twists that we’d put on our robots varied the gameplay in this showdown phase, opening the door to a climactic finish that none of us could predict (and reinforcing the GFF-based insight that careful balancing of the math that underlies a game’s mechanics and systems can yield more exciting outcomes in both a multiplayer and single-player game context).

George and I won!

Here he is holding up our winning transformer…and don’t sue us, Hasbro!

USC graduate student George Zou (right) and I crushed the competition in Librande’s Us vs. It exercise. (Note: A playable online version of the exercise is here.)

George and I made it to the other side of an expanded board with more hit points remaining than the only other mech still standing.

“Autobots, roll out!”

We didn’t get into it, but this balancing exercise falls under Librande’s Opposition element (its set of mechanics/actions), per his 2012 GFF deck.

Such balancing exercises inevitably involve math. In more sophisticated game projects, of course, these equations can be extremely complex. Balancing exercises may run across massive spreadsheets and interconnected pivot tables with a wide range of variables. Us vs. It was another case of scratching the surface, or touching the tip of a massive, math-riddled iceberg.

If a game has an economy—a player-driven marketplace—then it can become virtually impossible to predict where the market will go post-launch. Having an in-game market virtually necessitates that the studio use a Live Ops approach to content, patches, etc. No matter how large, complex, and “living” a game’s economy gets, the afternoon exercise implied, the game’s economic/mathematical systems still need to bend in service of the core aesthetic/emotional goal. The math, the economy, the balancing of a game’s various systems ultimately exist to serve the same psychological and emotional north star that all other game systems and mechanics exist to serve. (Note: for a deeper dive on a Live Ops process that complements this view, see our recent profile of ArenaNet’s Crystin Cox.)

This was one of my key takeaways from the afternoon exercise.

Both of the day’s exercises stressed the pivotal role that behavioral psychology plays in video game design processes. Whether it’s the MDA framework, Librande’s GFF, or, presumably, many of the other frameworks, custom design tools, and processes that exist in the industry’s “iceberg” repertoire, getting into the mind of “the gamer” and teasing out and serving his/her/their emotional needs appears to be paramount.

Perhaps as much as anything else, this reality may explain why every year sees a new indie game go viral—I’m looking at you GDCA winner Clair Obscur: Expedition 33—and a game with hundreds of millions of dollars behind it fails to resonate commercially.

The problem from a market analyst’s perspective is that it’s impossible to know the quality of a video game’s design from the outside prior to launch. You just don’t know. Neither do any of the other voices and data streams that emanate outside the studio.

As I exited Moscone’s West Hall after the workshop ended, I wondered how many other fields of design went as far into the psychology of future (and/or current) users, and into the core emotional experience that designers wanted the users of their goods/services to have.

What is the MDA framework and GFF assessment of Waymo’s taxi service…or BART…or JetBlue airlines? Does every company have a designer somewhere whose job it is to identify and serve the emotional needs of “the customer?”

Is game design unique in this respect or not? If not, then why do so many IRL goods, services, and processes suck? Are these designers bad at their jobs or are economic and financial considerations, or something else, precluding them from actually serving the emotional needs of “the customer”?

In Librande’s experience, other kinds of designers do use a similar process.

If you “were to interview any designer at almost any company,” he told me, “you would hear similar things about understanding the target audience’s needs.”

Perhaps the Interaction aspect of design is simply much harder to balance in an IRL context?

“How do you ‘talk’ to the game?” Librande wrote in response to a question I asked about the Interaction element of the GFF. “How does the game ‘talk’ back? Is playing the game fun? (The type of ‘fun’ must match the target audience: social, competitive, narrative, etc.)”

I doubt I’m alone in thinking that many of the IRL goods, services, and processes we use routinely “talk back” in negative, decidedly unfun ways!

This might be an area in which listening to, and learning from game designers might be of benefit to other designers, creators, and innovators of all stripes. In the workshop, we indeed only scratched the surface of, and tinkered with things that were “just a game,” but when one stops and thinks about it, as I did, as I waited…and waited…in a dirty, smelly BART station two blocks from Moscone, the psychological aspect of design has universal applications.