Understanding Roblox networking and FilteringEnabled: Part 1

So a lot of developers just can not figure out FilteringEnabled (FE). I believe this is a conceptual issue, and so I am going to explain what Roblox does in the background, to make FE more clear.

Roblox Networking

The first impression people have of Roblox is that it just “exists” in one world. Like the real world, everything is just there. You move, your friend sees it.

Of course, most users realize that their computer monitor is not just a window into another world. As a developer, I assume you realize this, and realize there are other players out there, playing your game.

player2 is alarmed, he’s being squeezed in by stalkers!

These guys obviously communicate with each other, and this forms the basis for online gameplay. If you realize this, you also must realize that this communication is not instantaneous. There is a slight delay that you probably don’t notice most of the time. When you do, you call it “lag.”

With this, we must realize our computers, we will call them clients, must be talking to each other. We will draw this with some arrows to remember that just like the real world when it comes to communication, computers must expend time and resources to talk to each other.

You can see that each client has to tell the other clients what’s going on. Hey, says you. “…” and so the blue client says “!” and the yellow client says “?.” What happens if one client forgets to tell another? Let’s say your client does not tell the yellow client you just walked 50 feet forward. Well, you and the blue client both see yourself in one position, and the yellow client sees yourself in another position.

More specifically, what happens if you decides to tell all the other clients “I have 1,000,000 cookies.” Now, humans may be able to detect that you’re cheating, but computers can be really stupid, and will let you get away with it.

Or will they?

You see, if you have been playing Roblox for a while, you may have noticed the “running games” tab, which lists a lot of the same world. You will notice that these games fill up, and only within these games do players communicate between each other.

This is good. You do not want to have to murder 3000 players as the murderer when playing Murder II. However, with this model, we learn something new, fundamental to understanding Roblox networking.

You see, Roblox clients never speak to each other directly. Instead, Roblox has its own computer, a messenger, that passes on messages to other players. It decides whether or not something is “true” or “false.” We’ll call this messenger a “server.”

Introducing, the client-server model, in cartoon form.

When you want to say “…” to the blue client, you tell the Roblox server, and the server tells the blue client “…” for you. Furthermore, the Roblox server remembers. If you move 120 studs forwards, the server will remember your position, and when player2 suddenly joins the game and wants to know where you are, Roblox can tell player2 “Hey, green is over here!”

For those with a more technical background, this is why a RemoteEvent fired from Green Client to Blue Client will never reach the BlueClient.

You remember that big list of games? Well, each of these games has its own server. However, you only communicate with your server, so you never get a message from “some other client” on “server2,” and they never get your message from “server1.”

For all intents and purposes, you can ignore these other games for now. Now, when anything happens on a client, Roblox sends this information to its server. If the server is running slow, or something, it may take a bit more time to send it off to the other clients. This is called lag.

Now, Roblox does counter this lag with several things. For one, Roblox extrapolates (that is, guess), what the position of a part is. This means that even if the server is dropping the ball on sending information, Roblox will still try to guess what the server would send to you, and then makes that appear on your screen.

Roblox also uses the concept of “Physics owners” that is, your client can “own “ a part and do the physics calculations on it, keeping the load off of the server. These parts are the ones closest to you, and that is why parts near you are very smooth and silky — that is, until another player comes near you. When moving parts start teleporting, this is Roblox physics owners swapping and another client taking control of what happens to this part. Sine their model does not match yours, the part will teleport.

There are a few fallout bugs from this system.

• It’s impossible to get the rendered (displayed) position/rotation of a Roblox moving part, because you cannot read the interpolated position of the part.
• Roblox parts, as mentioned before, will teleport when switching physics owners.
• Roblox physics on large moving objects can be slow
• If you have any sort of physics object (like a BodyForce) on the server, and you change it on the server, that means Roblox’s server will be forced to resume control of the model for a little bit before switching it back to the client. (Thus, teleporting)
• Parts with no clients near them (thus, no physics owner), slow down to a standstill, or even freeze in place, from lack of anything to process it.

FilteringEnabled: or, what is being filtered.

So about a year ago, Roblox released “FilteringEnabled.” What is FilteringEnabled, well, it enables filtering? What is it filtering? It’s filtering the information that Roblox clients can send to the server.

You see, in nonfiltered games, it is common to enter and see the whole game changed, gone, modified by someone hacking. Yes, that is right, without FilteringEnabled, Roblox will allow one client to tell the server exactly how something is suppose to be, and the server will blindly follow out the command.

This is because unlike you, who have you learned about networking and how Roblox works, most users do not. In order to simplify the development process, Roblox made it so every change on one client, results in the same change on every client. That is, Roblox hid (obfuscate), the networking, leading most users to think of Roblox game development as a single-world thing.

Clients talking to each other, with no delay, and no differential experience. If it happened on blue client, we assume it has happened on yellow client and green client. We know this is a lie. A horrible horrible lie that makes developers find all sorts of bugs in their games.

• Hackers can do whatever they want to your game, and Roblox’s server will diligently carry out this task. Yellow client can tell green and blue that, “this world now has rainbows and unicorns, oh, and the murder is now a popsicle,” and lo and behold, it is the truth
• Developers assume data travels instantaneously, but in truth, it does not. That is why Roblox had to add WaitForChild() and other things to help facilitate the loading of Robloxgames. Furthermore, this assumption can lead to weird glitches that confuse new developers. The reason why wait(1) seems to fix most scripts is because it gives Roblox enough time to finish telling the other client(s) and anything else that X happened.
• Roblox replicates (that’s a fancy word for “tells every other client and the server”) every single change on the client to the server. Does the server need to know that your background frame changed from transparency 0.5 to 0.51 as you animated it? Nope. Will it know? Yep. And remember, each message takes resources and time, leading to less for the physics and other important information. This contributes immensely to lag.

This design is very intentional, and makes it a lot easier to hop into game development on Roblox. On the other hand, the side effects are a lot of inefficient and laggy systems. That is why Roblox introduced FilteringEnabled a year ago, after struggling for 7 years with the “single-world” model.

What does FilteringEnabled do? FilteringEnabled basically prevents the replication (that’s a fancy word for “tells every other client and the server”) of properties that the client makes to its own world. If you change the color of a brick from red to bright pink on your own client, then that brick will be bright pink on your client, but not on everyone else’s — given that the game has FilteringEnabled on.

So how does anything change in the world (for everyone, that is)? The server has to make the change. If you make a new brick on your client, it will be “local,” only on your client. For it to become global, the server must make it and tell everyone about it. Because the server tells all the clients, and we assume the clients will accept the server’s version of events (the “true” version), then it is up the server to make these changes.

To facilitate this, Roblox added the RemoteEvent and RemoteFunction objects, which is basically a way for the client to tell the server “Hey! I need you to make XXXX” or “change YYYY.” The server can then decide whether or not to do this action or not. Of course, most developers put little to no thought into filtering out the data sent in these events, but this is ok. Even if the player can tell the server “give me 10000000 moneyz and 200003534 cookies,” the player cannot step beyond what the server was programmed to do. Most importantly, the server cannot find itself replicating rainbows into other clients when a hacking client has no way to request that a rainbow be made.

Developing with FilteringEnabled

The biggest issue with developing with FilteringEnabled is people not understanding what is happening. As you have read this article, you should understand now how this happens. The developer decides that an event needs to happen, say, a flower needs to appear.

The developer programs some sort of input from the client, say, the client clicking on the ground. This is great. The client clicks, and a flower sprouts. But wait, the flower is only on the client.

The developer does the obvious thing: Tell the server to make the flower. This is great, we get flowers everywhere.

Here’s the problem. That message from the client to the server — it’s not instantaneous. The server finds out, and it makes the flower as fast as it can. And then it tells the clients “hey look! a flower!” and this takes even more time. And this is what looks like lag. The game took time to respond, and players hate that.

There’s a solution, it’s the one Roblox was doing for us all along.