Meteor Mayhem

An original multiplayer strategy card game about mining resources, upgrading ships, taking risks, and dealing with whatever the hazard deck decides to do next.

Meteor Mayhem prototype and presentation
RoleSole Designer & Creator
Year2025
StatusPlayable Prototype
FocusBalance + Decisions
Project TypeIndependent Honors Project
ScopeMultiplayer Physical Card Game

Can luck matter without deciding who wins?

I wanted the game 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.

The first project where everything came together.

I developed Meteor Mayhem through Life Design Lab as an independent honors project. It brought together strategy, probability, visual design, rules, playtesting, and the part I liked most: changing one thing and seeing what happened next.

Question → prototype → playtest → change it again.

01Research

Looked at how other games handled resources, upgrades, and players getting in each other’s way.

02Ideas

Filled pages with card ideas, hazards, scoring rules, and several win conditions that did not all survive.

03Prototype

Built a physical version and wrote rules that made sense to me. Then other people read them.

04Playtesting

Watched players use the rules that were actually there—not the rules I thought I had written.

05Balancing

Changed cards, pacing, costs, and rules whenever testing exposed a problem.

The game changed when other people touched it.

These photos show one of the physical setups I used while testing the game. The pieces were not fancy, but they made it possible to watch where players hesitated, what they ignored, and which strategies they found before I did.

Feedback: I tested the game with friends, classmates, family, and members of the local gaming community. Their questions and unexpected strategies shaped the rule, pacing, and balance changes shown below.

Early prototype setupTesting cards, resources, and how quickly players understood the table.
Balancing in progressWatching what players saved, spent, and completely ignored.
Expandable Case Study Playtesting Journal — What Players Taught Me

I already knew how the game was supposed to work.

That was the problem. Everyone else was seeing it for the first time, which meant they were going to notice things I could not see anymore. Looking back, watching people play taught me more than repeatedly playing the game against myself.

01

Players Saved Everything

What I expected

Players would spend fuel and resources whenever they needed them.

What actually happened

Almost everyone started saving everything because they were worried they would need it later. The game slowed down.

What I changed

I gave players more reasons to spend resources earlier.

What surprised me: the players were not making bad decisions. The rules were teaching them to hoard.

02

One Strategy Became Too Strong

What I expected

Players would try several different ways to win.

What actually happened

Once someone found the strongest approach, other players copied it.

What I changed

I adjusted card costs and made other strategies more rewarding.

What surprised me: players solve games much faster than I expected.

03

The Rulebook Made Sense… to Me

What I expected

I thought the instructions were clear.

What actually happened

Different players asked the same questions because I had skipped steps that felt obvious to me.

What I changed

I reorganized the rules and added examples where players kept getting stuck.

What surprised me: knowing the answer makes it hard to remember what a new player does not know yet.

04

Players Tried Things I Never Expected

What I expected

People would mostly play the way I imagined.

What actually happened

Some took risks much earlier. Others ignored upgrades I thought everyone would want. Someone built a strategy around a card I had barely considered.

What I changed

I stopped trying to push everyone toward one “correct” way to play.

What surprised me: players do not need the designer’s permission to be creative.

05

Small Changes Had Big Effects

Changing one cost, one resource, or one number could completely change what players decided to do. Balancing the game was usually not one giant fix. It was a long list of small changes, followed by another playtest.

Apparently, “balanced” is harder than it looks.

The game in my head was not always the game people experienced.

When I started, I thought game design was mostly about inventing mechanics. Now I think it is just as much about watching what people actually do with them. The first version does not have to be perfect. It has to be useful enough to show you what question to ask next.

  • How much randomness feels exciting before it starts feeling unfair?
  • How many strategies should be equally competitive?
  • When does complexity make a game deeper, and when does it only make it harder to learn?
  • How much information should players have before making an important decision?
  • What makes someone want to play “just one more game”?

Counting cards helped. Watching players helped more.

I used probability and card-frequency counts to adjust how often different effects appeared. That gave me a starting point, but the numbers could not tell me whether a decision felt interesting or whether one strategy was making every other choice pointless.

Frequency

How often should a hazard, upgrade, or resource appear?

Cost

Was an upgrade useful enough to justify what the player gave up?

Timing

Did a card create a decision, or did it only interrupt the game?

Counterplay

Could another player respond, or was the outcome already decided?

From notes to a game people could test.

01

Question

Could I make resource collection feel strategic instead of automatic?

02

Rough Ideas

Cards, hazards, ship upgrades, scoring rules, and too many possible directions.

03

Prototype

A physical version that was not pretty, but could finally answer questions.

04

Playtesting

Real players found confusing rules, slow turns, and strategies I missed.

05

Current Version

A more readable, balanced game—and a much better list of questions.

Most of the useful work looked messy.

Cards that players could understand without stopping the game.

Meteor Mayhem card sheet one Meteor Mayhem card sheet two Meteor Mayhem card sheet three Meteor Mayhem card sheet four

The walkthrough opens with the finished prototype, then explains the main systems and how a round works.

I would keep testing, not just add more cards.

  • Test with more players who have never met me and have not heard me explain the rules.
  • Explore asymmetric ships or player powers without making one clearly better.
  • Build a small digital tool to track card frequency, costs, and playtest results.

Players always find the part you did not think about.

The biggest lesson was that players do not care what the designer intended. They use the rules that are actually there. Watching them play helped me improve the game much more than explaining what I meant. I am still curious how far I could take it with more testing and more people trying to break it.