Today I am bringing to you a new service which will allow for massive games to run on any device without a hitch! In addition, StreamX prevents hackers from swiping game maps by not rendering all of the game parts at once.
Summary
StreamX is a combination of in-game and offsite programming which allows for efficient part streaming without causing an insane amount of load on the Roblox server causing client disconnects or large lag spikes. StreamX’s streaming services also help protect games by preventing common map cloning techniques.
How it works
StreamX is able to effectively and efficiently stream parts to a Roblox server from an outside server by utilizing the HTTP Service and some clever calculation methods. Here is the sequence of events which StreamX executes upon server startup:
StreamX initializes itself with the host server and obtains a server identifier after authenticating with the specified access token.
StreamX starts an upload sequence which uploads all data of the parts in an “StreamX” folder in the workspace to the StreamX server, this is done to prevent glitching which causes the player to fall through the ground into the void). The should take at least 3 seconds but no more than 15.
On the backend, the StreamX host server caches then passes on the data to a high-speed data server for future use.
After all of the parts have been uploaded, StreamX starts a deletion process, essentially destroying all of the assets in the StreamX folder.
StreamX sends a request to the host server asking for parts that need to be rendered. In this request is a player’s head coordinates and a throttle percentage.
Some behind the scenes magic takes place by doing a calculation for each part in the database and the host server determines if it should be sent back to the game server, if so, the part data is packaged up and sent back to the game. If not it does not send it back.
Once the game server has received all of the parts, the parts are rendered into the workspace and can be viewed by the player or players.
After a specified number of seconds the code jumps back up to step 5 to load in more parts as the player or players move around the experience.
How can I get it?
You can purchase a StreamX plan from the link below:
or
You can run StreamX on your own servers by downloading the releases here:
StreamX will be available to be self-hosted through the StreamX Lite program, which is still in development.
Demo Video (from v2.1.4):
Let us know what you all think! Questions, comments, concerns, and constructive-criticism are welcomed in the replies section below!
Development Team: @Crcoli737 - Co-Founder, StreamX Developer @pyxfluff - Co-Founder, Payment Center Developer, Beta Tester @anon61048460 - Co-Founder, StreamX Developer
Correct me if I’m wrong, but does this cause the parts to be removed and reappear or does it use transparency?
Because if they are removed there may be local scripts that need to check if that part exists but being “removed” by the player distance will not detect them and cause errors in the code.
The truth is that I see it interesting but it causes me concern.
and this would happen with normal streamingenabled as well, in fact, with any streaming framework.
custom streaming frameworks might solve this by providing events for user code to execute within the lifecycle of the being-streamed parts, while with streaming enabled, you could use a library like streamable by sleitnick.
The code removes the parts. Although the parts that have local scripts in them or need to be accessed by localscripts should not be placed in the assets to stream folder in the workspace (the parts in the assets to stream folder are deleted when not in use). Parts that can’t be deleted should remain in the Workspace or a different folder from the one that is meant for part streaming.
Another concern: can you assure us that it will be available indefinitely? Since being hosted on a web service, as in this case AWS Amazon will need a maintenance paid with a monthly fee. If it is the case of a free hosting forget this question, thank you!
I can assure you that the production version will be available 24/7 as we have several self-hosted and cloud hosted backup servers which can each take the load in case an availabilty problem or maintenence session occurs.
Very Impressive, I haven’t seen a proper chuck loading and unloading system made one Roblox. All the ones I’ve seen work as they are intended to however, when they load and unload, it lags the client, which goes against the purpose of the system. However, the unfortunate part about this is since it relies on a 3-party service, and let’s say you need to do some maintenance on it due to a huge bug, you would need to close the production breaking the games that are currently using your service. If that is the case, I recommend adding a status system that works with the game and shuts down the game during maintenance.
I’m glad you’ve thought of backup servers, but the point of my question is, if for some reason the project is suspended, could we continue to use them? And if the hosting is paid for and the servers can no longer be maintained, would there be an alternative?
And also to underline the problem it has given @shr2mp
Yes. Uptime could be a problem although our Load Balancer has automatic failover protection and will switch over to a different EC2 instance if one goes down. Although during normal operation, the load balancer will balance the load between two EC2 instances. And if all goes wrong and Amazon shuts down, CloudFlare will temporarily switch to a self-hosted server to handle the load.
If the project is suspended, we will provide ample warning to our customers and if everything fails as soon as the server is reloaded, the streaming will not begin and the game will be as if the streaming wasn’t enabled. To your second question, yes, there will be a self hosted instance of StreamX if the cloud servers fail or aren’t paid for (although I can assure you, I have the funds to pay for the cloud servers.)
— 
— 
— 
