5 Roblox Game Design Lessons We Learned the Hard Way

We've been building MergePets for months now. Along the way, we've made every mistake in the book — and some that aren't in any book. Here are five lessons that cost us time, players, or sanity, and what we'd do differently.

Don't Ship Features You Haven't Stress-Tested

We built a gacha system early on. It looked great. The animations were smooth. The odds were fair. And when we shipped it, it didn't work.

The system involved multiple server-side services talking to each other — currency deduction, random pet generation, inventory insertion, visual feedback. Under ideal conditions, everything worked. Under real conditions — multiple players spinning simultaneously, network latency, race conditions — it fell apart.

Players lost currency without getting pets. Some got pets without paying. The experience was so unreliable that we had to disable the entire system and rebuild it from scratch.

The lesson: A feature that works in Studio with one player is not a feature that works in a live server with 20. Stress-test everything with concurrent users before shipping.

Security Is Not Optional — It's Day One

In our first live playtest, someone figured out how to fire RemoteEvents directly and give themselves unlimited coins. Within 30 minutes, they had every pet in the game, maxed every upgrade, and were spamming the leaderboard.

We learned a painful truth about Roblox development: the client is the enemy. Every RemoteEvent is an API endpoint that any player can call with any arguments. If your server doesn't validate every single parameter, someone will exploit it.

Our security system now includes:

• Rate limiting on all merge actions (max 5 merges per second)
• Mutex locks on all currency transactions (no double-spending)
• Ownership verification on every merge (you can only merge your own pets)
• Server-side validation on every quest claim, login reward, and shop purchase
• Admin hardening — admin commands only work for whitelisted UserIds
• CPS cap at 100K to prevent overflow exploits

Every single fix has a toggle in our SecurityConfig so we can disable individual protections if they cause issues. Build security as a system, not a series of patches.

The lesson: Assume every player is a pentester. Validate everything server-side. Build toggleable security from day one.

The First 60 Seconds Decide Everything

We spent weeks building the Desert Pyramid, the combo system, the pasture feeding mechanic, zone leaderboards — all incredible features that most players never saw.

Why? Because our tutorial was bad.

New players landed in the Meadow with a 5x5 grid and no idea what to do. The tutorial was a series of text popups that nobody read. Players clicked through them, stared at a grid of identical puppies, dragged one pet onto another by accident, and... left.

We redesigned the first 60 seconds to be guided by action, not text:

1. A single arrow points to two matching pets
2. Player drags them together — satisfying merge animation plays
3. Immediate reward (coins, confetti)
4. Arrow points to next merge
5. Within 30 seconds, they've done 3 merges and unlocked their first quest

No text walls. No "Welcome to MergePets! In this game you will..." Just do the thing, see the result, want to do it again.

The lesson: Players decide if your game is worth their time in under 60 seconds. Make those seconds count. Show, don't tell.

Systems That Don't Connect Are Just Bloat

At one point, MergePets had a pasture system, a home building system, a quest system, a leaderboard system, a combo system, and a zone progression system. They all worked independently. None of them talked to each other.

Pastures generated coins but didn't care about your quest progress. Homes had furniture but none of it affected gameplay. Combos were satisfying but didn't impact your leaderboard score. Each system was an island.

We spent a full week rewiring everything:

• Home furniture now gives CPS bonuses — a bed gives a sleep boost, a fridge heals pets faster
• Daily bonus objects in homes give coins, gems, lucky eggs, CPS multipliers, and evolve candy
• Combo multipliers now contribute to merge count leaderboards
• Smart quests adapt based on which systems you actually use
• Zone progression requires resources from previous zones (sacrifice a high-tier pet)

Now every system feeds into at least two other systems. The result: players engage more deeply because each action has multiple payoffs.

The lesson: Every system in your game should strengthen at least one other system. If it stands alone, it's a distraction, not a feature.

Don't Build What Players Won't Notice

We spent two days building an elaborate 89,000-character HomeConfig file with detailed furniture specifications, multi-tier progression trees, and helper functions that generated decorative variations. It was architecturally beautiful. Nobody cared.

Players cared about: Does the home look cool? Can I collect my daily bonus? Does my CPS go up?

They didn't care about: The internal data structure, the config file organization, or whether the code was DRY.

We refactored that 89K config down to 28K — removing 62K of duplicated junk — and the game didn't change at all from the player's perspective. But those two days we spent on the original over-engineered version could have been spent on something players would actually feel.

This applies to visual design too. We built an elaborate treehouse system for homes — trunks, branches, climbing mechanics, elevated plots. Players found it confusing and disorienting. We deleted all of it and put homes on the ground at Y=0.5. Everyone was happier.

The lesson: Optimize for player experience, not engineering elegance. The best code is code that makes players smile — not code that makes developers proud.

The Meta-Lesson

All five lessons boil down to one thing: build for the player, not for yourself. Stress-test because players will break things. Secure because players will exploit things. Nail the tutorial because players will leave. Connect systems because players want depth. And don't over-engineer because players want fun, not architecture.

We're still learning. Every week brings a new mistake and a new lesson. But that's the job. Ship, learn, iterate. The game is better today than it was yesterday. Tomorrow it'll be better still.