Game Design Deep Dive is an ongoing Gamasutra series with the goal of shedding light on specific design features or mechanics within a video game, in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.

Check out earlier installments on the tutorial system in Rogue Legacy and the rhythm mechanics at work in Crypt of the NecroDancer. 

Also don't miss these developer-minded looks at the movement system in Road Not Taken and Amnesia's "sanity meter" from earlier in our ever-growing Deep Dive archive.

Who: Amir Rao, Studio Director at Supergiant Games

Hi, I'm Amir Rao, studio director of Supergiant Games, the team behind Bastion and Transistor. Here I wanted to tell you about how we developed Transistor's function system, one of the more involved features in the game, and something we kept under wraps through most of development – mostly since we weren't sure how it was going to turn out!

Transistor was our second game, released in May of last year. Supergiant started in the living room of my dad's house in 2009. We recently celebrated our five-year anniversary and are now eleven people working out of an office in San Francisco, CA.

Prior to Supergiant, I was a level designer on Command & Conquer 3 and Red Alert 3 at Electronic Arts where I met Supergiant's co-founder Gavin Simon and our Creative Director Greg Kasavin. The game design process described below represents a close collaboration between Gavin, Greg, and me with input from the entire team. 

What: The Function System

Transistor is an action RPG in which you can unlock 16 different abilities (called "functions" in the game) that can be combined in different ways to create thousands of unique combinations. Experimenting with different function combinations to find the ones that speak to you as a player is at the heart of Transistor's systems design. And, it all came in a sort-of-roundabout way from one place: Our love of collectible card games.

Before we wanted to design an ability system about encouraging experimentation, we were more fervent in pursuing the opposite: We wanted a system that prevented players from forming early or rigid attachments to particular abilities. Rather than 'encouraging experimentation', we intended to make it not possible to go through the game using the same skills over and over from encounter to encounter.

Our favorite model of how this could work was from Magic: The Gathering, where typically you know all the cards in your deck but you're not sure how they will be drawn and in what combinations.  You have a mental model of the perfect cards to play, and the pleasure is in the anticipation and progress towards that over time, as well as the improvisation around having to make do when the luck of the draw doesn't go exactly as you hoped.

A lot of our early experimentations focused on randomness. Imagine a game where you have a 'deck' of various abilities, upgrades, and passive improvements that are drawn over the course of a game level. Over time you add new and powerful options to this deck. When you get to a new game level, you shuffle your deck and put yourself back together again, drawing out your options in a different sequence that creates new possibilities and gives you new ideas of how they might work together. This loop of localized power curves with an ever-expanding set of options was one of the original inspirations behind Transistor's system design.

The card-game angle was so promising to us that we were obsessed with pursuing a model that combined randomness and accumulation. However, the critical design problem with every version of what we tried was shuffling. In a game of Magic, there's a context for why you re-shuffle: You've started a new game. But in a relatively linear narrative experience, finding a natural-feeling reason that your skills reset over and over proved difficult to justify.

It also was really counter-intuitive to tune, as the difficulty of the game had to reset every time the player shuffled. Our idea of these highly localized power curves where you'd draw up, get powerful, and then lose everything clashed with the kind of game we found ourselves making where the stakes were supposed to be getting higher as you progressed.

There is probably a game structure that better holds our original concepts – we just weren't interested in changing the kind of journey we wanted Transistor to be for the sake of a particular systems obsession. If you're curious how we find ourselves in these kinds of places, feel free to reference our year-long preoccupation with integrating gardening into Bastion.

Why did we move away from randomness?

Two key things radically transformed our systems design. The first was finding a shuffling mechanic that actually felt natural to us. In Transistor, every time your health runs out, you lose access to your highest-value function and end up having to proceed without it at least for the remainder of the encounter before it becomes available again. If ever you lose every function in your action bar (which can be up to four in total), you reload at the last checkpoint.

This 'slow death' might seem like a devious slippery slope, and perhaps it was for some players, but we found that it caused many players to try new function combinations as the ones they were relying on became unavailable for a short time. Better yet, they would often stick with these new combinations even after regaining access to their preferred combinations from before.

This system also gave players three chances to complete encounters without having to reset and retry the whole thing again. We liked how, by reducing the player's options for the remainder of an encounter, it tended to induce a more methodical playstyle.

The second key change that evolved the game was collapsing our 'deck' of functions down to a total of 16 by combining powers, upgrades, and passive improvements into one concept. Now, every function could be an upgrade to another function if you installed it onto the other. Or, you could install your function into one of your valuable 'passive' slots to improve your character. This meant we could create 16 strong concepts that one might see in action RPGs (like 'stun' or 'charm' or 'long range') and let players combine them in ways that felt empowering and creative ("I can create a powerful long-range attack that stuns and charms enemies in the blast radius!").

The Result

Previously, I said we were trying to discourage players from sitting on the same powers all game long and denying themselves a deeper and more varied experience. That sentiment came from a very 'eat your vegetables' school of game design that I think many developers can be prone to. You see a relatively natural path-of-least-resistance sort of behavior in your players that you want to discourage, so you try to design all the ways in which it will be thwarted.

Instead, we became more accepting of the idea that many players will be inclined towards familiarity, and instead tried to make a system with enough richness that those more-experimentally-inclined might spend time to figure out what combinations worked for them...and maybe it could convert some less-experimentally-inclined players along the way.

To further enhance this, we layered in a system that reveals more backstory about Transistor's world and characters every time you use a function in a new combination. It helped reciprocate on player investment in both the systems and the story, without punishing those players who wanted to stick with what they knew.

You'll notice that while Transistor's function system might let creative players come up with lots of combinations, it completely lacks 'investment' in the traditional sense of most RPGs, meaning you can't take your favorite function and make it level two or three or 99. In Bastion, you could dump all your currency into your favorite weapon to express your affection for it and make it even stronger.

In Transistor, if you love a certain function, you can combine it with other functions you're fond of, but you can't power-level it. We ended up with a system that concerns itself with pairs and trios and the relationship between them, which harmonized nicely with the rest of what we were trying to do in Transistor.