xor.

Between 2018 and 2024, I spent a lot of time looking for ways Roblox games — and sometimes the engine itself — could behave differently from what their developers expected. I started doing this long before I got seriously into making games. Looking back, it changed the way I write code.

Some of the most interesting findings weren't obvious crashes or broken scripts. They were cases where two systems disagreed about what was true: the client and the server, the live game and its saved data, or the inventory and the economy built around it.

01 / Physics and server authority

One of my earlier findings involved PhysicsService and a mismatch between the position a client appeared to occupy and the position the server actually recognized. From the player's perspective, movement looked one way. From the server's perspective, the character was somewhere else.

That distinction matters because games often build important rules around location: whether you can interact with something, reach an area, take damage, or trigger an event. If a game trusts the wrong version of a player's position, it's making decisions with a false assumption. Roblox later changed relevant physics and velocity behavior.

02 / Network updates that don't tell the same story

I also found issues around how different kinds of network updates were accepted. In certain conditions, positional updates and appearance-related updates could stop lining up. That made the character's visible state diverge from what the server understood to be happening.

This was another client-versus-server authority problem, and the behavior was subsequently patched. The important part wasn't a specific flag or packet. It was the broader lesson: a character can appear consistent on one machine while the actual authoritative state tells a different story.

03 / Data that exists in memory but can't be saved

This is a class of bug I've still seen in live games. A developer can have a genuinely solid data system and still allow a player-controlled value to enter a profile in a form the storage layer can't persist.

The profile may work completely normally in memory. But if a later save fails because the data is invalid or exceeds a limit, the next session can fall back to an older saved state, depending on the game's recovery logic. That opens the door to data loss and, in some economies, rollbacks of legitimate transactions.

Session locking and a good data library are useful, but they don't replace validating the actual shape, type, and size of everything you're going to save.

04 / Replication and the hidden state of a character

Another finding involved an internal character-replication behavior that could effectively put part of the character's replication to sleep. It created a difference between what the local client showed and what the server considered the true position, while other updates continued.

It's an interesting example of why synchronization is not one single on/off switch. Different systems can keep updating while a critical piece of state becomes stale. I'm deliberately leaving out the exact mechanism because the behavior may still be relevant to live games.

05 / Selling the same item more than once

Not every finding was an engine issue. Some of the most consequential ones came from ordinary game code.

I ran into batch-selling systems that checked whether an item identifier belonged to the player, but failed to ensure the item could contribute to a sale only once. A repeated reference to the same item could be treated as multiple valid entries. The system had identifiers and validation, but it lacked a stronger guarantee about consuming an item.

That's a good example of a stale-state validation bug. The server checked something that was true before the transaction, but the transaction didn't consistently enforce what should remain true afterward.

What all of this taught me

These were different vulnerabilities, but they all made me ask a similar question: what does the system actually guarantee?

Does the server have the final say on a player's state? Can every valid in-memory profile be persisted? Can an item have one owner and be consumed only once? Are two parts of the game relying on different definitions of the same thing?

Finding issues like these is what originally got me interested in programming. Building games later gave me a very different appreciation for how easy those mistakes are to make — even when the code looks fine.

For issues that may still affect live games, I've kept the descriptions at the architectural level rather than publishing reproduction steps. The point of this post is the failure modes and what developers can learn from them.

Before I got seriously into making Roblox games, I spent years trying to break them. And something I've noticed is that a surprising amount of the vulnerabilities I've found weren't in terrible code. They were in systems made by people who clearly knew what they were doing.

I'm talking proper inventory systems, UUIDs, server-side validation, good frameworks, all of it. The code could be clean and the game could work perfectly fine for a normal player. Yet there'd still be some ridiculous way to duplicate an item or undo a transaction.

That's why I don't really buy the idea that being an advanced scripter automatically means you're writing safe systems. You can be good at programming and still completely misunderstand one of the assumptions your game relies on.

Good code doesn't mean the logic is right

I think developers spend a lot of time worrying about how their code looks. Is it organized? Am I using the right framework? Is everything properly modular?

Those are good things to care about. But none of them answer what happens when someone uses your system in a way you didn't plan for.

If you make an inventory, of course you test that equipping, trading, and selling work. But have you tested what happens when the same item is submitted twice? What if two players both have a record claiming they own it? What happens when your game creates data that Roblox can't actually save?

These aren't random edge cases that only matter to exploiters. They're the rules your system is supposed to guarantee in the first place.

One item shouldn't be worth multiple sales

One of my favorite examples comes from a batch-selling system I found. It used UUIDs to identify items and checked that the player actually owned the items they were trying to sell. On paper, that sounds completely fine.

Except the server was checking entries against an inventory state that hadn't changed yet. If multiple entries referred to the same item, they could each pass the same ownership check. Depending on how the reward calculation worked, the game could end up paying out more than once for an item that only existed once.

I can already imagine someone saying, "well, just block duplicate UUIDs in the request." Sure, that fixes that particular input. But what about trading? Other ways of consuming the item? Retried transactions? If every one of those systems has its own slightly different logic, you've got the same underlying problem waiting to show up somewhere else.

It's a stale-state validation issue, related to what people call TOCTOU (time-of-check to time-of-use). You don't even need two threads racing each other here. The code can make the same wrong decision repeatedly because it keeps checking a state that hasn't been updated.

To me, the actual fix starts with a much simpler question: what guarantees that one item can only be consumed once? If the answer is just "we check that they own it," then you haven't really answered it.

Your data library can't save something that's invalid

Another one I've run into is data rollback. I see developers set up ProfileStore, session locking, reconciliation, and assume they're covered because they're using a proper data system. And those tools are good! But they're not a replacement for checking what goes into the profile.

Say your game lets the client influence some saved settings. If the server doesn't properly limit the type, size, or structure of those values, it can end up with a profile that works fine in memory but can't be persisted. An oversized value is one example.

The player might spend currency, use an item, play for another ten minutes, and everything on screen looks normal. Then the save fails. Depending on the way that game handles failed saves and recovery, the next session can load an older state. Suddenly something the player spent is back, or a transaction they made has effectively disappeared.

It's not that every failed save automatically creates a dupe. The failure-handling logic matters. But that's exactly the point: your economy depends on persistence, and you've let the game create a state its persistence layer can't represent.

So yes, validate what the client sends. But also validate what you're about to save. Think about lengths, types, the serialized size of the full profile, and whether every piece of data can actually survive a save and reload. A good library can't make that decision for you.

And no, UUIDs aren't an anti-dupe system

This one bothers me because I see UUIDs brought up as if assigning an identifier to every item somehow solves duplication.

A UUID tells you which item you're talking about. That's it. It doesn't magically enforce who owns the item or whether it can exist in two places at once.

Imagine player A has an item with a certain UUID, and player B also has a record claiming that same UUID. Both inventories might pass their own checks because neither player has a duplicate within their own inventory. But globally you've still got two ownership claims for one item.

You can detect that later and delete one copy, but which one was legitimate? How did the invalid state happen at all? That's the part the UUID never solved.

What matters is how ownership changes, and whether every system involved agrees on it. Trading, selling, saving, loading — they all have to obey the same rules.

What I actually look for now

Because I started with exploits, I tend to read code backwards. Instead of only asking "does this feature work?", I ask what the developer is assuming will always be true. Then I try to think of a situation where it isn't.

I'm not saying every developer who's made one of these mistakes is bad. I've seen genuinely impressive systems with vulnerabilities, and I'm definitely not pretending my own code is immune. That's part of why I find this interesting.

But I wish more people thought beyond individual checks. An item should only be consumed once. A transaction shouldn't create value out of nowhere. A player's data shouldn't enter a state it can't save. And an identifier isn't proof of ownership just because it looks unique.

Don't just ask whether the server validates a request. Ask what your system actually guarantees. That's where a lot of these bugs start, even when the code around them looks completely correct.

I was originally going to write this about four months ago. Then things got busy, and honestly, who even wants to sit down and write a blog post anyway? But I've been thinking about it again, so here we are.

I feel like I'm saying grass is green whenever I tell someone that game design matters. Obviously it matters. But I also think people completely underestimate what that actually means.

It's not just how polished your game looks, how good the UI is, or how many features you can fit into it. Those things help, but they won't save a game that gives people no real reason to play.

15,000 players doesn't mean 15,000 players want to stay

One of the things that made me want to write this was a shooter that released a few months ago. It had over 100,000 Discord members before launch. Within the first twenty minutes it was sitting at over 15,000 concurrent players. Great launch, right?

Within about two hours, that number was down to roughly 3,000. By the next morning it was around 500. Eventually, when I checked again, it was down near 40.

How does a game with that much hype lose players that fast?

I think a big part of it was that the game didn't offer much of a reason to leave what people were already playing. It was essentially another front-page shooter in the same lane as RIVALS, with different polish and not a whole lot of content.

Put yourself in the player's position. You've already got skins, coins, and progress in RIVALS. Now a new shooter comes out and asks you to leave all that behind to start from zero, except the game you're moving to is fundamentally pretty similar. What's the appeal?

I'm not saying every new shooter needs to reinvent the genre. But there needs to be something that makes it worth choosing. A different experience, a stronger loop, something to work toward. Hype can convince someone to join once. It doesn't give them a reason to open the game again tomorrow.

Too much friction

Whenever someone asks me to try their game, one of the most common things I end up telling them is that there's too much friction. And almost every time, the response is some variation of: "what does that even mean?"

The way I'd define friction is the difficulty of getting to a reward in a way that's understandable and sustainable. You need some friction, obviously. If a reward takes absolutely nothing to get, it usually doesn't feel very rewarding. But too much friction just makes the game frustrating.

Think about a normal shooter. You aim, you hit, you win. You miss, you lose. It's not literally that simple every single time, but the relationship between what you did and what happened is clear. You can get better at it. You can understand why you lost, adjust, and win the next fight.

That's what I mean by sustainable. The player has a way to improve and a reason to keep trying.

When the game stops rewarding the thing it's supposed to reward

Now take a shooter that tries adding anime elements. I'm not against that idea at all. The problem is how you execute it.

One example I saw let players use these ridiculous ultimates, including one that basically spawned a tornado. And sure, it might look cool. But what does that actually do to a shooter that's supposed to reward aim and movement?

You can aim better, move better, and make all the right decisions, then lose because someone pressed a button with way more impact than the rest of the combat system. That's terrible design for a skill-first shooter. What exactly are you supposed to learn from that loss?

Abilities aren't automatically bad. If a game is built around them, or there's proper counterplay, that's a different story. But when you add something that breaks the basic cause and effect players are relying on, you've made winning feel less understandable. And if people can't work out how to win consistently, getting into another match starts feeling pointless.

It's everywhere, not just combat

Friction shows up in basically every part of a game. Tutorials, maps, intermissions, crate openings, the economy, even the way your UI is arranged.

A bad map layout can make moving around boring before you've even reached the fun part. A cluttered UI can make a simple game feel exhausting to understand. A long intermission can kill the momentum after a good match. A confusing economy can leave you wondering what you're even working toward.

And a confusing game loop is probably the worst one. If you don't know why you're winning or losing, you can't figure out how to repeat the good parts. There's no real sense of improvement, and eventually no reason to stay.

None of this means you should remove every bit of difficulty or make everything instant. That's not the point. The effort has to feel worth it, and the player needs to understand what they're putting that effort into.

I think that's what a lot of developers miss when they talk about game design. They focus on whether their game has good features, not whether those features actually work together to make something people want to keep playing.

You can have the best-looking game on the front page, a huge Discord, and a perfect launch. But if the experience itself doesn't give people a reason to stay, none of that matters for very long.