Tag Archives: For Students

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!

Lay Off Post-Mortem

This is the story of my first lay off, what I learned from it, and how I recovered. I recently received a job offer; this story now has an ending, so the time has come to tell it!

Exeunt Max

In the summer of 2014 we were deeply entrenched in a new F2P service game that had gone into open beta a few months prior. The game was in a precarious position, a topic that our project leadership was very open with us about. We resolved to turn it around that summer, and set some very ambitious goals. And we succeeded! We built an excellent game: tightly balanced, responsive, polished, and great looking.

In the middle of this process, we learned that there were going to be some publisher-wide layoffs hitting our parent company and its devs at about the same time we were wrapping up this summer push. We knew layoffs were coming, and we knew that our project was at risk. We even knew the date that they were going to happen. The team handled it well, and we still built a great game: we were proud of it and wanted it to succeed, with or without us. But the weeks leading up to the layoffs were still tense with worry: we didn’t know who or how many were on the chopping block. 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 →