Category Archives: Game Design

Ocarina’s Image: Fundamental Challenges of 3D (Podcast)

I recorded a truncated podcast version of one of my articles, Ocarina’s Image: Fundamental Challenges of 3D, for the Zelda Universe Podcast.

You can listen here:

Ocarina’s Image: Freedom in Breath of the Wild

“When I was a child, I went hiking and found a lake. It was quite a surprise for me to stumble upon it. When I traveled around the country without a map, trying to find my way, stumbling on amazing things as I went, I realized how it felt to go on an adventure like this.” – Shigeru Miyamoto, 1993¹

Fifteen years after Ocarina of Time, the Zelda team finally retired its time-worn solutions to the problems of 3D. They shifted their philosophy, drew from the inspiration for the first Legend of Zelda, and rebuilt the beating heart of the franchise from first principles.

Previously we examined the challenges of building the first 3D Zelda, and the tradeoffs that Ocarina made to maintain accessibility. These compromises attempted to balance two unsolved problems: decreased readability, and greatly increased complexity. In this final article, we’ll see how Breath of the Wild found new solutions to those problems.

Read More →

Ocarina’s Image: Formulas Etched in Stone

Ocarina of Time was a seminal masterpiece. It was a model for how to make a third-person, 3D adventure game that was accessible and ambitious. It broke new ground in camera control, 3D melee combat, 3D level design, and immersive worlds. It maintained a high standard for readability and accessibility. It sold 7.6 million copies on the N64 and 11 million altogether. Nothing like it had ever been made before, and it set a high-water mark that wouldn’t be surpassed for years.

And it etched in stone, in gamers’ expectations, and in developer’s minds a blueprint for what a Zelda game was supposed to be. It cemented formulas that Nintendo would follow for fifteen years.

“…Ocarina of Time became the standard for me for home console Legend of Zelda games. The series built up from there and nothing ever got made from scratch. I think subconsciously there was a strongly conservative voice saying, ‘This has to be this way,’ and, ‘If you change it too much, people won’t like it.’” – Eiji Aonuma, 2011 ¹

Read More →

Ocarina’s Image: Fundamental Challenges of 3D

 

 “I wanted something that players could get so lost in, it would take them a whole year to finish.” – Shigeru Miyamoto, 1992 ¹

I thought that making the user get lost was a sin.” – Eiji Aonuma, 2016 ²

The Zelda series has a storied, 30-year history. Shigeru Miyamoto created the first game with a team of six people; it released in 1986. A decade later, Eiji Onozuka’s first role was the director of dungeon design for Ocarina of Time. He later took his wife’s family name of Aonuma, directed Majora’s Mask and The Wind Waker, and went on to become the producer for the franchise.

There are almost 25 years between these two quotes, and they reveal a stark shift in the design philosophy for the Zelda franchise. I have long felt that the franchise lost something crucial in the games after Ocarina. It’s easy to blame Aonuma’s leadership. But I have a different take: The move to 3D in Ocarina was uniquely challenging and the Zelda team solved those problems imperfectly, then doubled down on Ocarina’s path for years after.

Until Breath of the Wild. It went open-world, had a non-linear narrative, and re-imagined how dungeons and items work. But those changes required a more fundamental shift: they needed to solve Ocarina’s problems, trust the player, and build their gameplay out of emergent systems.

This is the first of three articles, originally written for the audience of Zelda fans at Zelda Universe. In this series, I use my own experience as a game developer and extensive reading of interviews to infer why Zelda development decisions were made, and how Ocarina’s design shaped the series for years afterwards. But I wasn’t there! This is ultimately an act of speculation. Keep that in mind as you read!

Read More →

Tyson’s Law

Tyson Green is an experienced designer at Bungie. I rarely work with him myself, but other designers who have will often quote this rule of his:

Always solve two problems with every design.

Implied here is the idea that most designs can solve multiple problems, and by following this rule design elements will interlink in ways that better support the game as a whole.

I’ve seen this law expressed in other ways. Shigeru Miyamoto said it in a Eurogamer interview:

A good idea is something that does not solve just one single problem, but rather can solve multiple problems at once.

And in other disciplines! Matthrew Frederick, author of 101 Things I Learned in Architecture School, says:

Any design decision should be justified in at least two ways. … The more justifications you can find or create for any element, the better.

Clay’s Law

Chris Clay was a senior designer I worked with at Turbine. Sometimes we would spend a lot of time in the weeds, talking about a design tweak in a meeting. When we did that, he would sometimes end the meeting by invoking his rule, that the rest of us dubbed Clay’s Law:

Never talk about a design for longer than it would take to go to a desk and prototype it. 

Words I try to live by – though I do love talking!

Link, the Legendary Heroine

Preface (9/20/2016): This was originally published on Zeldauniverse.net, a Zelda fansite. The intended audience consisted of fairly dedicated Zelda fans, most of which were in their teens.

Link! The Hero of Hyrule! A young adventurer who heeds the call to action and saves the land from darkness. Reincarnated time and again, forever destined to wield the Master Sword in defense of the Triforce and the people of Hyrule. Link, of course, is us, the persona we embody when we play a Zelda game, the avatar of our own heroism; the stand-in that represents us in the world of the game. Link is defined by many things: the tools we wield when we play, the land we save, the monsters we defeat, the dungeons we explore, the characters we meet. A green tunic, a sword, the Triforce of Courage. The actions we take and the fantasies we fulfill when we pick up the controller.

The stronger our connection to Link, the stronger our link to the world becomes.

That is why future Zelda games should allow the player to choose Link’s gender.

This may be a controversial position. You may have some concerns with the concept, and that’s fair. I posit that (a) this would allow more people to enjoy the games we love, and (b) it would have no ill effects on the quality of the game, its story, or its characters.

Let’s dive in. Read More →

High Granularity Vs Low Granularity Space

Preface (3/23/2015): I originally wrote this article three years ago, when I was just beginning my design career. It was half proposal, half exploration of design concept. I’ve cut a few parts out that aren’t really relevant to my readers; if it seems to start and end abruptly, that’s why. I had not yet worked on a MOBA, where I learned quite a bit about tanking in PVP, and I overlooked many examples of high-granularity 3D games that had readable positional and facing gameplay. Nevertheless, I think the basic gist of this article is still quite accurate: there is an inverse relationship between spatial granularity and tactical readability.

I’ve been doing a lot of thinking about the game industry’s embrace of fully 3D spaces, huge numbers of possible viewing angles, and the incredible amount of fine granularity introduced when you can move or look anywhere. I’ve come to some interesting conclusions about the effect this all has on gameplay. I want to throw a wrench in the tanking paradigm; bring a focus onto positioning, level design, and the environment; and improve the tactical readability of combat. Read More →

Achievement Design Guidelines

Preface (3/24/2015): In 2011 I was tasked with designing an achievement system for one of the games I was working on. That system never saw the light of day, but I did write some guidelines on achievement design, intended to help future designers that might work on the system. This is an excerpt from those guidelines. Many of these were derived from reading achievement guides written by other designers – but because I never expected to publish this, I didn’t do a good job of saving links to those guides. If you have written similar guides on your own blog, please link to them in the comments here!

While researching achievement systems, I came up with a number of guidelines we should attempt to follow while designing achievements. An important thing to understand is that achievement systems can be used to incentivize a very wide variety of player behaviors, to the point that players will do things they do not enjoy just to earn an achievement.

Push players towards enjoyment

If there is a type of play-style or mechanic that players enjoy already, it’s a good candidate for achievements. Think carefully before incentivizing something they do NOT enjoy.

Evaluate an achievement by the most efficient method it could be earned

Ask yourself: if I was a dedicated player out to earn this achievement as fast as possible, how would I do it? Make sure the answer is something we’re willing to live with. Read More →

Controlling a MOBA on a console controller

Preface (3/24/2015): I wrote this four years ago, when I was still working in QA. I had never worked on a MOBA , or played one on a console. Or done any sort of in-depth dive into polishing a control scheme, for that matter. But I was real proud of this write-up at the time!

This is a concept document examining the design challenges of creating League of Legends or a clone of League of Legends on a console.

Control Scheme Goals:

Speed

Players must be able to execute actions quickly. They must not feel delayed by menus, slow targeting methods, or any other aspect of the interface.

Precision

Players must be able to execute actions with precision. If it involves aiming, the control scheme should allow players to aim at exactly the point they want to aim at. There should never be any ambiguity, and, if the player misses or otherwise fails to perform the action, it should be because of player error, not a failure of interface or controls. Read More →