 square foot of my house that shouldn't be a dining room, but is instead a shrine to board games. The thing you see in the middle is not a table, it is an altar. I even have a little prayer booklet that I keep on my phone that tells all the times I've ever offered up a game to the gods. Yeah, it's a little bit ridiculous. I love board games. I love what they do. I love the social aspect of them. I love how they let me connect with people. And this is a talk about board games. It's a talk about board game design. I'm not a board game designer, but I became interested in it and I want to talk to you a little bit about that. I also want to talk about the process of board game design and then I want to talk about what we as software developers can learn from board game developers and more game development. Take us off. Let's look at the specific game. How many of you have ever played code games? That's a good game, right? If you were there last night, there was a couple people playing various versions. I even saw somebody that had a signed box from the creator, which was pretty cool. But code names is a really great game, right? It's very tight. It's very well done. And if you haven't played it, it's basically two teams where one clue giver is trying to get the other members of their team to guess which of these 25 words he's talking about or she's talking about with a single word clue. So if I wanted to say, hey, I want you to guess horse, dinosaur, and fish, maybe I would say animal and then conveniently have forgotten that the dog is right there and you click the dog and then I'm going to lose. That's fine. It's a really cool game. I've never played it with anybody that hasn't wanted to play it immediately afterwards. And the first time that I played this game was like, man, this is so simple. Why did I think of this? This is great. I mean, it's the game of the year. And in contrast to that, there's this game. This is Mage Knight. Mage Knight is one of the most complex games on or game 8.com. It has one of the highest complexity rates. It's you're playing one to four heroes. You can be collaborative or competitive. You have 11 different scenarios that you go through. You're exploring all of this different land. You have to manage your deck of all your different things. It's like there are so many mechanics and ideas in this game. It's absolutely insane. The only reason why I really bring it up is because when I saw this, I thought how did anybody ever think of this? And it turns out, actually, the same guy thought of both of them. This is Vlad Yeshvato. He is the creator of both games. And when I saw his name on the side of both of these boxes, I was kind of amazed. Like, how did one person come up with these very different, very distinct ideas? And so that actually got me into the whole notion of like, what does it take to design a board game? And in a lot of ways, I was kind of surprised because he probably went through a very similar process for both games. I got really interested in how he did it. It also became interesting to me that, you know, the game like code names, you know, it's simple, but simple games can take just as long to develop and really, you know, make right as, you know, really complex games like Mageshine. So let's talk about what a board game is. For the purposes of this talk, we're going to find a board game as a set of rules and the needed components that deliver a fun and or interesting and or challenging experience for players. There's probably other things that fit into this category that you could say is kind of like a board game. But for this talk, this is kind of what we're going to be talking about. So that's what a board game is. How do you even start like with an idea for a board game? Where does this come from? Power of work? As a board game we can see. Inspirations can really come from anywhere. There's lots of examples of inspiration in a lot of ways. You can be inspired by theme. If any of you have ever played the pandemic, I know it. Yeah? Oh yeah, good chunk of the room. So it's four scientists versus all the viruses in the world. And when Matt Leacock decided that he wanted to make a game, he decided he wanted to make a game that was a system spirally out of control. That is the game he wanted to make. That was the theme and the inspiration for the game. Right? Who wants to make a game like that? That's not, that's not a thing. That's not like, oh, I really want to make a game about mites, or a game about, you know, space, whatever. No, a system spirally out of control. You can find, you know, inspiration from anywhere. He also found inspiration from the mechanics, though. There's a point in the game where the bit happens where you, you know, have an epidemic, and there are all the cards that indicate the cities you've already infected with all these viruses that you then shuffle and put back on top of the deck you're about to draw from so that you can infect those cities once again. Right? And it is, it is that moment when all the tension happens, and it's that moment when Matt Leacock realized that he had a game on his hands. So he found inspiration in that. You can also find inspiration, like, from the mechanic in the sense of, say, somebody wanted to just make a drafting game, and they noticed drafting is just whenever you pick something out of a set of things and then pass what's left to the next person and then you get the next set of drafting. And somebody goes, that's kind of like the conveyor belt at a sushi restaurant. And so they made sushi go. You can also just be inspired by your audience. I can say, hey, I really want to make a game that my kids will play. I really want to make a game that my coworkers can play at lunch. I really want to make a game of horrible people. Right? I mean, this is basically apples to apples, but you're not ever going to bring this out with your grandmother unless your grandmother is really cool. Right? It's a different, it's a different kind of thing and it's like based around the audience. So you can find inspiration from anywhere. And once you have inspiration, you really just need like some building blocks put together. So what are the building blocks and what are gates? First, there's really, there's really two different kinds. There's a rule building blocks or the mechanics. And there's a bunch of different kinds of mechanics. Oregon Geek, which is just a heavy website, lists over 15 different types. And you can probably find more, those are probably broader categories. But you also need things to represent states. And these are just the components. What you'll notice about all these different components, is that they're really simple. They're things that you probably have around your house in one way or another. You can find the more expensive components. You can find the things that are harder. But these things are really easy. And so there's something unique and distinct about that, especially for board games. So we've got rules. We've got components. Now we have to ask ourselves, is this fun? How do you know if the game is fun? Because you can't tell. I've learned this from trying a couple board games out on friends and it didn't work very well. The way that you find out if it's fun though is through playtesting. And that's really what I really want to talk about today. So what is playtesting? Playtesting is the primary way that you're going to be able to evaluate and improve your game. It's like, it looks a lot like testing that we're familiar with. You have an idea. You implement it. You play that idea. You observe the results of it. Your brains know how to make it better. You keep going. Over and over and over again, right? The tighter the cycle, the better. That's what playtesting, that's how playtesting works. And so when you're ready to start playtesting, and some people say, hey, how long do I have to be working on a game before I start playtesting five minutes? You start playtesting with yourself right whenever, as soon as you possibly can. Because the first phase of playtesting is just your ability to, your design phase, and you're just trying to improve the viability. I actually did this with some co-workers. They indulged me at a retreat where we all got together and we did like a 45-minute session where I had them basically invent a game. I gave them some paper. I gave them some dice, some tokens, and some index cards. It said, I want you to make a race to the end-style game where everybody has a token. They all go on some path and the first person to the end wins. Whatever that is. You define how they move. You define how they interact. You define what happens. But that's the basic mechanic. And they didn't spend 40 minutes thinking of a game and then play it. They were playing a game within five minutes. The goal was to get from their brain to reality as fast as possible. They're drawing out something very quickly. The thing that made them able to play the game four or five times in that, and that was really, really short period. By the end, my friend Chris here in the middle said he forgot that he was designing a game and just wanted to play it. It's really cool. Going back to Pandemic, Matt Leacock actually published his very first map of Pandemic. This is clearly on a sheet of paper. It's actually, you probably can't read it, but it's also got markers on each of the different nodes and they correspond to the different cards in a standard 52-card deck. He didn't use special cards to break anything in particular out. He just used the deck that he had and said, hey, I'm going to try this out. I want to see how this works. And he started playtesting this idea. And he found out what wasn't working. If you've ever played Pandemic, which so much you have, you know that there's not really any difference between all the different connections between places. And he clearly has blue and red connections and even some double connections here. And those mechanics got pulled out of the game. Because yet again, figuring out what a game is is an exercise and mostly saying no. And what you're proving during this design phase is just, hey, do my mechanics work? That's my big idea work. And when you kind of get to the point to where it's starting to all click a little bit and you really don't want to go any further without maybe a UI that some people might be able to appreciate even if it's just printed out on some paper, then you're ready for phase two. And that's got to playtesting. So got to playtesting is just, hey, I want to determine how other people are going to play this game and figure out what needs to be tweaked to make it more fun. Actually have a co-worker, his name is Jason Carr, who is a game designer for GMT games. I found this like infinitely fascinating. He was super helpful for this talk. And if he talked to me about how he does guy to playtesting, he'll go and sit down with people and say, hey, I have this new cool game because I got to sell it. And he says, we'd like to play with me. And as people go around, sometimes in the middle, he'll see, you know, a time that they're not having fun or a time that they're frustrated. And they'll say, okay, let's try this. He'll take a card out. He'll turn it over and write something new on it and say, let's try with this for this next round. Oh, that worked a lot better. Cool. I have a new data point. Now I can try that in a new game. So you're finding out if people have fun. This is when you're answering that question, right? You are absolutely testing the user experience at this point. This is one of the times that I was really impressed with what board game or with what playtesting could do because it really helps you figure out the things that are working in not just on a mechanical level, but on a user experience level. And once you get to the point at the end of the game where people are saying, you know, I want to play that again. I really like what this game is. I think I understand a little better. And now I want to play it. That is a great time for you to move on to the third phase, which is blind day testing. The goal here is just, hey, can people who are completely unfamiliar with this, you know, take it and play it? Because that's what's going to happen, right? You're going to sell this as a box. You're not going to sell you going around to a bunch of houses and showing them how this game works. The primary thing that you're trying to do is find out if they understand something. You know, can you read the rules? Is it understandable? Is it good? But also is it complete? Could you remember all the edge cases? Are there assumptions that you made? And this is, I've kind of like set this up as kind of this big, long, you know, waterfall type thing, but it's not. It's not quite as clean cut as that. There's a point maybe during blind day testing when you realize, oh, there's something wrong with how this works. I need to go all the way back to design for a little bit to kind of like work through what this needs to be. So you can go back and forth in these phases. It's not completely, you know, one thing to the next, just like it is. There's some, like I said, there's some blurred lines here, but there's not just blurred lines between the phases. There's also blurred lines in what you're testing. You're not just testing one individual thing. This is not unit tests, right? You're testing the overall player experience. You're testing the general thing. And you're testing the UX. You're not testing the UI, right? You don't need great UI in order to test this and make sure that your game is fun, right? UX can be tested without a pretty UI. In fact, you can even ship without a pretty UI. This is an example of that. This is a game called Glory's Grown. The top image that you see is the original printing. It looks like crap. There's basically a bunch of clip art with none of the backgrounds match. It's crazy. It's a top of the game. People enjoy playing this game. They have a great experience here. It just doesn't look good. So somebody else said, hey, I'll do a Kickstarter and we'll reprint this where it actually looks good. That's what the bottom image is. What you can test is for UX is without good mechanics. You actually have to have solid mechanics in order to really hit this up. So let's start to get into what I want to get at. What can we as software developers learn from game development? So first off, I think we can learn that inspiration can come valuable to remember that you can be inspired by your co-worker, that you see frustrated right there. I think it's valuable to remember that you can be inspired by someone in the board game that you play that you're like, oh, this was pretty cool. I think it could actually do something like this in the UI or the interface that we're dealing with right now with our users. There's no such thing as an invalid inspiration. I also think it's really cool that simple tools can tell us a whole lot. You don't have to spend two weeks developing something before you get it in front of a user, before you even start to test it and find out what the user experience is like. In fact, you know, maybe you can do it with, you know, come up with some prototype and maybe that takes you half an hour. Maybe you can use a piece of paper and jot down a UI and go take it over to a co-worker's desk and say, if I showed this to you on the screen, where would you click? What if you could get done in five minutes, like answer some of those questions in five minutes? Rabbit user testing is possible even early in a project. I think that we as computer engineers often forget that. We think that we have to have it looking closer to an end product before we get it in front of the user. It's also valuable to remember that saying it pays huge dividends going forward. This is true not just for your, not just for the user experience that you have, but also for your application, right? When you say no to things, you have a lower carrying cost and over time you're actually able to deliver a better user experience to your users because they're not having to deal with so many things. You're saying no so you get down to the essence of what your product needs to be. The other thing that I think is really interesting is that UX and business mechanics are way more intertwined than we think they are. I think that we tend to think of like, look, I'm implementing this thing that has to be this way. Let's make the UI make up for the bad user experience. UI isn't UX. They just supposed to have user in the name. If you are a back end developer, you have just as much responsibility for user experience as the UI guy. Maybe more so. And it's your job in fact to push back on those things to say, this is going to give the users a bad user experience. Just to give you an illustration in the software world, if we did this, he was at a conference where everybody's going to their talks and they were doing something silly where you could go and get a caricature made of you. So, instead of having everybody wait in line, they let them use an app. This doesn't have any particular, there's no CSS, it looks really ugly. But it totally serves a purpose where everybody still gets to go to all their talks that they want to go to. And they still get to have their thing. Maybe they would have just skipped the caricature entirely that you paid somebody to come to your conference to be weird. Just for no good reason. This was great UX and bad UI. We need to remember that. We need to think about delivering UX first before we even think about the UI. And finally, whenever you are there, you're thinking about delivering stuff to people. How much do you think is it fun? Are you delivering a fun experience for people? Are you delivering an interesting experience for people? Are you challenged? I remember my co-worker who said, hey, I stopped thinking about the game that I was designing and I just wanted to play the game. He was really just challenged. It was really just a challenging process for him. You can be challenged too. And if you're not challenged, why not? What can you do about it? And finally, are you improving people's lives? Board games improve my life. I have a better life because of it. I connected people because of it. I connected with strangers last night at the board game thing because of it. And I think that we as developers have the opportunity to improve people's lives. Maybe you're doing expert use software and you can improve all the people that you work with for internal stuff. Maybe you're making people's lives better because they just don't have to have as hard of a time submitting expense reports. Whatever. You're thinking about that and trying to make their experience a little bit better and make their lives a little bit more delightful. Thank you very, very much for having me. Again, my name is Mark Simonin. You can tweet at me at Mark Simonin. I do work for Citrix and we are hired. If you are interested in working for a place that thinks about their products this way, it gives engineers the autonomy to do this kind of stuff and think about things and push back and say, look, I work for this to have the best experience for from the people that are using this. You can come talk to me afterwards if you can talk to us in the booth. Thank you very much.