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.
RG: So yeah, keep those old designs.
PAG: Thanks a lot.