An original multiplayer strategy card game by Charlie Barra
Full Portfolio Case Study · Video Walkthrough · Rulebook (Prototype Edition) · Playtesting & Balance Questions · Printable Card Sheets
Can luck matter without deciding who wins?
I wanted Meteor Mayhem to be unpredictable without making players feel like their choices did not matter. Players had to decide when to take a risk, upgrade, defend, or interfere with someone else.
That sounded straightforward until people actually started playing it.
Meteor Mayhem is a multiplayer tabletop strategy game about mining resources from a meteor, upgrading ships, surviving hazards, and competing with other players.
I designed the:
- rules and turn structure,
- cards and card categories,
- resource economy,
- ship upgrades,
- hazards and events,
- physical prototype,
- playtesting process,
- and card-frequency approach used during balancing.
Role: Independent student game designer and prototype creator
Duration: Approximately 4 months
Status: Playable physical prototype
Players: 2–4
Play time: 15–30 minutes
Tools: Google Slides, physical prototyping, and playtesting
Developed through: Life Design Lab, an Honors-level program at Morristown High School
The project did not move in a straight line.
- I researched resource systems, upgrades, risk, and player interaction.
- I filled pages with cards, hazards, scoring ideas, and several win conditions.
- I built a physical version so people could finally test it.
- Players found confusing rules and strategies I had not expected.
- I changed card effects, costs, pacing, and instructions.
- Then I tested it again.
The prototype was useful because it answered questions. It did not need to look finished yet.
| Early Planning | Proposal | Brainstorming |
|---|---|---|
| Design Process | Card Ideas | Self-Evaluation |
|---|---|---|
I already knew how the game was supposed to work. That was the problem.
New players noticed things I could no longer see because I already knew what every rule and card was meant to do. Watching them play taught me much more than repeatedly explaining what I intended.
| Early Prototype Setup | Balancing in Progress |
|---|---|
| Testing the card system, resource pieces, and how quickly players understood the table. | Watching what players saved, spent, and completely ignored. |
I expected players to spend fuel and resources whenever they needed them. Instead, many saved everything because they worried they would need it later.
The players were not making bad decisions. The rules were teaching them to hoard.
I wanted several ways to win. Once someone found the strongest approach, other players started copying it.
I adjusted costs and made other strategies more rewarding. The goal was not to remove a good strategy. I just did not want it to be the only good one.
Different players asked the same questions because I had skipped steps that felt obvious.
Knowing the answer makes it surprisingly difficult to remember what a new player does not know yet.
Some players took risks early. Others ignored upgrades I thought everyone would want. Someone built a strategy around a card I had barely considered.
Players do not need the designer’s permission to be creative.
Changing one cost, one resource, or one number could completely change what players decided to do.
Apparently, “balanced” is harder than it looks.
More detailed notes are in documentation/playtesting/Playtesting Journal.md.
Writing the rules down exposed missing steps and unclear wording. The current prototype rulebook is a working draft that I would test with players who have not heard me explain the game.
View the Meteor Mayhem Rulebook (Prototype Edition)
“I never actually calculated exact probabilities. Instead, I wrote down the questions I wanted to answer while playtesting. That helped me decide what to change after each game.”
The questions focused my playtests on:
- how often high-impact cards should appear,
- how long it took to build a strong mining tier,
- whether several paths to victory remained viable,
- whether one strategy became dominant,
- and how much control players had over uncertainty.
The notes are intentionally honest. I wanted high-impact cards to appear often because the game is more fun when it is chaotic. At the same time, repeated play suggested that building the mining tier as quickly as possible could become the preferred strategy. Card selection and scouting gave players ways to respond to uncertainty, but the dominant-strategy question became something to keep testing.
View the Playtesting and Balance Questions
The working Markdown record is in documentation/balance/Balance Notes.md.
I used consistent layouts and categories so players could understand cards without stopping the game every turn.
| Card Sheet 1 | Card Sheet 2 |
|---|---|
| Card Sheet 3 | Card Sheet 4 |
|---|---|
View the printable card-sheet PDF
The reference card helps players check resource points, mining tiers, and when to draw from the disaster deck.
The game in my head was not always the game other people experienced.
Players use the rules that are actually there—not the rules I thought I had written. The most useful changes came from watching people play instead of explaining what I meant.
With more development time, I would:
- test with more people who have never heard me explain the rules,
- track playtest results more systematically,
- refine card frequency and resource costs,
- revise the Prototype Edition when future playtests reveal unclear rules,
- explore asymmetric ships or player powers,
- and build a small digital balancing tool.
I am still wondering how much randomness feels exciting before it starts feeling unfair.
meteor-mayhem/
├── README.md
├── assets/
│ ├── hero/
│ ├── process/
│ ├── cards/
│ └── playtesting/
├── documentation/
│ ├── design-process/
│ ├── playtesting/
│ ├── reflections/
│ ├── rules/
│ └── balance/
└── printable-files/
- Design Process
- Playtesting Journal
- Meteor Mayhem Rulebook (Prototype Edition)
- Playtesting & Balance Questions
- Balance Notes - accessible Markdown
- Playtesting Log Template
- Project Reflection
- Prototype Edition — current rulebook for the playable prototype.
- Future revisions — will be documented here when additional testing leads to meaningful changes.
I do not think the goal is to make a perfect first version. I think the goal is to build something useful enough to show you what question to ask next.
This repository was assembled in July 2026 from original design files, rules, cards, photographs, and project documentation for portfolio review. Its Git history records archival organization and later documentation updates, not Meteor Mayhem's original development timeline. The dated process materials, playtesting records, and prototype artifacts provide the evidence of how the game developed.