Playing (and talking through) the game with her a bunch of times, the different formats we invented got me thinking about how this simple system works and what you, the player, might want to know about it. Board games as simple as this one are kind of fun to poke at this way because you can usually see your way to some aspects of the game’s structure by either writing some expressions that describe how the game works formally, or when all else fails, writing some code that helps you understand some aspect of the game.
For Battleship, I decided to tackle a straightforward question Blaise and I face every time we play: Where should you take your first shot? How does that depend on the size of the board and the ships that are available to place on the grid?
The answer certainly will depend on whatever biases human opponents have for placing ships on the grid. There are probably some general factors that come into play, like the fact that most people have a left visual-field bias that affects a lot of different tasks. There are also probably lots of individual differences as well: Do you really like to put ships on the edges? Do you like to bunch everything up in one place? Do you hate/love using the corners? What these biases are could be it’s own fun problem to consider, but for now we’re going to act like they don’t exist. This way, we can start to develop a kind of simulation called a Monte-Carlo model that will let us understand some things about Battleship and how to plan your first shot.
What is a Monte Carlo model? Basically, it’s a way of simulating a probabilistic system by making lots of random draws and keeping track of what happens each time. For example, suppose you have 10 coins you want to flip and you want to know how often you’ll get exactly 3 heads – that’s something you can work out analytically, but if you didn’t know how (or just didn’t want to), you could also just flip the 10 coins lots of times and see how often you got 3 heads. That latter approach is more or less what we’re doing in a Monte Carlo simulation: Given a random process, we “draw” an outcome and record what features of the outcome we care about so we can estimate properties of the system that we’re interested in. While this strategy has been around for a long time, the advent of computers capable of doing the random draws and multiple iterations for us meant that MC simulations became much more widely used in the mid 20th century. To my knowledge, a mathematician named Stanislaw Ulam (who is a fascinating person to read about) is responsible for developing modern MC approaches, which he and others including John Von Neumann and Enrico Fermi used to examine issues in nuclear physics arising from the Manhattan Project. This was a case where they really didn’t know how to write down deterministic equations to explain the systems they cared about, so simulating them with random draws was about the only way forward.
OK, so how do we use these methods to talk about Battleship? First, let’s define what we want to know: Where should we take our first shot? I’m going to rephrase this as, “How likely is it that any given square will be occupied by a ship?” After all, if a square isn’t likely to be occupied, we wouldn’t want to waste time shooting at it. Second, let’s define how we think this system works in terms of a random process. Here are the rules I’ll use for our Battleship simulations:
1) There are five ships. One ships takes up 2 squares, two ships take up 3 squares, one ship takes up 4 squares, and one ship takes up 5 squares.
2) No square may be occupied by more than one ship (no overlap).
3) The ships are placed on a 10x10 board.
4) The ships are placed randomly by the opponent. For each ship, each legal ship position is equally likely to be selected.
Note: It’s really rule #2 that makes things a little tricky to compute deterministically, since the placing of one ship constrains the possible positions of the others.
So now what? The next step is to write code that allows us to randomly arrange the 5 ships for a single game and record where they were positioned. Here’s a picture showing you what a single game looks like using code that implements the four rules above.
My guess is that at this point this basically matches your intuitions about the game, so you may not be very impressed. Sure, we got some quantitative data about the relative merits of the center vs. the other locations, but how big a deal is that? Arguably, not much of a big deal, but the real fun starts by messing with those rules and seeing how things change. See, I wrote all my code so I can manipulate the size of the board, and the size and number of ships and do all this over again. Let’s see how the maps change when we use a smaller board (9 squares and then 8 squares).
There’s tons of other stuff you can do with this little game by simulating different scenarios, and these are nice ways to see how some candidate rule changes might make the game more or less fun. What if you introduce squares that can never be occupied? How about ships with different shapes? What if you make your game toroidal by letting ships “wrap around” the edges of the grid? Suppose we let the “no overlap” rule go? There are lots of possibilities to explore, and an MC simulation lets you quickly get some insight into how they work.
That’s the end of my grown-up post, and I hope you found it at least somewhat fun. I really think learning how to play with mathematical objects opens the door to lots of great ways to explore ordinary stuff, and hopefully this was a good example of why I think that’s fun to do. Please feel free to play with the code yourself, and I’ll try to develop a few more posts about similar topics. Thanks for reading, and happy modeling!
