Magic: The Gathering Drive to Work Podcast - #1028: Databases

Episode Date: April 21, 2023

In this podcast, I talk about one of the most important tools we use for Magic design—databases. I walk through the history of our databases and explain how we use them.

I'm pulling out of the gas station. We all know what that means. It's time for another drive to work. And when I got in my car today, I realized that I didn't have enough gas to make it to work. And once before in the podcast, I've actually gotten gas during the podcast, and it went horribly. So I decided today I would start at the gas station, which is close to my house. I will make sure to get a full 30 minutes. So if I get to work and I'm not quite at 30, I will stay until I get to 30. So you guys will get your full, I don't want to short you of any content. Okay, so today I'm going to talk about an important tool that we use in making magic sets.

Today is all about databases. Ooh, databases, excited tapping. So I'm going to explain what a database is, how we use it, and just, you know, talk about it as a tool that is an important part of making magic. Okay, so essentially, when you think about it, we are making a product. When we make a magic set, we're making a physical product. The end result is actual cards that have to get printed that have art on them and proper rules text with templating and, you know, there is a finished product we are making. So we need something that keeps track of that product because a lot of different people

will work on the product and a lot of different people need to have insight on what's going on. So we need a repository where all the information can be in one place. In addition, we need to have the means to be able to look back and see what changes got made. Maybe we changed a card but didn't want to change it back.

We want to make sure we have a record of what once was. In addition, we want a place where we can make comments, where someone who can see something can go, oh, I want to make sure the person in charge is aware of whatever.

And so we need a place also that comments can be made. So the database is, oh, and there's a lot of different sections of the company, right? So, you know, R&D is busy making sure

that the rules text on the card is what it's supposed to be. But there's creative people that are making sure the names and flavor text are where they're supposed to be. And there's an art team making sure the art is proper. And also, like, there are frames that have to get made. We have to make sure the right frame goes on the

right card. So there's a lot of technical elements of making a magic card. And we need a depository where all that stuff is in one place. We refer to that as the database. So today, I'm going to talk about sort of how we use the database to make magic, and then talk a little bit about the history of magic databases. For all those people that love their database information, I'll talk a little about the history of the magic database. Okay, so actually, I'll start with the history of the Magic Database. Okay, so... Actually, I'll start with the history of the database, and then we'll get into the everyday use of it. So, ever since I started working at Wizards,

from the very, very beginning, there always needed to be a database. There needed to be something that kept track of the cards. So in the earliest days, it was a program called FileMaker, which you guys might know. FileMaker is very good at having, like, pieces of information. You can sort of think, I mean, some ways you can think of them as, like, index cards, right?

FileMaker allows you to sort of keep information on a digital, it's kind of a digital index card. And then it allows you to rearrange them however you want. And so early on, that made a lot of sense. Magic cards are kind of like, you know, they are their own entity. We wanted each card to be something. So when I first got to Wizards, I think when Richard made Alpha, there was no database per se. I mean, I don't know whether it was a Word document or what it was. Maybe he used a spreadsheet. Actually, I don't know whether it was a Word document or what it was. Maybe he used a spreadsheet.

Actually, I don't know what Richard used way, way back when. But that also was Richard was the sole keeper of it. And so whatever form Richard wanted to put it in, it didn't matter because Richard was the only one that was interacting with it. But once you start getting a lot of different parties involved, you need a centralized database to keep track of the information. Now, the earliest database, the original database, we had a guy named Bill DeDrew. What's his name?

And Bill was in charge of managing the database. So the cool thing early on is if there's some functionality that didn't exist that I needed, I could call up Bill and go, hey, Bill, could you do such and such? Oh, you know, we need a slightly more space on the rule stacks. It's cutting something off. Or whatever it was, we could call Bill, and usually Bill would go, okay, no problem. And then anywhere from a day to a couple days, Bill would do it. Now, in the very, very early days, it is possible.

I don't know. As time time went on all the different sections of the company started interacting with the same database I think early in Magic's history that there were different database used by different teams that it wasn't quite as unified so the database I'm talking about was kind of the R&D database which was about what

do the cards do you know the text of the cards. Then at some point, somebody said, you know, maybe we want a bigger database, maybe we want something that's more custom-made, rather than something that is just using

existing sort of software. Maybe we want something that's more, something that can be customized in an easier way for what we need. just using existing sort of software. Maybe we want something that's more, that can be customized in an easier way for what we need. And so that was, so the second database was called Multiverse. And that, they spent a lot of time and talked to, like,

I think that was where the different sections started coming together. Like, originally, I think, like, Art had their own database. And then, you know, maybe frames. Like, different parts had their own database. But the problem there is you want to make sure that the things link up. Like, it's kind of important to say,

we want to make sure that this text and this art go together. And so having all those records be in a singular place was very helpful. And so Multiverse was born. Multiverse took a while to get going. And early on, I mean, I was used to having, like, I could call Bill and make changes, and, you know, it would change pretty quickly. Once you started getting a bigger team, it took a long time.

Not that we couldn't make suggestions, not that they couldn't adapt when they could, but it wasn't quite as quick quick and it was a little more elaborate of a process. But on the upside, it started getting more integrated. So like if the art team got an art asset in, they could attach it to the card so that the

you know, well the way to think of it is let me use art as an example. We're going to have artists do art you know, well, the way to think of it is, let me use art as an example. We are going to have artists do art. They're going to turn the art in. And then we need to make sure that we have the file that is the art attached to the file that is the card, right?

We want to make sure that, you know, we don't want to print a card and have the wrong art show up with the card. Early magic, for those that are fans of Early Magic, there were a bunch of these mess-ups in Early Magic. If Biff Afrit, I guess, was one of the most famous ones. Or, sorry, it wasn't If Biff. It was...

The art was of If Biff. There was an Afrit in 3rd Edition, I think, where the name was on it and the card text was on it, but it was the art of the wrong... It was an efreet. I'm thinking on which efreet. But anyway, it was an efreet

and the wrong art was used on it. So the card we published just had the wrong art on it. It's a famous sort of misprint. And there were mistakes like that early on. I mean, one of the reasons I think the database sort of, the reason for the database became more important is it's easy to miss something when you're dealing with lots and lots of cards and lots and lots of components. And so I think part of the reason for sort of solidifying,

making a more dedicated database was to not have mistakes like that happen. So anyway, we had multiverse for many years. It's funny, the period of time that I, like now I don't really, because my strong seconds sort of do the file, I don't do nearly as much file manipulation

as I used to so my sort of era of file manipulation was the early database and then the FileMaker Pro database and then Multiverse I use Drake, I have a general working of Drake I can clearly look things up in Drake

I don't do as much inputting as I do before. So one of the nice things about the database is when you're managing a file, you can add cards. Or let's say you're repeating a card. You can go find that card elsewhere where it is, and then you can repeat it. So you don't have to type it all out again. And when cards have the same name, that's another feature of the database is if you're using a card name that exists on another card, it can tell you that.

The database can say... Because what happens is when it sees the same name, it assumes it's the same card. So if there's a mismatch between the name and the text, it'll say, this card is, you know, this card is not correct. That is not the text that goes with this name. And so one of the things when you have 25,000 cards, it's very easy to name a card something that we've already named a card. It's very easy to do that. And so one of the passes that editing used to do is they used to

go through and double check. But I think, I mean, they probably still do that path. But the database now has some tools to help catch that. And so there's a lot of, like, one of the things that happens. Sorry, let me finish my story of history. So we had Multiverse for many, many years.

And then we decided that we could do a little bit better than Multiverse. I think there's more integration that wanted to go on. I don't know on the technical side why they needed to change, but they did. So we changed to the latest, our current Multiverse, sorry, our current database is called Drake.

And so they spent a lot of time. So each team had individuals that were dedicated to the project. and so they spent a lot of time, so there were, each team had individuals that were dedicated to the project, and then, for example, the R&D rep would come to us and say, okay, what do we need? Like, what functionality was really important in Multiverse?

What functionality did Multiverse not have that you would have loved to have? And that, for example, the names, that's a good example where I think Drake now looks at names where I don't think Multiverse ever did that. But anyway, we sort of talked about all the different functionalities we needed. So let me talk a little bit about the basic functionalities of sort of what we have.

So first off there is where you put all the component pieces. And they're all broken up. So each thing is its own file. So color and number and rules text and name and flavor text and art ID and all that stuff. So everything has its own. And the reason for that is one of the things that's really important for databases

is you want the functionality to be able to look things up. So let's say, for example example we're trying a new mechanic I want the ability to just print cards that only have that new mechanic. So to do that I could search, it's got a search function, so I could search for that word in the rules text. I could search for a super type or a subtype or I could search for a color or a rarity. You know the database allows us to just look at the thing we want to be looking at. And oftentimes when you're doing magic designs, you know, you're focusing on a certain aspect. So it's nice that you can just look at that aspect. Mechanics are really a common example

where, hey, I just want to see the cards with this mechanic so we can see what cards are what color at what rarity and we can figure them out. Other times it's like, oh, I just want to see what the white uncommons look like. So it lets you do that. So anyway, everything's its own field. And that's important so that you have the ability to search the things you want. Rarity is a separate field from number. As I explained before, let me explain card codes really quickly. The way we identify each slot in the set is there's three components of it. One is the rarity. So normally that will be C or U or R or M for common, uncommon, rare, mythic, rare. There are other rarities. Land has a technical rarity. Basic lands are the land rarity. There's a token rarity. When we have bonus sheets, sometimes the bonus sheets have their own rarity.

So, first is the rarity. Second is, we like to call it the color, but secretly it's not the color. It's the frame. So what that means is, well, actually, that's a little incorrect.

Essentially, the color says where are we grouping it. And either you are W for white, U for blue, B for black, red for green, and G for green. I told this story before, but I guess I'll explain it real quickly. The reason blue is U and black is B is blue and black can't both be B. And the next letter in a row for both of them

is L. L is used for land. So if something is a land, we use that. And then there's A or U. And A we use for artifacts, so we use U for blue. We later realize in printing they use B for blue and K for black, but we didn't for blue. We later realized in printing they use B for blue and K for black,

but we didn't know that. So WUBRG, W-U-B-R-G is the order, and we refer to it as WUBRG. Anyway, so the next number of the slot is either white, you know, W-U-B-R-G. If it's multicolor,

it's Z, and Z represents all the multicolG. If it's multicolor, it's Z. Z represents all the multicolors. If it's an artifact, it's A. Although, if it's a colored artifact, it'll get the color, not artifact. Artifact means it's an artifact and a colorless artifact. C will mean colorless if it's... Oh, no, no, C, yeah.

C means colorless if it's colorless but not an artifact. And L will mean land. T is token. Anyway, and then there's a number. So WC01, or sorry, CW01 means common white for slot. One of the things that we do when we make the database, sorry, when we use the database is sometimes we have things where we have to orient cards. We're like, it's a double-faced card and

each face gets its own slot, but we want them connected. And so there are tricks we use. For example, we do what we call 99ing, which is if we have a card that's in the file that we don't want sort of officially in the file, but we want there because maybe we want to pull it back in, we do what's called 99 it, which means you just like CW99, which means this is a common white card, but 99 means not in the file yet.

Oh, so one of the functionalities of the database is we want the ability to be able to print up cards. I did a whole podcast on our stickers and our playtest cards and all that stuff.

So we want the ability, so it's really smart. In the database, you can build decks. So Play Design wants to build decks to playtest with. And it also can handle doing outputs for sealed.

So let's say we want to have a sealed playtest. And then that way you can output things and it goes to our printer and then you can print the cards. If you want more detail on our playtest cards, I did a whole podcast on our playtest cards. Anyway, so there's different codes that you can use. And then every part of the card is broken up. Names is its own slot. Rules text. So super type, and then type, and then subtype. And then there is rules text. There is power. There's toughness, there's loyalty, if it's a planeswalker.

And then there's a lot of additional fields that are, there's a field for the frame, there's a field for the art, there's a field, what we call the art ID, which is every piece of art gets a number associated with it that's unique to that piece. So the art ID is in there. We do a lot with frames. I talked about how if it's an artifact but a colored card, it listed with the colored cards, but we have to indicate somewhere what the frame is. So there's a thing for the frame. There's just a whole bunch of, and there's a lot of technical things of caring about individual stuff. Also, there is a place for notations. Dev notes is what we call,

what R&D writes in. It's short for developer notes. We don't really use the term development as much anymore, but that's where it comes from and it's sort of been, I don't know, it's stuck. And there also might be templating notes

or editing notes or just places for different things if people want to comment on other stuff. Part of the idea is we want the database to be the repository where everybody can sort of have discussions and talk about it. And then one of the neat things about it is you know, let's say we do what we call file pass. So we might say to people, hey, could you guys do a file pass? And what that means is usually it's somebody not on the team, although sometimes team members will do file passes.

Well, team members do do file passes. Usually if I ask them to do a file pass, usually they're external to a team. But what that means is, hey, go look at the database. And then if you have any notes on anything, write the notes in the dev comments. And then it allows the team to see what outside people are thinking. One of the things that if you're not on a team, we like if you can sort of poke your head in from time to time and just give some comments. It's nice to have outside people that aren't, you know, when you sort of get in the weeds sometimes you can miss the forest for the trees. Like you can maybe miss that you're not doing something. But an outside person can come in and say, hey. It's also the

place where, like, maybe there's comments about, you know, usually there'll be, the way we do, we do names that aren't final is normally if they're not final, they're in brackets. And so if something's in brackets, if something's not in brackets, that's like, well, we think this is the real name. So people can make comments on the names. Sometimes, for example, the name implies something due to magic slang that isn't true. So we want to be careful not to make players think the card does something it doesn't. Sometimes maybe there's something about the name that is inappropriate. It's very easy, for example, to be very in the context of magic

and not take a step back and go, well, there's a meaning external to magic. And we want to make sure that we know that. And so we want to be careful about that. You know, flavor text will go there. People can comment on that. And people can comment on, you know, what's the creature type? Oftentimes, there's somebody on the creative team who does a pass on the creature type. Or maybe they haven't even done the pass yet,

and the design team is just, they've stuck whatever they think it might be, and there could be notes about what we might want to do with the creature type. So the database just gives a lot of people the opportunity to go in, to look, and to provide feedback in a way that is structured that people can see. The other thing that's nice about the database, so, back in the day, the way that meetings

would be run is we would print up the file, so that everybody would have their copy of the file, and then meetings, we could go through the file and take notes on things. Nowadays, we have their copy of the file. And then meetings, we could go through the file and take notes on things. Nowadays, we have, you know, screen technology and also we're sort of hybrid.

So usually now if we're talking about something, it'll go up on the screen. We can, you know, whoever's running the meeting can log in and be part of the screen in the meeting. And then they can show what's going on with the, they can show what's going on with the, they can show what's going on so people can sort of physically see the file. Another thing that has happened, I say recently, but it probably has been a couple of years. There now are means in the database

to show you what the card would look like if it was a finished card. So what we've done is there's a viewpoint where it says, okay, it puts the frame on it at, you know, that we put all the frames in so that you can see something that's close to what the final frame would look like. If the art is in, you get to see the art. The art also, the other thing that happens for art real quick is we give the artist art. The first thing they do is they make a sketch. And then the sketches come in. And then the art directors make comments on the sketches.

All this is also done, I believe, in the database. And then once the artist gets the notes on their sketch, then they will do their final version of the art. And then when the final version gets in, that ends up going in the database, gets scanned and everything. So one of the things that's nice is that we can see late in the process,

like one of the latest meetings we do where we do a pass where we look at the cards and we want everybody to make comments on them. But when we're looking at the cards, there are names that we comments on them. But when we're looking at the cards, you know, there are names that we think are, you know, we think these are the real names and this is the art and here's the templating we think. So it's a chance for us to look late in the process. Now, it's not so late that we can't make changes. The whole point of it is we're showing more eyeballs this to get a sense of, and a lot of times the people looking at it. For

example, I work on a set very early in exploratory and vision design and then i hand off a file now i'll peek my head in once in a while i might do a file pass i i'll do some play tests um but it's not really until that final sort of look look at the cards where i'm seeing everything all together you know i'm it's one when you're really enmeshed in the file, you become very connected of all the component pieces. But usually it's not until that final sort of slideshow that people are sort of seeing it all come together that aren't, you know, like the lead of the set is very, very familiar with the component pieces.

For example, I did the set design for Infinity. So late on, I would see art as they came in and I would get a sense of what's going on and I would make notes to Dawn, my art director, like when sketches came in, if there was any issues that needed to be addressed. Like sometimes, for example, the reason the set lead will make notes

is that the art kind of contradicts something mechanically about the card. Like it implies something. I'm like, oh, well, that implies this and that's not really true. So usually the set lead will make some comments on the art.

We don't make a lot of comments. It's never about the quality of the art. It's more about, oh, is the art implying something that just the card isn't doing mechanically. But anyway, when I was in charge of that, when I was the set lead,

you know, I would be very, like, I was looking at names and flavor text and the rules text and the art, and I was thinking very much in holistically, like, one of the things that happens, and I've talked about this in my flavor text podcast, that flavor text, names and flavor text are the last thing to be done,

and so normally when you get to that part, the rules text is mostly locked in and the art is done, hopefully, usually. And so sometimes what happens is, let's say the art and the rules text are not in perfect alignment. It's usually the job of the names and flavor text to help make it feel more connected. the names and flavor text to help make it feel more connected. And so a lot of times, you know, there's clever things you do where you, you know, you try to get a name that both feels like it connects to the art and feels like it connects to the rules text. And if you do that, or sometimes flavor text, you really can make the card more whole together where there's elements of it that in a vacuum don't see as connected. And anyway, it's important for us to see something. So it's really nice.

The functionality to see the finished version of it, we haven't always had. I think that's something we had asked for. So in the late stages that we can see it. Anyway, I'm glad we do because it's a really nice feature. And it definitely helps in those meetings to get a sense of the total card. One of the things that's really a challenge for us is because we deal with the database, we don't really,

we don't see finished cards until they're printed. And so this lets us sort of see them a little bit earlier and it's just cool to see a magic card as a magic card. There's a lot of sort of raw instinct that comes in it and sometimes you can call out things and that's at a point where we still can make changes. So that's cool. Anyway,

I try to think of other elements of the database. We use the databases in almost every meeting and it's really interesting in that I think back to the days of our, like our sheets of paper that have the file. And we all would be reading together.

And then usually the rule was the person who was the lead would take notes. And then their job after the fact was to go put all the changes into the database. So normally you would run a meeting, you take your notes, and then you go have the file reflected. The cool thing now is because we're literally interacting with the file in the meetings, we can make changes in the meetings. And that is another upgrade.

And also if you listen to my podcast about play, like they've already made playtest cards that's been upgraded. So there's a lot of, we've made a lot of incremental gains and there's a lot of ways now to use the database to check things and cross-check things. The other thing that is nice is it is also a database. So let's say, for example, we're doing something new, or let's say we're bringing back a mechanic and I want to say okay I'm curious what

we've done with that mechanic so I want to look at what we're doing with the mechanic plus what we've done with the mechanic so the database has every single magic card in it from the past as well and so that allows you to do searches um now there are external databases that people have you know the gather we have there's other, that let people look at everything that exists. But when you're making a set, we need to look not just at what does exist, but what we're making. And so our internal database is the only place that we can do that. So, you know, if we're bringing back Mechanic X, and I want to say, oh, well, what else are they doing? I can bring up all the things that any card we've ever done that has done that,

and I can look at it and compare it to see what we're doing now. And it's nice to have the ability to do stuff like that. So the ability to have a database that can look at old and new is very valuable for us. Also, sometimes, like I know when I'm doing names, sometimes I will pull up cards to see what names we've done. But because we were two years ahead, it's very valuable to make sure that I'm looking at what are the names of the next two years that haven't been released yet. Because another problem we used to run into is you would do a search on Gatherer or whatever and not copy a name that we've already printed

but you might copy a name that's about to be made. And now we can capture that stuff as well. Anyway, I know today's funny when I ask people what they like to hear about a lot of people like to hear about a lot of different things. This is mostly

today about sort of, I don't know how much you guys think about the database. Probably most of you don't think about it at all. Although the public does interact with their own version of a database to sort of see the card. So like it makes sense, you know, that there's a lot of useful ways to use the database external to wizard. So hopefully you can extrapolate all the cool ways for us.

But on top of everything else, there's a lot of tools that we need, um, that aren't necessary tools that are needed externally. Um, the biggest is magic cards. Once they're printed, are printed, they're done, you know, so an external database, um, and our outside database is mostly about, well, here's what is, and that's what it is. And it's kind of locked. Where in internal database, we are making cards that are constantly changing. And so the flux and the ability to deal with the flux and... Oh, the one other feature, by the way, before I go, I'm here, but I promise you my 30 minutes. Another feature I use a lot is there's a history feature that will show you every change the card got made. So when I do my articles where I go back and sort of talk about the changes the card,

I can go back and look at that. I use that all the time. The only quirky thing about it is the way it works is it tells you every change. So you have to sort of track along and figure out what's where. So there's a little bit of like detective work that has to be done. But I've gotten good at it because I've done it enough. But it is nice that I can share sort of the history of the card and all that is, well, I can share the history of a slot.

The thing that gets tricky is the database only tells you the history of that slot. So sometimes if a card changed slots, which can happen, usually, by the way, the slot can change. We can change the rarity or the color. Like if you want to have the card and just move the card somewhere else, you can change the elements of it and it'll stay the same slot as far as the database is concerned. But sometimes you'll remove something and put it back in, and when you put it back in

you don't put it literally in the same file that it was before. So sometimes when I'm tracking down things, I have to figure out, I can only see the history of any one slot. So sometimes when I'm tracking things down, I have to figure out if it changed slots. And that can be the real detective work and get a little trickier. Anyway, guys, I hope you were entertained by the talk of our database. And like I said,

a very important tool, and hopefully this was an insightful look into how we use it. But anyway, guys, I am now at work, and it's 30 minutes. So we all know what this means. It means it's the end of my drive to work. So instead of talking magic, it's time for me to make a magic. I'll see you guys next time. Bye-bye.