# Beggar My Neighbour Simulation and Analysis
[GitHub repository for this project](https://github.com/DAHammond/Beggar-My-Neighbour-Simulation/blob/1737790917ce0fe5f30f6a2e72e0302350f9918b/Beggar%20My%20Neighbour%20Simulation.ipynb)
[Author LinkedIn](https://www.linkedin.com/in/david--hammond/)

As our Nile cruise drifted between Aswan and Luxor, the sun dipping low over the river’s shimmering surface, my travel companion unveiled a curious distraction: Beggar My Neighbour, a card game for two that hinges entirely on chance. The aim? To claim every card through a simple yet surprisingly gripping pay process. Our games stretched on, each round a test of patience as much as luck. This sparked a question in my mind—could the Python skills I’d honed at university unlock deeper insights into this game? What could we learn about its mechanics, and just how long might we expect these marathon matches to last?

Beyond unraveling the game’s mysteries, I set myself a second mission: to keep my coding and data science skills sharp while experimenting with a new AI tool to guide the process. Having previously leaned on ChatGPT’s 3rd and 4th generation models, I decided to switch things up for this project, enlisting xAI’s Grok 3 as my coding companion. Its fresh perspective promised to add an intriguing layer to this analytical adventure.

By its very design, Beggar My Neighbour leaves no room for skill—every game’s outcome is preordained by the shuffle of the deck. This meant my focus had to shift from predicting wins to dissecting the game’s inevitable flow. I set out to explore the number of moves and time it takes for a game to reach its conclusion, alongside tracking the frequency of dramatic comebacks and shifts in the lead. To wrap things up, I’d dive into the game’s edge cases—those rare outliers that defy the norm—before reflecting on my experience with Grok 3 and its role in bringing this project to life.

## History

As I delved into Beggar My Neighbour on our Nile cruise, I grew curious about its origins. This classic card game, likely born in Britain, has roots that stretch back to at least the 19th century, though its exact beginnings remain elusive, typical of folk games passed down through generations. By the mid-1800s, it was popular enough to appear in Charles Dickens’ Great Expectations (1861), where Pip and Estella play it, hinting at its widespread appeal in Victorian England. Known also as “Strip Jack Naked” or “Beat Your Neighbour” in some circles, the game’s simple rules—dividing a deck and claiming cards through chance-driven face-card challenges—made it a favorite for casual play across all ages. In this nature, the version I originally played differed slightly. Beggar My Neighbour's reliance on luck, not skill, ensured accessibility, from family parlors to far-flung corners of the British Empire. Today, while less common, Beggar My Neighbour endures as a nostalgic pastime and a fascinating subject for mathematical and programming explorations.

## Rules
Beggar My Neighbour is a classic, luck-based card game played with a standard 52-card deck. The objective is simple: one player must win all the cards. Here are the key rules:

- Setup:
- A standard 52-card deck (no jokers, unique cards: 2 through Ace for each suit—Hearts, Diamonds, Clubs, Spades) is shuffled and split evenly between two players, giving each 26 cards.
- Players do not look at their cards; they hold them face-down in a personal stack.
- Card Types:
- Number Cards: 2 through 10, with no special effect.
- Court Cards (Penalty Cards):
- Ace: Opponent must play 4 cards.
- King: Opponent must play 3 cards.
- Queen: Opponent must play 2 cards.
- Jack: Opponent must play 1 card.
- Gameplay:
1. Players take turns playing one card face-up to a central pile, starting with Player 1.
2. If a number card (2-10) is played, the turn passes to the other player.
3. If a court card (Ace, King, Queen, Jack) is played, the opponent enters a "pay" phase:
- They must play the required number of cards (e.g., 4 for an Ace).
- If they play a number card, they continue paying.
- If they play a court (face) card, roles reverse: the original player must now pay.
- If they complete the payment without playing a court card, the player who played the court card wins the entire pile, adding it to their stack.
4. Cards won are shuffled and added to the bottom of the winner’s stack.
5. If a player runs out of cards during their turn or while paying, they lose.
- Objective:
- The game ends when one player has all 52 cards, becoming the winner.
- Note:
- The game relies heavily on luck (card order from shuffling) and can be short or, in rare cases, very long due to cycles of penalty cards and pile exchanges.

## Simulation Decisions
While working with Grok to code and simulate Beggar My Neighbour, I made several choices to keep the project simple, efficient, and accurate.

First, I decided that Player 1 would always start the game. This streamlined the simulation process. When Grok tested a version with a coin flip to decide the starting player, the win rates for both players hovered just below 50% due to the maximum moves limit, showing no significant difference when this aspect was distributed randomly.

Next, I needed to set a limit on the maximum number of moves to prevent endless simulations. Following Grok’s suggestion, I chose an arbitrary limit of 10,000 moves. Testing showed that very few games reached this limit, with all non-limited games concluding below half that number. In my final results including in this article, I simulated 100,000 games with none reaching this limit.

I also opted for a Monte Carlo approach in Python, using familiar libraries like Matplotlib. This allowed me to explore the Monte Carlo methodology while building on my existing coding knowledge.

Finally, since I’m living abroad without a PC, I completed the project entirely on an iPad. For convenience, I used a Jupyter notebook on the Carnets app stored on Dropbox, ensuring the project was secure and easy to edit section by section.

## Simulation method

### Simulation Overview
This Python simulation models "Beggar My Neighbour" to analyze game dynamics, such as the number of moves, leader changes, and comeback frequency. Here’s how it’s implemented:

- Deck and Setup:
- A 52-card deck is created, with unique cards (e.g., 2H, 3D, ..., AS), shuffled randomly, and split evenly (26 cards each) between two players.
- Game Logic:
- Each move involves playing one card to a central pile, incrementing a move counter.
- Number cards pass the turn; court cards trigger the penalty phase per the rules.
- The pile is awarded to the player who played the court card if the opponent completes payment without a court card.
- A maximum move limit (e.g., 10,000) prevents rare infinite loops.
- Tracked Metrics:
- Moves: Counts each card played to the pile.
- Leader Changes: Tracks how often the player with more cards switches (excluding ties).
- Comebacks: Measures if the player with fewer cards at 25%, 50%, and 75% of the game’s moves wins.
- Outliers: Games hitting the move limit are identified and excluded for separate analysis.
- Monte Carlo Approach:
- The game is simulated multiple times to account for randomness in shuffling.
- Statistics (average, median, standard deviation, etc.) are computed for moves and leader changes.
- Time estimates assume fast (2 sec/move) and slow (5 sec/move) play speeds.
- Implementation:
- Code is broken into chunks for Jupyter: setup, deck creation, game logic, simulation, analysis, and visualization.
- Results are presented for all games and without outliers, with a histogram of moves.
- Purpose:
- This simulation provides insights into game length, competitiveness (leader changes), and the likelihood of comebacks, capturing the stochastic nature of "Beggar My Neighbour."
## Simulation Raw Results

*In the Juptyr notebook, there is an extended version of the results which excludes the outlier results that hit the max moves limit. As there are none in this simulation, I have not included them in this article as the statistics are identical.*

## Results

The simulation results reveal a notable variation in the number of moves required to finish each game of Beggar My Neighbour. With an average of 197.56 moves compared to a median of 151, the data displays a positive skew, likely driven by large outliers. This pattern is evident in the box plot below, which highlights 4,760 outliers across the 100,000 simulated games.


As I compared the current simulation results to those from earlier code preparations, I was struck by the absence of any games hitting the maximum move limit of 10,000. In contrast, a single Grok simulation of 10,000 games included 47 instances where the limit was reached, leading to a noticeably longer average game length. Having tested both previous versions of the code and the updated iterations, the results presented here have been consistent across multiple runs. However, it’s puzzling that outcomes from the same code seem to differ from those on previous days. If you have any thoughts on what might be causing this odd behavior, I’d love to hear them—very strange indeed!


The histogram reveals a concentrated cluster of results, with a pronounced density at lower move counts and a long, slender tail stretching toward higher numbers of moves, reflecting the distribution’s positive skew.

In the latest simulations, the average game duration is 6 minutes and 35 seconds for fast players (at 2 seconds per move) and 16 minutes and 28 seconds for slower players (at 5 seconds per move), based on the average of 197.56 moves.

Lastly, the results show no comebacks whatsoever, with the trailing player never winning after 25%, 50%, or 75% of moves. I suspect this isn’t accurate and likely points to an error in my code—any insights on where I might have gone wrong would be appreciated! That said, if these results hold true, they offer a fascinating perspective on the game’s dynamics.

## Conclusion and how was Grok 3

This project came together swiftly, thanks to Grok 3’s assistance. I obtained my results in no time, though I suspect some human error crept in when I translated the code and took a couple of days between starting and completing the project. Still, the findings were fascinating and addressed my initial hypothesis. Without the goal of writing a full article, I could have answered my core questions in under 30 minutes.

### TL;DR
Grok 3 proved to be an incredible tool, though I found it challenging to get the AI to focus on specific parts of the project, especially since I had modified sections outside the main code. In my simulation, on average, a game of Beggar My Neighbour lasts 6 minutes and 35 seconds for fast players (2 seconds per move) and 16 minutes and 28 seconds for slower players (5 seconds per move), with games ranging from a minimum of 27 moves to a maximum of 1943 moves.