Interview: Richard Garfield on Getting Design from Good to Great

Richard Garfield is famous for having designed Magic: the Gathering, the first collectible card game. He has released many successful board and card games, such as NetRunner and Roborally, and has worked on several video games including SolForge.

I had the opportunity to interview him. As a game design consultant, I help developers turn their games into hits, so I was very interested in learning how he’s able to release such consistently great games. He had some great insights, particularly regarding the use of prototypes.

PAG: When you’re in the early stages of a project, how do you choose which direction to go in? Which to pursue out of all the possibilities? I’m sure you have a bunch of ideas, so how do you narrow it down and decide “Ok, I’m going to do this thing”?

RG: That’s a different answer for board games and card games versus computer games. With board and card games, it involves putting together some quick and dirty prototypes. With those prototypes, usually when I play them there will be pieces of them that I like and are original. If I feel I can bring them out, I pursue it further. And sometimes that involves a complete redesign.

A little later in the process, typically it’s all about whether people want to keep playing. There may still be a lot of development work to do, but if they want to play another game after they’ve played one for a long game or four for a short game, then I know I’ve got something good. No matter how good I think it seems, if they’re not interested then there’s a lot of development work needed, or maybe it’s just never going to get there.

I’ve noticed this even with Magic. That was the first place I noticed it. Magic was developed for two years. The play testers would complain just horribly. They would just ravage the game for all sorts of different things, but they couldn’t stop playing. And they had reasons to complain. There were all sorts of problems with the game, that’s why it was in development for so long. But the fact that even with their complaints they couldn’t stop playing said you had something special.

PAG: You mentioned earlier that was different when working on video games. I know you’ve worked on some projects, so what’s your approach there?

RG: The problem is that you’ve got to do a lot more planning because it takes more work to get that prototype together. Once you get it together, if you’re clever you have a lot of flexibility, but it’s flexibility within a framework. If you want to change that framework, you’ve got to work a lot again.

For me – and this will vary for different people – I very much believe that games are so complicated, if they’re good, that they can’t really be modeled in your head very easily. I just find it much easier to play them and see, rather than have them described. That’s why I like to make quick and dirty prototypes for paper games, because even with simple paper games it’s just so much easier for me to spend a couple of hours to make the prototypes. I’ll often find something that I wouldn’t see, even if I thought about it for that hour or two.

With computer games, the calculus there is changed because it often involves so many more people to bring out the flavour. For example, in paper games, in my early prototypes I’ll often use a lot of parts in them and put a basic layout on them and that’s because it’s very distracting to the players if they have to extract from the game what its final look is. If you can throw any illustrations in there, make their layout look at all good, then its well worth whatever time it took.

In computer games, it’s the same deal but it’s more difficult. Putting things in like animations is very time consuming and involves all sorts of knowledge. With computer games, I like to make paper prototypes to get started. I’m much more likely to have the whole design or as much of it as I can fit in my head before I get started on the [computer] prototype, because it’s so much more work.

PAG: Interesting. I like the idea of making paper prototypes even for video games.

RG: Yeah, that’s a technique where it can be very frustrating. For example, I worked on the game SolForge. Even a game like that, which isn’t very far from a paper game, if you actually try to prototype it, it’s a mess because you’ve got to keep track of all these leveled up cards and these counters and things like that. You have to be a mature player to be able to say “Well, when this is all going to be automated, it’s not going to be bad.”

PAG: When you have an idea, for a gameplay mechanic or some other aspect of a project you’re on, and it’s pretty good, it’s kinda there but it’s not great yet, how do you push it to the next level? How do you get it to be great, if it’s something important?

RG: It will vary on the project a lot. I mentioned briefly that I like to look for those things in the game that feel fun and original and try to make them happen more often. For example, somebody sits down and they try to use a particular strategy that they’re intrigued by, but it doesn’t really work, then there’s a chance that what you want to do is change the game mechanics and balance so that what they’re looking for is a viable strategy. That could mean they just weren’t good enough to make it work and it takes more skill, in which case you want to make the game fun enough that they stay with it long enough to get good enough. But more often, it’s something like they see a combo and there’s just not enough in the game to make it go.

It’s amazing how small a sliver that can be in a game. For instance, you can play a game for an entire evening and on one turn, I could make a play and I think “Oh, it would be nice if they worried about if I was bluffing.” But unfortunately, the mechanics of the game are so there’s no chance of bluffing, or there is one in a hundred chance of bluffing. So, you’ll have to add this whole mechanic to the game or a set of cards or something, to bring that out if that’s something you want to see.

PAG: I don’t know how large the team you’re used to work with usually are, but when you’re working on a team sometimes you’ve got a teammate who’s coming to you and brings an idea that might be good in their own perception of what the game is, but everybody has slightly different vision, and from your own point of view, you don’t think it’s a good fit for the project. How do you handle that? To keep the game nice and focused, and not annoy your teammates.

RG: I’m probably usually diplomatic to a fault. If somebody brings an idea that they really like, even if I’m almost certain it’s not where we want to go, I’m usually willing to entertain it because maybe 10% of the time I’m wrong. Then I want to have had that insight. Say 70% of the time it will be clear it was wrong and we win. My colleague has become a better designer. And the rest of it, it will be muddy and I’ll probably be able to convince the people which direction I think is best.

I keep an open mind, because they might be right, and if they’re wrong I have a lot of techniques for letting them think about why I might think it’s wrong. I’ll make it clear that I think it’s not the right direction, but if there’s enough people or an individual feels strongly enough, I’ll be open to trying.

For example, one thing that comes up often is that there’s a mechanic that they really like, and I think it’s too complicated. It may not by itself seem complicated, but then I explain that game designs have a complexity budget. You can only have a certain amount of complexity and you have to figure whether it’s worth spending. If you figure you have 10 units of complexity budget and somebody wants to add something of one unit, but it only adds a small value to the game, then that’s not going to be as good as somebody who wants to add something that’s even more complex – it adds two units of complexity – but it adds a lot of value to the game. When people begin thinking about it as a budget that they can use up, it makes it easier to understand why a mechanic may not be strong enough.

PAG: I like the idea of the budget of complexity. It makes it clear how sometimes one feature might be complex and kind of cool, but when you add it to everything else, it might push it over the top and make it too complex or too hard to explain.

RG: Yeah, it’s very easy to look at a mechanic you like, look at it by itself, and think that it’s worth it, but when you look at the project overall, you’ve got to figure out where to cut your complexity.

PAG: Thanks, that was very insightful. Our little chat inspired me to dust up this old prototype for a card game I made a while ago. I might try to do something with it.

RG: One thing I do as a designer, is I frequently have prototypes that I put in the closet for a long time. Even those that I think have a lot of potential, but it’s just too far away. When I pull them out I’ve got more tools and a fresh mind to look at them. I’m frequently, when I need a new design, looking in my closet, pulling out a prototype and starting over. The prototype might be twenty years old.

PAG: Wow.

RG: So yeah, keep those old designs.

PAG: Thanks a lot.