Update: this no longer works with the recently imposed restrictions, although I’ll consider recreating something similar in the future to work with these changes.
With the release of MessagingService, a wave of creations originally impossible to achieve have began popping up. Developers can now create global chatrooms, easily broadcast global announcements and setup basic match-making systems. However, out of all these, one particular concept really caught my attention: @Hanfian’s ‘infinite player server’
“How on earth did he do that?” was my initial reaction, followed by a week of experimentation with the new API. By the end of the task, I’d created a place where players could walk, swim, climb, dance, chat and interact with other players from completely separate servers live to 3/10th of a second:
https://i.imgur.com/7ZEShcN.mp4
How it was made
- Every 1/10th of a second, record information on the server about the player (e.g. did the player jump, chat, where are they standing, facing, etc?)
- Every 3/10th of a second, gather these records and fire them to all servers using PublishAsync. We’re firing off every 0.3 seconds as the limitation is
150 + 60 * number of players = 210 per minute = 3.5 a second
which means we could fire off a message every 0.286 seconds (to 3dp) before throttling the service. - When the server receives data on a player via SubscribeAsync, add this to a table which is then fired to the client every 1/10th second (we do this to prevent throttling the client).
- On the client, use this information and setup NPCs accordingly for each player, replicating their original movements.
- If data on a player is not received after x amount of seconds (e.g. 5 seconds), assume the player left and delete the clone.
Creating the first ‘200+ player server’
So obviously I didn’t stop there. With the foundation in place, I set off to create the first ever ‘200+ player server’. Of course this wouldn’t be a ‘real server’ but more of a projection of one to give the illusion that everyone is in one single server.
The first attempt was like a blue whale atop a straw-bridge. As soon as it hit 100+ players, clients would begin to disconnect under the immense strain.
This is where I came up with the plan to introduce a filter system: depending on your ‘intensity level’ (which is automatically set based on the number of players and can also be toggled), information on clones will stop being processed from a certain distance away and their parents set to nil. Additionally, the system was adapted to only introduce 2-3 clones per second, instead of all at once when joining the game. This significantly reduced lag and ultimately helped in hitting the goal of a 200+ player server.
On the Saturday, 5 days after beginning development and with the help of @Alvin_Blox, KreekCraft, @DeeterPlays and @ObliviousHD, we achieved our goal of a ‘200+ player server’:
https://i.imgur.com/5AqjLY6.mp4
Above: Hitting 200 players for the first time
https://i.imgur.com/JOtHTrX.mp4
Above: An in-depth look at the filter system with 300+ players
Future possibilities
You can find an open-source version of the project here. Hopefully with more minds involved the concept can evolve beyond a good 'ol rick-roll. Some thoughts so far include:
- Immersive RPGs/Worlds where players explore all together.
- Social games like Habbo Hotel or custom houses/builds where players can join other rooms instantly without having to teleport between servers.
- Playing in-game with others while you play in Studio Test Mode (studio access for MessagingService would have to be enabled first).