Backrooms Online: Developing a networking solution for a MMO game.

What's a Backroom?

“If you're not careful and noclip out of reality in the wrong areas, you'll end up in the Backrooms, where it's nothing but the stink of old moist carpet, the madness of mono-yellow, the endless background noise of fluorescent lights at maximum hum-buzz, and approximately six hundred million square miles of randomly segmented empty rooms to be trapped in. God save you if you hear something wandering around nearby, because it sure as hell has heard you.”

Recently, there is a new trending topic on the internet, especially among younger audiences - the backrooms.

The origin of the backrooms is rather mysterious, it began when a person posted a picture of a yellow wallpaper (the one above) onto a forum called 4chan. Another user, commented with the quoted description “if you're not careful and …”. This marked the beginning of the backrooms.

Soon, entire fandoms were created by the internet, which detailed descriptions about the different levels in this intricate and expansive maze of endless corridors and rooms. The backrooms were born.

In short, backrooms are liminal spaces, which is a kind of unnatural interior setting that gives a person a level of eeriness and familiarity at the same time.

The Pitch

There's already a lot of Backrooms games on the internet, but the concept of liminal spaces and backrooms in general is so alluring that I wanted to make my own. While playing a couple of these games with my friends, I realized that, there is a lot more potential to be explored in this setting.

In the backrooms, there are potentially millions of people who “no clipped” from reality into this liminal space, and thus arises the idea of settlements and groups of people wondering within this giant interior. What if I were to make an MMO out of it? MMO stands for Massively Multiplayer Online (Game), it's different from normal multiplayer games in that, it has a massive amount of players, online, in the same world (thousands by current standards). Imagine if you could explore the backrooms with countless other players, establish settlements that anyone else could visit.

The biggest roadblock to this is: networking. Multiplayer games typically use a Client-Server model, like the diagram below:

Clients could be a phone, a PC, a tablet, anything that goes to the end user. The server is what we typically refer to as the cloud, the one that handles everything upstream. In this game, the clients are the players and the game, while the server does the heavy lifting by syncing players with each other, prevent cheating, etc.

The problem is, there is a limitation in the amount of connections a server can handle. Internet traffic is almost always bottlenecked by bandwidth, the amount of data that can be transferred per second.

Server Meshing

Luckily, a solution exists to avoid this - server meshing. The concept is to subdivide the game into different sections, with each section being handled by a single server. This network forms a type of “mesh”, hence the name. However, rarely do MMOs implement this model. Star Citizen with over $600 million in funding, has been stalled by server meshing for years now.

Because backrooms are mostly tight interior spaces, and do not feature space battles with thousands of people, there is rarely a reason for hundreds of players to group together, or be worried about people beyond their immediate vicinity. This offers a easier solution to server partitioning.

In the example above, we have partitioned the game into grids. The grid which the player is in is highlighted in blue, we also have 3 other neighboring grids. We do not need to include all 8 neighbors because, the others are too far from the player to have any effect.

To implement this model, I needed a framework that was lightweight and flexible. Luckily, Riptide Networking was exactly what I was looking for. A simple and free C# framework that only handles UDP connections (transmitting information in bytes between client and server). It was so good that I even sponsored it on Github.

When the player is connected to neighboring grids, the player also connects to the servers of the adjacent grids as an observer. For example, one of these adjacent servers might be Server B, our player on Server A (the current grid) connects to Server B as an observer, receiving all updates from server B, such as player movement. This way, the player can see people on the “other side” (server B). However, because the player itself is an observer, it does not interact (the player does not send information to server B). Players on Server B can see our player by connecting to Server A as an observer.

The hardest part with server meshing was to handle the “edge” problem. For instance, if the player walks from Server A to Server B, how do we seamlessly handle the transition? Because the player is already connected to Server B before crossing into it as an observer, we simply need to send a message to Server B, converting our status from an observer to a real player. This only takes a few bytes of data, and because the connection is already established, it would be almost seamless. Here's a video demonstrating this:

There are two windows, representing two players. Initially, both of them exists on Server A. When the player in the foreground window enters the shadowed region, it's crossing the boundary where it would be transferred to Server B. Our background player on Server A, would still see the player moving in Server B because we are connected to that server as an observer. The transition is almost seamless!