I recently made a post about a similar topic, but less about scenes and more about specific objects and properties. Check it out here:
You’ve gone into a lot more detail with it, and I’m in full support of this. There is no reason why developers shouldn’t have full control over what replicates and what doesn’t in their games. Something as fundamental as this should always be in the developer’s control.
Brilliant post, I really hope Roblox do something about this soon. There are a lot of use cases for this kind of thing (mainly performance+bandwidth cases) which could make the games in Roblox potentially so much bigger.
:RemoveScene(String scene) is missing, also (may not be appropriate but) a more specific :GetScene(String scene).
I’m thinking some OOP might be better for this, as the system may end up being a bit more complex than CollectionService. You’d have a Scene class that handles loading, unloading, add-to and remove-from that gets returned from :CreateScene() and :GetScene(). This would lower the number of methods and signals on the main service object, allow for expansion of the Scene class to have more features and would separate scenes more cleanly from the service. Think TweenService + CollectionService.
As a developer, I have wanted to produce large train games for some time, routes that feel like they are the size of a whole county. The level of detail I want to include in the game limits the size of the map based on performance of existing large train games on Roblox. The technology to keep memory and framerate to manageable levels is something I don’t see floating around, so I will have to spend time developing it myself, using time I could be spending on adding content and polishing the game.
I think this is the direction Roblox should go for having huge universes, not the “Games” feature that is unreliable, limited, and makes devs less money.
I cannot tell you how many games I have wanted to make that would basically rely on such a feature. Imagine a space game where you can separate scenes for planets on the surface and from space, or an RPG where you can enter huge worlds and only have one loaded at once. All without leaving the server.
This feature would make it easier for devs (No need to create and maintain 50 “Game” places anymore) and would make players happy (You are always playing in the same server, maybe with friends). I can see 100-player games being much more viable with such a feature.
Even on a simple level, this would still benefit us so much. I think Roblox has to give us something like this eventually.
Thanks so much for the amount of detail you have provided in your request. I’ll be working on getting this filed today and will follow-up if I have any questions.
Yes!!!
I would be SO happy if this were to be a feature!!
The one thing I’m generally scared of while working on my game is that it would be slow even when I’m applying as minimal details as I possibly can, and it most likely won’t be a small map.
100 likes in a little over a month- I think it’s safe to say we’re all sore for a feature like this. Let’s try and keep the momentum up in January when the code freeze is over!
I like this, it would really help with massive open world environments, and provide more options to help big servers run more optimally. Dividing server / client workload is extremely essential in game development and I think this feature request would help devs do a lot with that. Also could someone please tell me why StreamingEnabled doesn’t work based on CurrentCamera Cframe and instead works off Torso position like fr how u supposed to get a cutscene in smh
An idea to possibly improve this is to have LOD zones just like you’d have the current zone. The game dev would need to make 2 levels per zone, but it would be optional and allow for farther draw distances. This could be very imperative towards making massive open worlds in roblox.
A potential (ab)use case of this feature is a surefire way to cloak enemies in combat and prevent hackers from determining cloaked player positions (can’t make visible parts that aren’t there):
all characters are assigned unique replication zones
characters of team players are replicated to each other
when an enemy character is uncloaked, it is replicated to all team players
when an enemy character is cloaked, it stops replicating to team players
Another use case:
Consider a space game that is set in an asteroid field of good size (e.g. 100,000 studs across) where asteroids are scattered across the entire map. The asteroids are not static, and can be manipulated by players. Players do not need to know about changes to asteroids that are 90,000 studs away from them, much less changes to 100 asteroids, none of which are larger than a single pixel.
Or in other words, StreamingEnabled that I control.
A note on this: If roblox ends up adding more control to StreamingEnabled in the form of adding replication Zones, it would make a lot of sense for devs to be able to choose a part (or a camera) that the streaming service uses as the center point. My game’s cutscenes don’t work if StreamingEnabled is turned on because the player hasn’t spawned and the camera is looping through a list of CFrames. If we could at least make StreamingEnabled work based on the camera position, or even just preload specific areas of the map, that would at least make the situation a lot better.
As it stands, and as it has stood for years, I really can’t see StreamingEnabled ever becoming this flexible or useful to developers. There are a lot of great examples in this thread of what people want to do to expand their games.
Considering how this is such a sore spot for a lot of creators here & how often it’s been suggested with no response other than the vagueness of “we’ll improve streaming” (which has certainly been improved, but functionally is the same as it was on release), I’m worried that for some reason or another they think a system like this wouldn’t be “user-friendly” and would rather have a checkbox that attempts to do everything for you without knowing what the developer’s intent is.
I think Roblox is slowly moving away from that mentality when it comes to developing. For instance, they removed the check boxes for bubble chat, thus giving us devs more control but also making it less simple to implement. FIB is highly customizable compared to the old lighting.
But that’s just a guess. I think the more control devs have, the better
Support! Generally, I’d love to have more control over replication.
How would you feel about Scenes being actual userdata objects, so you would have something like:
local sc = Scene.new(workspace.Model1)
sc:Add(workspace.Model2)
game:GetService "SceneService":LoadScene(Player1, sc)
I think this approach would be more in-line with the typical OOP practices (correct me if I’m wrong). The reason why I think CollectionService works as it does is because Tags essentially are strings, so there’s no need to create a separate data type for them.
Personally I wouldn’t like to have to parent all my models in Workspace to another model to be used as a scene, but perhaps a way to tag specific objects as part of a Scene, like the Collections Service.
