 So, as Jim said, my name is Jonathan Bergman, and I'm here to share the story of how I build a board game and how Ruby relates to it at all. Now, I'm not going to talk about digital board games with actual physical board games, so I hope you enjoy the talk. So I'm a tech lead at the eBay Israel Innovation Center down in Tel Aviv, and we build cool projects for eBay, mostly using Ruby and Rails. And I wanted to not click that button, but I wanted to start off with this short intro to board gaming, because I'm guessing that when I say board games, some of you think of this, or maybe this. But board games have changed a lot in the past 20 years. I want to have a quick show of hands. Who here has played a board game in the past year? Whoa. For the past month? Not bad. Today. So there's a current revival of board gaming as a hobby, and more and more people play board games each year. Now modern games also have a very wide variety of both mechanics and themes available to them. From Settlers of Catan, which was considered the grandfather of designer games, it's a game where you race to settle an island, competing with the other players for resources, but never actually fighting them. Carcassonne, a tile laying game where you have to build a medieval city in France, and Ticket to Ride, which is a set collection game where you lay railway tracks across the US and try to block off your opponents. To lesser known games like Agricola, a work replacement game where you build a farm and harvest food and try to make sure that your family doesn't starve over the winter. Galaxy Trucker, which is a really crazy game where you build a spaceship using only one hand, fly through space, and you get a seat, get pulverized by meteors and aliens and pirates and so forth. And The Resistance, which is one of my favorites, a social deduction game with no physical parts at all, where you just accuse your friends all the time for being spies, all the while hiding the fact that you were one all along. So there are many other examples of awesome board games right now, but all of them have in common that they bring people together around the table. Now board gaming as a medium is unparalleled in the way that it has both a competitive gaming aspect as very social interactions. We're now in a golden age of board gaming, as people say. Since 99, sales have been growing at a rate of 10 to 20% each year, with the amount of games published growing accordingly. From around 500 games published in the year 2000 to more than 1,000 new board games published last year. That's a crazy amount and a lot of copy pasting to get the graph there. So let's talk about how board games are made. I'm going to generalize the process. It's not the same for all the games out there, but it should get you an understanding on how board games are made and what is required to produce a board game right now. So we start with a designer. That's the person who invents the game. Usually the one whose name adorns the box when it's ready. So they come up with a basic mechanics and rules of the game that iterate through the rules, several different iterations, and they usually add a theme to the game, whether it's a farming game or racing game, a giant monster game or whatever. They will go through several iterations and have a prototype ready to show the publisher. While a designer is usually one person or a small group, a publisher is usually a bigger company that will help produce the game. The designer will show the prototype around to several publisher and get one interested in buying the rights to the game. Then the publisher takes the game to its internal development team. Now these are not programmers, even though they're called developers, but people who are in charge of getting the game ready from the raw state so it's ready to print. They work with the artists and the content writers on getting all the assets ready. They set the final game rules and the final theme. They might even change it based on the other games that the company is currently producing. And they do a lot of player testing during that phase. This is an iterative process when they try to iron out all the bugs out of the game. There are many different ways to play test the game right now, open, closed play testing and even something called blind play testing where you just send out a game to a group of people and you don't help them at all and you just get feedback in the end. So after the game is ready for print, it's sent to the manufacturer. So let's talk about cost for a second. When producing a video game or an app, usually the cost is in the upfront when you're developing the game or the app. Getting multiple copies out there once you're done is relatively cheap or even free. But when you're producing a board game, each physical copy that you produce has costs in both materials, production, and shipping and storage, which is something that you don't necessarily think about. So you see producing a board game is a complex process involving many different people. And to get a game out there, you need a lot of help. Luckily, things have been improving over the past few years. Kickstarter, the crowdfunding website, has been a real game changer in the scene. It enables people to get their games out there and fund them without needing to find a publishing house. For the past four years, the tabletop category in Kickstarter has grown from $100,000 in 2010 to over 30 million collected for board game campaigns this year, which is crazy. It is worth noting, though, that with so many games now relying on Kickstarter to get produced, one out of every three campaigns fails. Another cool way people get games right now is using print and play, which is essentially open sourcing board games. People who come up with games publish the rules and all the necessary things you need to play the game online. And you as a person can just go online, print out the parts, whether it's cards, boards, whatever, and just play the game. This is widely used when doing play testing because you don't always have access to your testers. So you can just send them a PDF and expect them to print out the rules and play the game, which is really, really cool. So this was just a little taste of the board gaming rule right now. It doesn't, I didn't touch everything out there, but I hope you could see that board games has a parallel to developing software, which was probably one of the reasons I was naturally drawn to building a board game as a side project. A couple of months ago, I had an idea and I started designing my first board game, which I call Missiles and Microchips. It's this one here. Missiles and Microchips is a sort of cross between poker, a game I used to play as kids called standoff, where you point the gun fingers at each other, and some game theory mixed in. In the game, you play a rogue supercomputer trying to take over the world. But to do so, you have to fight the other computers out there. Each player starts the game with five energy points, which are both your life and your score. The object of the game is to be the first to reach 10 points or the last player standing. At the beginning of the round, all the players simultaneously select an action and a target from their hand. Everyone has the same available set of actions to them and targets representing the other players. Everyone then reveals their chosen target. Starting from the start player, each player can change the hidden action that they chose, but pay one energy to do so. But it's really great if you're trying to bluff someone out or if you see that everyone's ganging up on you. Players then reveal their chosen action. You can choose between three different actions. Attack, if successful, will remove one energy from your target and disable any charge that they're trying to do. Block protects you from incoming attack, hurting your attackers, but it will cost you one if used when no one else is attacking you. And charge will add one energy to your pool, a way to heal yourself up. Now each action interacts differently, depending on who you're doing the target of action on, what their action is and who in turn they're targeting. All in all, there's 18 different combinations between two players in a given round, and when you combine that with the fact that everyone is playing simultaneously, it creates very interesting interactions around the table. So after resolving the actions, players update their energy. If someone won, we stop the game, hooray. Otherwise, everyone takes their cards back, the starting player token moves, and we go through another round. The game continues like this until one person reaches 10 energy points or all players but one are eliminated. So those were the basic rules of the game, and now for the interesting part, I wanna go through how I got the rules. So it all started one day during lunch. I was sitting with one of my coworkers who's also into board games and game design, and I was sharing the idea for the game I had with him. I told him I was having issues with then deciding on how the actions interact with one another and the specific numbers. We talked about it and we came up with the idea of writing a simulator in Ruby. So I went to work on that first version that night. The first version was very, very simple. You would just input how many players were playing, and I had all the basic building blocks needed to simulate a game, whether it's like the game, the round, the players, the cards, and all my players were completely random. They would just select cards out of their hand using sample, and I would print out whoever won the game and how long the game took. My next version saw the inclusion of winning by reaching a certain number of points. To do so, you just input the starting energy for each one of the players and the amount of energy required to win the game, and you could get another simulation. You could see that then the output I had was very, very verbose. This is truncated because there were 47 turns in that game, but that was because I was simulating just one game at a time. So the next thing I did was naturally wrap it so that I simulate multiple games each time. This was to give me a more statistical outlook at how my game is playing as a whole. I started to look at how long a game lasts given the current random nature of my players in the system. I would print out the average number of turns and how many times each player won. My thinking was that if the players are completely random, each one of them should win roughly the same amount of times. Now, the most important class in my code was my action resolver class. It receives the board states for a certain pairing of player and target, and it returns a result of the change of energy required for each one of the two players. The action resolvers were instantiated inside a round resolver class that would resolve the actions for each one of the players and their relevant targets, sorry. And in turn, that was run inside my game round class. Now, the code for the action resolver was written in a way that enabled me to easily play around and change the rules of the system. It was really important for me that the essence of my rules, the interactions between the different actions on the table was both easy to read and easy to change. I had a sort of DSL written out to show how each action resolves. So one of the first changes I added to the rules was that if you're trying to charge and someone is attacking you, then your charge is disabled and you don't get the point. You can see that the change in the rules was very minimal. It was only one line of code and it doesn't affect the readability of the method whatsoever. I was using the amazing Hashi library in lots of parts of my code. It's been super helpful. If you haven't used Hashi yet, I highly recommend you take a look. I've been using it in all of my projects from parsing APIs to working with a command line or even simulating board games. It's really cool. So now it's a few weeks and to playing around with a game and I felt good enough to try and test it out on humans. I used some blank cards and cubes I stole from another game, I borrowed from another game and I created this very first prototype. I have a small tip for people who like to create stuff plus a plug for eBay. I have a kit at home. I call it my maker's kit. It has all the stuff I need to quickly prototype anything I want to, whether it's video games, board games, websites or mobile apps. It consists of a bunch of empty playing cards, post-it notes, dice, tokens, pens and markers, and evil like a small hourglass. I use it every time I need physical stimulation for my creative process and I've found it very helpful in a lot of cases. So back to the prototype. I drew all the cards for the actions and for the computers I chose like computers from popular culture, Cal from 2001 Space Odyssey and Skynet from Terminator, just to name a few. We played a few rounds of the game at work. This is Gertner, he's one of our developers. And it helped me understand how humans or developers play my game. I took the feedback from these first sessions and went back to coding. I started working on expanding my players in the system. I no longer wanted just the random players who would just check and do random things. And you can see that in the code for the players, I emphasize the same things I did in the action resolver class and that was simplicity and ease of change. So I wrote a simple player and that was just an extension of my random players in the system, but with a bit of improvements. Instead of being completely random, they try to defend themselves whenever they're under attack and they try to heal up whenever they're low on energy. I improved the interface of the system every step of the way and I started pitting these new simple players I wrote against the completely random ones I already had in the system. I saw them completely outperforming the random players or at least like by 7%, which was good enough for me. And that was a good thing because it meant that A, my simple player was actually smarter than the random player, which is good. And B, if you play random in my game, the chances of you winning are lower than if you think while playing. I felt happy with my new simple players and I wanted to start testing the effects of the number of player has on the length of the game. To do that, I created a multivariant test which ran 10,000 simulations per combination that I built. I had 150 different combinations of the number of players, the starting energy and the energy required to win the game. For each one of these combinations, I simulated 10,000 games and the output was the average number of turns for each combination. This resulted in 1.5 million simulations of the game. That took about 40 minutes and a lot of data to go over. I did what you do with big data and I put it in a chart. If we zoom into the chart, you can see that the average turns peaks every time that the starting energy is exactly half of the energy required to win the game. And it made perfect sense to me since both zero energy and the energy required to win the game are end-game cases for a certain player. If a player starts his energy at exactly half of it, he's at a point of equilibrium between the two winning conditions. I then looked at how adding another player affects the length of the game. Each chunk here represents another player added to the game while inside is, I'm testing out the different starting energy combinations. I saw two trend lines in the graph. The top one represents the average turns per player when the starting energy is set to high and the bottom one shows the average turns per player when the starting energy is set to low. You can see that the top one is much stronger, meaning that when the starting energy was set to high, each extra player added to the game lengthened the game more so that if the starting energy would have been set to low. Now, I used this chart and this data to help me hone on the variables of my game. I could make an educated decision to start the game at five energy and to set the winning energy at twice that 10. So I went back and modified some other aspects of my rule system. I made it so that if you block, but no one is trying to attack you, you lose one energy point. The really cool thing is that after doing such a change in my system, I could now run a regression using the multivariant test and compare the change in the game. That was really, really helpful. I was feeling good about the game and the numbers of the game and I decided to turn my attention in creating a nicer prototype. I started with a bit of design and created the unique persona for each one of the computers. I did some, let's call it research, which was me watching 80s movies about computers. And I came up with some really cool computers based on the research. Some of them were inspired by movies, some of them from games and some of them from cleaning my living room. Can you guess which one? I ordered my first prototype from a company called the Game Crafter. They provide a printing service for when you're working with small quantities, which is great when you want to make a prototype. They have a web interface where you can just upload any art you want for cards, boards, or boxes. And they also have a huge collection of little bits and pieces, everything from sheep to people to grain to missiles. They didn't have little computers, all of them. The first prototype arrived in the mail and it looked fucking awesome. Getting a physical copy of something you built is extremely exciting. We sat down to play it at work that very day and the custom card art and the huge yellow cubes added a lot of feel to the game. We did encounter some several issues, like he's holding one of the cards upside down. And I had to go back to the drawing board or coding board or whatever you want to call it. I used the time working on the code again to test another theory I had. I started by creating a single-minded player or else got him a stupid single-minded player. A player that would do the same action over and over and over again without changing. I ran these new single-minded players one by one, the attacker one at first, then the blocker, then the charger. And I compared him to my simple players I already had in the system. Each one of them lost, which was great. And I have another small quiz for you. After running all these three single-minded versions of my players, the attacker, the blocker, and the charger, I saw that for games of four or more people, if you charge all the time, you have a higher chance than if you would block all the time. So I'll let you think a bit about why that exactly is. So after this last iteration, I started towards printing an even better prototype. I worked on getting the rules, having player aids and the nice box. I'll go in another small tangent and say that writing rules is really, really hard. Although it does remind me a bit of coding. You can instinctively tell good rules from bad ones. The more you read other people's work, the easier it is to write your own. And while writing rules, you wanna make sure you keep it dry. Don't repeat yourself, which I just did. You wanna keep the rules as short and concise as possible and whenever able, refer people to other sections of the rules. So I had to rewrite my rule book, I think, two or three times and refactor it another two or three times, but I was happy with them in the end and ordered another prototype. I received this new prototype and I took it to the monthly board game meetup that I attend in Tel Aviv. I got to play a few rounds of the game that day with people willing to help me test the game out and it was really fun to get to play it with other people. A couple of meetups later, I bought the game with me and placed it on the huge piles of game we had at the center of the room where everyone can just come and take whatever they wanna play that day. And I was playing something else across the room. I saw someone going to this pile of games, going through the different games, picking up my game, opening the box and starting to go over the rules. I then got to experience something totally awesome. For the first time ever, a group of people, which I didn't know, were playing the game without me being involved at all. They just picked up the game, learned the rules and started playing all by themselves. It was such a rush to see that happen. Of course, once I saw them starting to play, I went over and started filming them, taking pictures. I think they suspected it then. So I haven't finished the game yet. I might still get to try and get it published one day, so keep your eyes peeled for it out there. But for now, it just has to be one of my cooler side projects. I posted the code for the simulator on GitHub. You're welcome to take a look through it. I can't promise anything. It's not as clean as it was in the presentation, but it works. Now, I was kind of worried I won't be able to do this next part due to production and shipping issues, which is kind of weird to say at a Ruby conference, but they made it. And I'm happy to announce that I'm giving away four copies of the prototype here at Goga Ruko. This is a special edition I created specifically for this event with a special computer, the Goga Bot. And to enter the raffle, all you need to do is tweet about your first computer and add the hashtags Goga Ruko and microchips. And later today, I'll, I have a script and it will go through Twitter and find the four winners and we'll announce them and they'll get the copy. I hope you enjoyed the short journey through board gaming with me. My name is Jonathan Bergman. Feel free to come out and check out the game or just say hi. And thank you so much for having me here.