Race to Oregon.
A competitive card game that turns the classic Oregon Trail into a strategy and survival challenge for 2 to 5 players. Designed, documented, and tested to IEEE software engineering standards.
Believe
A classic game that was never meant for friends
The Oregon Trail has been around since the 1970s. Millions of people grew up playing it. But it was always a solo experience: just you against the trail, alone.
In Professor Simone Maccanti's Software Verification and Validation class at RMU, we were asked to identify a problem and build a solution that meets real engineering standards. Our team of three (Alex Marsh, Jayden Walker, and me) saw an opportunity: what if the Oregon Trail was not a solo survival story, but a competitive game you play with friends? Something where strategy, trading, and a little bit of luck decide who makes it to Oregon first.
The challenge was not just about game design. Everything we built had to be documented, testable, and professionally specified using IEEE standards. That meant we had to think like engineers AND like product people at the same time.
Jake Rice
Junior, Engineering Major, Casual Gamer
Context
Has 15-20 minutes between classes
Wants something quick, social, competitive
Grew up playing Oregon Trail as a kid
Plays card games like Uno and Exploding Kittens
What he wants
Learn the rules in under 5 minutes
Play a full game in 15-20 minutes
Strategy that matters but luck keeps it fun
Social interaction (trading, negotiating)
"I want something I can play with my roommates that takes 15 minutes, not 2 hours."
Understand
Researching what makes card games actually work
Before designing anything, we studied what makes competitive card games successful. We looked at games like Exploding Kittens, Uno, and Settlers of Catan. We also mapped out who would actually play this game and what would make them come back.
The primary user is a college student who wants a quick, competitive card game to play with friends. They have 15 to 20 minutes between classes. They want something easy to learn but strategic enough to stay interesting. This user profile shaped every design decision we made.
For the second version, I rebuilt everything from scratch over the summer:
Simple rules, deep decisions
You should be able to explain the basics in two minutes, but still discover new strategies months later. If the tutorial takes more than 10 minutes, you have lost most casual players.
Randomness plus skill
Pure luck gets boring. Pure strategy is intimidating. The best games balance both so anyone can win, but skilled players win more often.
Social interaction is everything
Trading, bluffing, and negotiating with other players is more fun than playing against a computer. People come back for the people, not just the mechanics.
Use case stories we designed for
Use case 1: First-time player
"Jake just sat down with his friends after class. He has never played before. His friend explains the rules in 2 minutes: collect resources, trade with other players, survive random events, reach Oregon first. Jake plays his first round and understands the game by round 2."
Design decision: 7 rounds (fits in 15 minutes), 4 simple resource types, visual tutorial under 10 minutes.
Use case 2: Competitive rematch
"Sarah lost the last game because she ran out of food in round 5. She wants to play again immediately with a different strategy. This time she is going to trade more aggressively early and stockpile food."
Design decision: Random events prevent the same strategy from winning every time. Trading system creates social dynamics that change each game.
Use case 3: Non-English speaker
"Omar is an international student from Morocco. His English is good but not perfect. He wants to play with his American roommates without struggling to read every card. He switches the language to Arabic and follows along easily."
Design decision: 4 language options (English, Spanish, Arabic, Chinese). Adjustable text size. High-contrast mode.
Ideate
Designing the game mechanics
We boiled the game down to four core mechanics. Each one was chosen because it addressed a specific user need from our research:
Resource cards
Four types: Food, Wood, Bullets, and Fabric. You need them to survive. Run out of food? You are in trouble. Managing your resources is the heart of the game. This keeps every decision meaningful.
Random events
Every round, something happens. A snowstorm hits. Bandits attack. Disease breaks out. You have to adapt your strategy on the fly. This is what prevents the same strategy from winning every game.
Trading System
You can swap cards with other players. This is where the real fun happens. Sometimes you have to give up something valuable just to stay alive. Trading creates the social interaction that keeps people coming back.
The journey
Seven rounds, one for each state on the Oregon Trail. First player to reach 100 points wins. This keeps every game under 20 minutes, fitting perfectly between classes.
Built for everyone, not just gamers
The scenery changes with the seasons as you travel west, which makes the journey feel real. Text size is adjustable. There is a high-contrast mode for people who need it. And we added four languages: English, Spanish, Arabic, and Chinese. A simple tutorial gets new players ready in under 10 minutes.
Built with:
Python
Pygame
Git
Figma
Notion
IEEE SRS
Standard
AES-256
Sora
Listen
Testing with real players changed everything
The most valuable part of this project was not the code or the documentation. It was watching real people play.
We tested with classmates in ENGR-3400 and got direct feedback from Professor Maccanti. Both groups found issues we never would have caught ourselves:
Rules that seemed clear were not
The trading system needed extra explanation. Several players asked "wait, can I trade with anyone or just the player next to me?" We rewrote the rules to be explicit about every interaction.
Some events were too punishing
A few event cards wiped out half a player's resources in one round. Players felt helpless instead of challenged. We rebalanced the events so they create tension without feeling unfair.
The tutorial was too long
Our first tutorial was 15 minutes. Players lost interest. We cut it in half to under 8 minutes by removing edge cases and letting players learn those during gameplay instead.
The version we submitted was dramatically better than our first playtest. Not because we added features, but because we listened to what players actually experienced. The disconnect between what the team sees and what users experience is exactly what product managers exist to bridge.
What we shipped
We delivered a complete Software Requirements Specification, a professional document that any developer could pick up and turn into a fully playable game. Our professor and classmates gave strong feedback on how clear the game logic was and how natural the interface felt.
<5s
Load time
99.5%
Uptime target.
IEEE
Standards met
What we shipped
Game balance
No strategy wins more than 35% of games
Average game length: 12-18 minutes
Player elimination before round 5: under 10%
Usability
Tutorial completion: under 10 minutes
Rule questions during first game: fewer than 3
Players who want to play again: 70%+
Accessibility
Has 15-20 minutes between classes
Language switch time: under 5 seconds
High-contrast mode readability: WCAG AA
Text size range: 12px to 24px
Technical
Has 15-20 minutes between classes
Game load time: under 5 seconds
Data encryption: AES-256 verified
Offline play: fully functional
What it does today
Real-time group chat organized by class. Secure file sharing for notes and study materials. QR code joining — scan and you're in. Account system with real password security. Clean web interface that anyone can figure out.
What's next
Moving to the cloud so it can handle more students. Push notifications so nobody misses a message. Connecting it with the systems universities already use. The goal is still the same: make it dead simple for students to help each other learn.
Takeaways
What I took away from this
01
Decide what you are building early and protect it. We defined our scope on day one and said no to everything else. That discipline is why we finished a complete, polished game instead of a half-built mess with 10 features.
02
User testing is the most valuable product activity you can do. We learned more from one playtest session than from weeks of designing on paper. The disconnect between what the team sees and what users experience is exactly what product managers exist to bridge.
03
Good documentation is a product in itself. The best spec is useless if the reader gets confused. Writing the IEEE SRS taught me to always write for my audience, not for myself. That skill applies to PRDs, user stories, and every product document.
04
Every team member sees things differently, and that is the whole point. My focus was connecting the technical details to what actually makes the game fun to play. That translation between engineering and user value is the core of product management.