Probably Designed: Eddie Cai and Kev Chang

This epside is the first of a two part conversation with Eddie Cai and Kev Chang. Eddie is the lead designer at Pengonauts who released Star⭐Vaders earlier this year. Kev is the director of Box Dragon Studios in Sweden. Their game, As We Descend, went into Early Access at the end of May.

You can find both games on Steam.

Pengonauts: https://pengonauts.com/

Star⭐️Vaders: https://store.steampowered.com/app/2097570/StarVaders/

Box Dragon: https://www.boxdragon.se/

As We Descend: https://store.steampowered.com/app/1769830/As_We_Descend/

Introductions

hdh: Why don't we start with you, Axolotl? I'd love to hear a little bit about you, your background, what you're interested in terms of design, and a little bit about your game—the one that you've been working on that was just released, Star Vaders, which is a fantastic game in my opinion at least. And then we'll talk to Kev as well.

Eddie: Yeah, so I'm Eddie, known as Axolotl online, and I like watching movies. We started an indie game studio with a couple of my friends a few years ago, and Star Vaders is our first game. It's a roguelike deck builder.

hdh: Is there anything in particular that you were aiming for or thinking about in starting your studio or starting your practice? Is there a natural progression from what you were working on previously, or was there some particular thing that you had in mind or were aiming for in your studio?

Eddie: Yeah, not at all. Basically, we were working on Star Vaders as a hobby project in our free time, and when it grew bigger is when we realized there's more potential in it. That's when we started working on a prototype that we put on itch, and then some publishers reached out, content creators covered it. So that's when we kind of started thinking about starting a studio. Only after we signed a contract did we all go full time on the game.

hdh: And so how long were you working on the game prior to becoming an actual studio?

Eddie: Like a year, maybe a year in our free time.

hdh: And what sort of movies are you into? Are you into all sorts of movies?

Eddie: Oh, I love horror movies.

hdh: Any particular era or sub-genre of horror films?

Eddie: Yeah, my favorite sub-genre of horror films is related to the monstrous feminine, which is hard to explain, but movies like Alien, Raw, Suspiria—they kind of deal with feminism in an interesting way. It's an interesting sub-genre for sure, and a lot of my favorite movies are part of it. I dunno why, it's just fun to watch.

hdh: Is there anything from that sub-genre of movies that flows through to your practice in game design? Is there anything that you'd say informs your work from the filmic background?

Eddie: So I've also dabbled a bit in filmmaking as well, and I think in terms of art, there's a lot of thinking about how something is supposed to be interpreted by a viewer or player, and in the same way, guiding the player or viewer. In film, you guide the viewer's eyes through clever edits or camera movements or color or lighting. In the same way in games, you guide the player's thought process through mechanics and gameplay interactions. So I think a lot of that carries over.

hdh: Very cool. And let's jump over to you, Kev. You've been working on a game for some time as well—also a run-based collectible card game. I'd love to hear a little bit about you, your background, what brought you to what you're doing now. And if you want to talk a little bit about your game or what you're excited about, that's also amazing.

Kev: Of course, I'm Kev. I'm the game director of Box Dragon. We're a team of five now—I think most of our production we had about ten. I've been working on this game for over five and a half years now, along with my other co-founder, Karl, who is the tech half. So yeah, it's been a long project. You have to call it what the market calls it, which is roguelike deck builder. At the end of the day, "run-based" is probably the better, more accurate term. But I think the unique thing in As We Descend is that you've got this kind of double deck building—or maybe even triple deck building if you want to call it that—because you draft which units you do, and then each unit has its own card pool, and then you cobble that together.

Maybe that ties into some sort of background. So I'm not a movie guy at all—it's funny, I love hearing the movie talk, but it's such a different world. I definitely enjoy a good film, but I am much more of a "tinkering in the sandbox with my games and mechanics" kind of guy. So I think my background is definitely board games and making mods. I spent so much time making mods in Warcraft III and StarCraft in my life that it must be thousands of hours, and hundreds of board games in my board game graveyard. I call it a graveyard, but it's kind of the repository, the archive of all the ideas. I've had a few published—I had two published. One is out now called Critical Mass. It's like a mech dueling game. So definitely I've been in the card game space for a while now.

hdh: And so have you been working in games for most of your professional career, or did you do something before games? I know that in game design, there are a lot of different backgrounds. I guess historically there are tons of folks now who actually managed to make whole careers out of games. But were you doing anything before games, or have you been in games pretty much your whole career?

Kev: That's a great question actually. I think it is awesome that game design gets so much value from being from a different background, like you've mentioned with films and doing different things. I did IT for a little bit. I was in New York and just doing IT at an architecture firm, but it wasn't my passion. It was just a day job. So in my off time, I was still tinkering at board games. I guess professionally, I wanted to do full-time games, so that's why I moved to Sweden. That's why when my co-founder and friend Karl was like, "Hey, do you wanna come to Sweden? Work on games full-time?" I'm like, "Of course, let's do it."

Games have definitely been a passion for me in most of my waking life ever since childhood even. I would say since I was like six, I was probably making games already. So it's definitely been a thing I've been chasing—I want to be making games all the time. And of course the design facet is the most interesting part to me.

hdh: You mentioned that you've been working on As We Descend for five years or so. That's a pretty long haul. I mean, it's a beautiful, awesome game. Were you also working on it on the side before you had a publisher or before you had the organizational structure to work on it as a job?

Kev: So that kind of came up in lockstep with the pre-production of the game—like tinkering with the pitch that happened alongside discussions with Coffee Stain, who's our longtime backer and partner on this endeavor. I bet it's a unique case, at least in my head it's a super unique case. I'm sure if you talk to more game devs, you'll find out how typical or atypical it is. But we definitely got the game off the ground from just the paper pitch really. And the game has been through a lot of evolutions. So is it the same game as it was back in 2019 when we were pitching it? I don't think so, but I think there's a spirit of the game that has sort of transcended and has been a red thread for the whole time. I think there are probably like four other viable projects that could have spun off from it instead if we took it in a different direction. But it's been a fun journey.

Card Pools and Run Identity

hdh: Awesome. Well, I would love to segue into one of the topics that we had discussed before in our pre-show prep—the idea of card pools and how you build and customize card pools. I think there's a lot here to talk about. I know that both your games have unique approaches, and I feel like Eddie was talking about this online in a thread that I saw. Maybe it's a topic that's near and dear to you—this idea of run identity. And I think that card pools play into this significantly as well.

There's something interesting to talk about. Both of your games, from my perspective, really feel that not just the individual card mechanics, but the entire card pool feels well-crafted, and you do feel like you are able to dig into—people would call them factions or whatever else, but they're different character classes, in some cases characters with their unique mechanics—and really go a direction with a build. But you're mixing this, of course, from the perspective of a designer, with some amount of randomness in order to give the runs the variance and excitement that they need to work in the genre.

I would love to hear a little bit about your philosophical takes on how do you manage this? How do you build an interesting collection of cards that work together, but still has this variety and run identity? I think there's a whole bunch of topics here and the two of you are the experts on it. I'm just setting you up.

I'd love to hear actually maybe a little bit about the approach in Star Vaders to start, and then we can wrap around and see how the conversation goes. Because in Star Vaders you do have a couple different dimensions that are at play in terms of how your draft pool is set up. Would you mind walking us through that?

Eddie: Yeah, so basically in Star Vaders, you got the classic classes in the deck builder. Each class has their own unique card pool, and within each class, you also get to pick your pilot. And then each pilot also has unique cards added to the card pool. But what you're talking about is really the neutral pack system in the game, which actually came up pretty late into the development of the game—probably came up with that last year.

The idea is that every time you play a run, there is a subset, a random subset of neutral cards that will be available to you during the run. So for us, we pick three packs out of ten, and each pack is basically composed of five cards and three relics. So every time you play, you get three packs mixed into the card pool, which makes it so there's a lot of variety between every run. Every run you'll see different cards, and not even—you'll see different cards, but some cards you won't be able to see. The card pool itself is randomized between runs.

And the way we've designed the card packs, we made it so the packs themselves—each pack is focused on a specific synergy or archetype so that they feel coherent together. And the pack system basically lets us add as many packs as we need without diluting the card pool, which is potentially a problem if you wanna add a lot of content to a deck builder. But there's no point in focusing on any specific archetype—it's really tough to find it in general, which I'm sure we'll talk about more.

Kev: That's a dangerous roguelike thing, right? Of diluting the pool. It's been in the conversation since as early as Binding of Isaac. Do you want to unlock more things? Because it's gonna invade the pool, right? If you're breaking up the synergy, and the synergies are the fun thing, then does it make the game worse as you unlock and add more content to the game? And I think this solves it in quite an elegant way.

I think another interesting thing about your pack design system is you have, like you said, you only have five cards in each pack. That's actually a very small number. What made you decide to go with such a narrow set of cards?

Eddie: Yeah, five. So in our glossary, there's five columns, so it looked nice. So that's why there's five.

Kev: Good as good reason as any.

Eddie: Yeah, I actually think that's mostly the reason, but also it just seemed to work, right? If it works, it works. And the bigger the packs would be, the harder it would be to come up with more packs. So I'm glad we kept it at a pretty small number. Our game itself, actually relative to other games, has a surprisingly small amount of cards, but it doesn't feel that way because the cards are all super impactful by themselves. And on top of that, there's the upgrade system that does change up all the cards by a lot and allows for a lot of different types of synergies, interactions. But yeah, five cards makes a difference in a card pool. It makes a big difference. You can explore a completely different archetype just from such few cards.

hdh: On a specific run though, in Star Vaders, how many cards are in your pool between the packs and then the pilot cards and the class cards?

Eddie: It's probably around a hundred, I'd say.

hdh: Okay. In any specific run, there's probably a hundred in your pool.

Eddie: Yeah.

hdh: Okay, that's actually quite a lot though, right? One thing I noticed about Star Vaders is that my deck always ended up being pretty small or usually ends up being pretty small. And I don't know if that's because I end up just focusing on upgrades or I end up focusing on very specific synergies really early on. But I do find—and it just might be the number of rounds of draft that I have—I just don't have enough to have a ton of cards or whatever.

Eddie: Yeah, there's also really a surprisingly low amount of drafting in Star Vaders. You probably draft cards five or six times in the game, in a run. And there's the shop of course, that you can buy cards from, but I think in Slay the Spire, you'll probably draft ten times in a single act. It's a very different pacing for drafting. So you definitely end up with smaller decks—smaller, more concise decks, but on purpose.

One thing from Slay the Spire I didn't really want to keep was the idea that you'd be skipping so many cards 'cause there's so many drafts that sometimes you'd be diluting your own deck, right, if you take too many cards. So I wanted it to be—I basically tried to just remove the drafting that would've happened that you would've skipped. You only need X amount of cards to make your build. So I'm just giving you exactly X amount of drafts for you to build the deck with.

And what helps for our game is the re-roll. Instead of skipping, we have re-roll. That's what makes a difference. If you don't like a card, you can re-roll instead of skipping.

Kev: You can kind of think of a re-roll as a skip and a new draft sort of, right? In a sort of janky way—not in a bad way, certainly. It's just a different interpretation of it.

Eddie: Yeah, no, exactly.

hdh: And then with As We Descend, Kev, because I have multiple classes that I mix up for each encounter, and then I also have a lantern deck, it's like I have several decks that I'm mashing together. And that's part of what gives the variety.

Actually in As We Descend, in a single run, because you have these multiple units that you're navigating, you end up having different decks for different encounters, and I think that the two of you are probably better players than I am, or more advanced players, because I end up like, "Oh gosh, I only have enough hit points for these two units, so those are what I'm taking to this encounter or whatever." But I think you could probably do more planning than that and actually combine and build your synergy for the different encounters in a more advanced way or a more planned way, right?

Kev: Yeah, that's definitely the anticipated high-level play. I don't know how many players are getting to that level. I definitely see a lot of player feedback where that's not necessarily clear, and I don't think that's their fault. I definitely think it's a case where this kind of design, which has multiple pools, which has such complex synergies, needs to scream, "Okay, you want to build this kind of thing, you want to build around this."

That's why I think the Star Vaders approach—okay, each pack has a very clear identity, it does one thing, and that's about it—is actually a very good design in that way. I think our units, some of them are quite complex. Almost to be as complex as a character in another roguelike deck builder. And that's probably a little over the level because then you're like, "Okay, how do I juggle these multiple characters that are hyper complex?"

But unit pool-wise, a unit has about fifteen to twenty cards and you get four units through your run, along with your lantern, which is about forty cards. So if you do the math, it's about 120 cards in your card pool each run. And the total card pool is about 480. So you see about a quarter of the card pool each time, which is a very small portion, right?

Again, Axo is saying a hundred cards out of maybe—I think it's like 200, 300 in Star Vaders?

Eddie: Three hundred.

Kev: So you're seeing maybe one third of the pool? But it's one of those things where it doesn't matter how many there are total, right? It's, do the things you see on a given run make it feel like, "Hey, I'm building towards this specific build, am I getting towards this thing? Are the pieces working together?" Right?

And I think I'd share some of Eddie's thoughts on how often should you skip a draft. And I think As We Descend handles this a bit differently, although I think players are used to tools like skip and removing cards. So in As We Descend, like you said Harry, you can just not send troops to battle, and not sending troops is super impactful. Each unit you have has up to eight cards. So if you don't send a unit, it's like you get to remove eight cards that you don't want from your deck. And if you could do that in Slay the Spire, if you could do that in any other roguelike deck builder, you would press that button every single time. You'd be like, "Hey, if I can just face this boss and not have the cards that don't help me, let me do that every single time."

hdh: But it's a risk-reward balance thing, right, with As We Descend? 'Cause you have to also manage your hit point pool. Because you're gonna take a certain number of hits, and if you don't have enough units, you're not gonna survive the encounter. So you have to make that trade-off. It's kind of like drawing cards for life or, right? You're making this trade-off where you have better control of your card pool, the cards you see, but you're introducing this other risk.

Kev: Totally, and I think that's what makes it quite a complex decision where I think it's quite fun from a design standpoint. I think it's super intriguing, right? It makes the game ultra crunchy, have these deep interactions. At the same time, there is definitely a thought about how clear is this to a player in terms of card pool design.

Because I think if I asked players, would they identify units as having card pools like this, I don't know that they're necessarily thinking about the gameplay on this layer as they would if, let's say, the packs were more declared or written out a different way. So I think there's definitely ways you can approach the idea of softly changing the card pool and doing it in a subtle way, or you can do it in a more strict way where it's really declared that, "Hey, these are the cards you have to work with. This is what you can do. These are the limits."

Because I think that's an interesting part about the genre, right? The players are playing in this space you're giving them to explore and see what's possible, but them being able to identify what is possible is a big part of that gameplay experience.

hdh: But sometimes it just takes time, right? Because I mean, you're in early access for maybe a month at this point or less than a month. So sometimes these things just take—you know, it's the classic thing as a designer, you've played the game a lot and it's gonna take six months for players to get to a certain level in terms of their sophistication with how they understand the interactions. And then they start to see the deeper interactions. And the fact that it's there, I think, is a lot more than a lot of games in the genre can say, because that depth is actually pretty interesting, assuming that you can of course pull the thread so that the players come along with you to get there.

Kev: For sure. Yeah, I think that's my wheelhouse of design. I love doing designs in this space, but it is definitely one of those things—a danger as well—where how apparent it is to a player is at least somewhat important in terms of getting players to play around in the space and fully explore it before they're like, "Oh, I can't see it, I don't know where it is."

Of course, like you said, early access, it'll take time, and these systems, sometimes you just have to keep adding onto it until it becomes one of those things where players are like, "Yeah, that's the hallmark design here is this very obvious thing." Like, Eddie, I know you're extending your packs, right? Like you said, your packs are kind of recent. Your update 1.1, I think you just dropped today. Has the beach set, the summer set?

Eddie: Yeah, the beach pack.

Kev: And that's a pack, right? You're like, "Okay, we can have this as a pack."

Eddie: Oh yeah.

Kev: Because you could have done it another way, right? You could have just been like, "This is just gonna be in the general pool," or "This is per character," but you were like, "Eh, we'll turn it into one of these add-on packs."

Designing Pack Systems

Eddie: Packs are surprisingly hard to design because—and this is related to the card pool, right?—because ideally they are themed so that there's a direction that it can inform a player to try during the run, but also they cannot be so parasitic. Parasitic as in a set of mechanics that only works with itself. I think the term came from MTG expansions? So a parasitic mechanic would be something like a card that creates chocolate and then another card that uses chocolate as an energy. But you can only use the card that uses chocolate if you have chocolate. So you can't use it on any other card in the game.

The important thing about the pack system when designing a pack was that I had to design the packs as what I call support mechanics. So when designing the packs, I had to make sure that the mechanics that they are exploring already work with the rest of the card pool.

hdh: Is that just because the packs are so small in terms of the parasitic mechanics, or is it not? No.

Kev: Wouldn't it be because—well, it has to work with every character, right? And you don't know which ones show up in each game?

Eddie: But also it's like the reason the packs exist is to create this extra dimension of variety. I think it's important for that dimension. I wouldn't see the point of a pack system, but if each pack is extremely only parasitic and if you build into a pack, you only do that pack. It doesn't—it's not multiplicative, it's just additive in terms of variety, right? I'd rather the pack system have multiplicative interactions. So taking a pack lets you create several different builds, like dozens of builds based on the interactions between a pack and the existing card pool and other packs.

So for example, the beach pack that just came out, it's based—the theming is based on RNG mechanics, like randomness, so some of the cards are like just a tutor for random cards, or cards that mention the word random, right? But the reason I chose to do a random pack is because there's already a bunch of cards in the card pool that are based on random mechanics. So grabbing this pack means that those cards in this pack can interact with a bunch of other cards in the game already. So that's what I call a support mechanic—something that's not gonna win the game by itself, but something that you have to combine with something else to win a game with.

Player Preferences and Balance

hdh: Do you keep data? Do you know—do certain packs have higher win rates than others? Do you have—I mean, maybe you don't want to tell people about that publicly if there are certain packs that are more busted than others or whatever. But I wonder—do people just like, I don't know, are people really biased towards certain packs, or are there certain packs that end up with different win rates? Or do you feel like they're all pretty balanced?

Eddie: I mean, we do collect analytics, but I don't look at them, so I wouldn't know.

hdh: Right.

Eddie: I think it depends on a lot of things. Yeah, it depends on the character you're on because some packs work better on specific pilots than others. Some packs—some combinations of packs are very strong together, but they're not as strong individually. Some packs are just strong individually. So I don't know. I know that there's one pack, the doom pack. That one's very, very good in high difficulties because there's a lot of doom. It's kind of useless in lower difficulties because there's not that much doom, so it definitely depends.

Yeah, it's not an easy answer.

hdh: It's not always the case that the strongest packs are the ones that players wanna play. But there are definitely—I feel like there definitely is an opportunity to run into player biases, right? And I'm sure you see it. There might be people who just, maybe they'll restart until they see a pack that they want, or Kev, maybe you see folks who are—even though it might not be the best unit—always drafting to some unit because maybe there's just some play style that they find that they like or whatever.

There's definitely these player biases that come in, and I guess I would put the question out: One, how do they manifest and do you see them? And then two, do you care or do they matter? I mean, do they matter to what you're trying to do as a designer or the situation, the context you're trying to set up for the player?

Kev: I do think on one level you can't avoid it. People are always going to have favorites, and when people actually compare their tier list with each other, usually you can see stuff that's opposite next to each other. Like one person will be like, "Yeah, the bell maiden's the best character," and another person will be like, "She's the worst." So there will always be people that disagree with this. It's a very subjective thing, and I think people want to pick their favorites. So from that perspective, it's not an undesirable thing.

I think when it could get bad is if it's over-centralizing, and I think that's maybe why Eddie is like, "Okay, yeah, it makes sense that it's support mechanics for these packs and not like you don't put core, powerful mechanics in here." Because it might overshadow the class you're playing as with a pilot or even the whole rest of the packs, right? There's a danger of, "Hey, if something is too strong or it's overrepresented, everything else in the game becomes kind of unimportant." And I think that is definitely the danger of working with so many packs, right?

I think there are ten-ish packs, eleven packs in Star Vaders. There are seventeen units in As We Descend. And the fact is all the units have to work with every other unit basically. So it's a super complex puzzle of every unit has to be viable, but then it kind of has to be viable when any other unit's on board. And it also has to be viable with both factions that you can play as. Is it good early in the game? Is it good late in the game? Is it good on high difficulty? Is it good on low difficulty? It's such a multifaceted thing.

hdh: Do you test that? Sorry, I mean, just to jump in, but it seems like you need a lot of testing or you just have to see things when they're broken when they come?

Kev: I think, yeah, you playtest a lot, right?

Eddie: You do a big vibe check on all the cards and feel your way through. I think at some point there is a bit of instinct that you learn when you're deep into a game on if something is reasonable or not. And it's hard to describe, but sometimes you just know if something's gonna work. And sometimes, you know, if something is way too strong or way too weak or—and it's not really a comparison, but it's more like vibes.

Kev: I totally second this. I think that in design, we so often want to reduce it to a science or a spreadsheet thing because it feels more authoritative or more definitive, right? To say, "Oh yeah, there's this methodology you're supposed to do with it." And it's not to say that those aren't helpful. So much of it is actually really just vibe space. Does this stick out? Does it feel wrong? And once you work in the design space enough, you definitely get a sense that like, "Oh yeah, this is just not gonna work," or "Everyone's gonna play this thing. It's gonna be so busted."

On Design Intuition

hdh: And I would say that the two of you probably strike me as having really strong intuitions around some of these card designs. I think that it comes through in both of the games—they both have quite a lot of depth and complexity and interactions with the cards. And it feels cohesive still. And so that to me seems like it takes a good amount of that intuition. But that's also a really hard thing to tell someone who's maybe aspiring to get into the space or design it—to intuit better or whatever, right? Is there something you could add or what gave you some of that intuition?

Eddie: It's a very interesting question. I mean, I'm thinking about it. You can go first.

Kev: Okay. I think at the end of the day, you gotta roll your sleeves up and just work with it. I know that's not the satisfying answer, but rather than trying to—okay, as a thought experiment, think through the capacity that you're able to intuit through it. As in, if it's not at all, then it's not at all, right? And you just test some numbers and see how it goes from there.

I think everyone's first card game is usually like, "Oh yeah, take a famous card game, you know, and then mess with the numbers or something," right? You make your own Magic set. You customize your Yu-Gi-Oh cards, you make up fake cards, Pokemon cards, whatever, right? Then you kind of go from there. Usually whatever definitive card game you grow up with, that gives you some basic understanding of relationship mechanics and values to each other. Like, does this even work? Does it make sense? How much should be on content versus systems?

I think the important thing to keep yourself intellectually honest about this kind of stuff is also to make theories before you just say, "Hey, let's just test it." I think that kind of ideology rubs me the wrong way also. I know I just said go with your intuition, but I think you have to gut-check yourself and make yourself take a bet on what you think your change will do. Don't just be like, "Ah, let's just wing it and we'll change things and we'll see where it goes."

If you have a change, theorize what your change will do and then make the change. Make the smallest or most incremental change—or however radical you need it to be really—and then see if it gets your goal done. And I think that builds you a solid understanding of the push and pull of things, right? And you'll also start to find out about the secondary knock-on effects when you make this change and you thought that it would only affect this one specific thing and you realize that it's a card game. So everything is super systemic and super complex. So your one change changed fifteen other things. And then when you do that enough, I think you start getting a pretty good understanding of what a small change will do or a specific type of design. Will that push you in this direction or that one? It might not give you the perfect answer, but you at least have a good clue where it goes.

Eddie: Yeah, that's a pretty good way to go about it. I think it does mirror what's going on in my head when I'm trying to design stuff—the idea of theorizing effects of things that can happen. I know when I design stuff, I do what I call playtesting in my head. I go through the process of playing with the card and seeing different scenarios with the card in my head before implementing it just to see if the interactions are fun or if there are problematic interactions. It's kind of similar in the sense that you come up with theories first and then implement. But I also do think that just comes later. You can't really do that when you start the card pool. I think the very first things—when you begin making cards—is just make a lot of cards. Make enough so that it becomes a pool and not just a set. And once you have a pool, then you can start iterating on it. But you need a pool first to be able to iterate.

hdh: What's the difference between a pool and—like when does a set cross into a pool? I mean, is it just words kind of, yeah?

Kev: Yeah. When there's too many for you to feel like you can get all of them, right? I think that's when the set is too big and you're like, "Ah, there's variation in which subset of the pool you see each time." Each time you're testing a build, right? Whatever it is. I think even that process of building the pool will tell you whether your design space is working or not. Because when you have difficulty making the pool—just get the pool done, right? But if you can't get the pool done and you're like, "Wait, I just don't know what to make, what design will work here?" And I think if you're really struggling on that, then maybe there's some sort of core mechanic that's not working. Maybe your design space is not actually correct, right? And I think that's a good signal that hey, maybe some system or parameter has to be changed so that you can have enough space to make this pool, right?

hdh: Yeah, it's interesting 'cause there's a couple things I hear, and maybe it's just from taking a step back. I hear this idea of having a point of view being very important potentially. So basically saying like, "Okay, this is a direction that you want to take the design or maybe a feeling that the player has. And I'm gonna try this to see if I can meet that." It's kind of like a point of view or a perspective on the design. But then there's also this other side, which is kind of like spidey sense. And it's funny 'cause I think about this—I kind of think about this all the time from my professional space. I've worked in large teams building lots of software for a long time, and there's some amount of spidey sense that I feel like I have for organizations and systems and these sorts of things that—it's hard to describe, but you're just like, "Oh that's gonna break something," and you just kind of have this weird hunch.

Trying to put a finger on what that hunch is or where that hunch comes from is like one of the most challenging things when you're trying to go between being someone who's just starting and someone who's more senior at any discipline, I think. That hunch just comes from just doing it a lot, I guess, and also maybe having some sort of success or point of view or philosophy about your approach. I don't know if that makes any sense.

Kev: It does. I think the nice thing about cards is that they're so low risk. I think a lot of parts of design feel complex and hard because there are so many moving pieces. You're in danger of wrecking the whole rest of the design whenever you change something. And surely, of course, you can have cards that ruin the whole experience, right? But I think from a compartmentalizing it down to, "Hey, this is just one bit of design," right? It's one concrete atomic unit of design. I think there is a nice part of that. I think it's quite newbie friendly in terms of just being like, "Okay, how do I even tackle that one thing?" And being able to do it one at a time does make it way easier.

So I think that is the beauty of cards. As much as it is easy to get tired of working on cards after working on cards for so long, and there's so many expectations about what cards are and cards are not. I think one of the great things about cards is, "Hey, it's just a card. It is what it is," right?

Eddie: One thing I think is important for newbies to understand, I guess, when making a card pool is that more doesn't mean better, and do not be afraid to cut out stuff. It's easy to think that more is better for a card pool because it's more variety, more variety means more fun, right? More interactions and everything. But it's not necessarily true. And for Star Vaders, we probably designed a thousand cards in total, and we cut like 70% of them, and we only kept the good ones. You know what I mean? It's a big iterative process, and as you add more, you cut out the bad ones. So then it keeps cycling until there's only good ones left. Don't be afraid to cut out stuff. Even cards that you like or mechanics that you think are awesome. But if they just don't play well, just put it on the side and try cutting it. See if it works or not, and keep iterating.

Pool Size and Density

hdh: I guess it ties into what I was gonna ask, which is, if you were to make a game with a very limited pool and without expansion, is that harder to make fun? I guess I could sense a process where maybe you get into exploration, and you make a bunch of different cards, and then you could just chop, chop, chop, chop until you have the subset of ones that are good, and then that could be your card pool. There's kind of bottom-up or top-down approaches to it.

Kev: I was thinking maybe it doesn't matter that much. Those are not perhaps the important things, right? The important thing is how much gameplay value do you get for each thing you have? What is the density of those? How frequently do you see them and get to interact with them? With a game where you draft much fewer times, then every single card needs to be super splashy, right? And then with a game where you draft fifty billion times, then you probably don't want cards to be super splashy or it throws off the whole game.

So I think design is so context specific that I don't want to throw out a generalism. What I will say as a general thing is you want to really pay attention to what are the systems that are at play there? How complex of a game are you trying to shape? And what fits for what you're trying to do. Does this satisfy your design goal? Right? If it's making people play with the space, then you're probably in the sweet spot. Even if you aren't mathematically in the sweet spot, you could cut or you could add, but maybe that's not the important thing.

This conversation is continued in the next episode where we spoke more about card pools and designing for deck builders and a number of other interesting game design topics. I'd like to thank Kev and Eddie for joining me for the episode and Alex Epton for providing the music.

I'm looking forward to bringing you the rest of the conversation next week!