Multispace System

Feature Requests Engine Features
#1

It’d be nice if you could create multiple workspaces, like so:

-- In this example, the scripter has made houses.
-- He wants to create a seperate Workspace to build the interiors in.
local InteriorSpace = Instance.new("Workspace", game)
InteriorSpace.Name = "Interior"

game:ChangeSpace(InteriorSpace, true)

The second argument would be to transfer the player’s character to the new space.
The current space can also be changed in Studio by dragging a target workspace into the viewport.
This could be used to create seperate worlds for each level in a game, as sounds would only play in their space preventing sounds in one level from leaking into another.

Moving the levels far apart from eachother instead of using seperate workspaces is a bad idea, because geometry starts to distort and physics get weird the further away you go from the origin.

26 Likes
Replicate physics for objects not in workspace
Player.Room Property
#2

I think most of us have had that annoying problem where we have to drag some lobby or something of the sort tens of thousands of studs away from the center to prevent people from seeing it from the map.

I think this sounds like a nice idea, but there are some major changes that would have to take place. First of all, the camera (for some reason) is a part of the workspace. Secondly, terrain is also part of the workspace, do you propose multiple terrain objects? Then of course you have to deal with the character’s default spawn workspace. You’d also have to work out the sound engine dealing with only one workspace at a time…

Maybe I’m wrong, I’m not exactly an expert on the Roblox engine, but this seems extremely complicated. Perhaps…

we could just fix this pesky problem and then dragging spawn rooms tens of thousands of studs away from the center would not be a problem anymore.

3 Likes
#3

Can’t, it’s caused by floating point errors.

2 Likes
#4

This would be neat, but I have to imagine it’d be extremely difficult to implement, and they’d be better off implementing other smaller features.

2 Likes
#5

Although, if everything were positioned locally to that then you could negate floating point errors for the relative positions, and further, add the player to that space.

#6

But that local origin would also be a floating point so you would still see artifacts due to floating point errors.

Suppose everything is drawn correctly to some local origin O, and I’m at position P in global space. The translation (P - O) to draw the character and position the camera will still be subject to floating point errors if P and O are big enough.

1 Like
#7

I’ve actually done something like this in the past, but it only works on FilteringEnabled and really doesn’t like non-anchored parts without an explicitly set network owner in the space that they’re in. I’ll see if I can find it again!

#8

linking thread i made earlier
http://devforum.roblox.com/t/local-physics-replication/31332/2
How are you determining which client gets network ownership? I imagine a Lua-sided physics distribution system would be awful.

#9

Perhaps every cell would run physics normally, the difference being that parts only interact with parts in the same space, and the “active” space would be client-only, and simply affect what graphics are being shown on the client. For fine control over physics replication (and replication in general), I would love to have this feature: Manually Replicated Folder

#10

As far as I can remember I handed physics ownership to the nearest player in that workspace with a 1-second debounce. If there were no players in that world, all the parts would just go anchored until a player joined back in that world.

Unfortunately, it didn’t handle structures made of multiple parts very well. I did make it so parts under a players’ character would always be owned by that player, which made it possible to create vehicles in those sub-worlds.

#11

Oh man I’d love this. Seems unlikely, though.

#12

We could do this ourselves If we had collision masks and an instance with a property that controls if its children are rendered or not.

5 Likes
#13

There are so many places in the engines where things would have to be localized to the current workspace instead of being global:

  • Skyboxes
  • Sounds
  • Lighting
  • Camera
  • Terrain

Are there any reasons you don’t want to use multiple places and teleport players between?

1 Like
#14

Imagine I have three stages to my game:

  • On the map, playing
  • In the lobby, waiting
  • In the 3D customization window

These cases aren’t suitable for teleportation. Currently if I want to accomplish this, I have to carefully place the scenes for these places so they don’t intersect. I could unload the other scenes and then place the active scene wherever, but then a player may walk through my scene since their active scene intersects with mine. I can’t unload players clientside because that breaks replication when I re-load them.

The elegant solution is to be able to switch scenes/stages like most other game engines allow, and what this feature request is suggesting.

4 Likes
#15

I can see memory consumption becoming an issue if you have multiple large workspaces.

#16

On the contrary I think it’d actually improve performance. @zeuxcg is always chiming in on how doing things from Lua are slow and that it should be done in C++ if possible. With ROBLOX-native scenes, the unloading that we currently do in Lua could be done in C++, saving the need to iterate over lots of parts and individually tell C++ to update each one.

4 Likes
#17

If a workspace is represented as a folder in ReplicatedStorage right now, and two clients locally parent the folder to workspace, physics does not replicate between them. They both simulate the physics independently and it desynchronizes.

Can the server set the network owner of parts in ReplicatedStorage? Can this replication problem be solved without a new feature?

#18

This is the closest suggestion i could find, so i’m replying to it.

Recently roblox changed things regarding workspace.
First off, Workspace is now “WorldModel”, and a sub class of WorldRoot. You’re able to create multiple "WorldModel"s via `Instance.new(“WorldModel”), you just can’t parent it yet.

From my understanding, and what I’m told, this is just going to be for animating and viewport frames, and won’t have physics. My suggestion is, the OP, basically, add multi workspace support. or add physics and camera changing support to them.

Why you might ask? Here are some quick use cases i thought of right away:

  • Lobby/Menu models don’t have to be a part of the map, as an example, the phantom forces lobby usually has to hide under the map or something while the player is in the menu
  • Rooms. Skyrim has an interesting system when you enter a building, you load into a separate workspace of sorts. This is useful so you can put your rooms at 0,0,0 (center of floating point, less physics issues)
  • Large servers, from what I understand, roblox added multi threaded physics, and they’re working on making 200 player servers more viable. So in this case, games that don’t need a ton of server side lua can have 10 lobbies of 20 players each in their own WorldModel/Workspace. It’s possible we’re getting multi threaded lua in the future as well, that would make this an even more compelling case.
  • Say you have a large city game, and you want each building to have an interior, well obviously rendering the interior on all of them is taxing, and you could put each into their own workspace.

I’m sure other people could come up with more use cases, they’re endless!

8 Likes
Release Notes for 416
#19

They should add “PhysicsEnabled” and “CollisionEnabled” properties as well. Collision detection is mostly separate from physics. Just detecting whether 2 convex surfaces intersect is a fairly cheap process if done correctly and doesn’t require physics; however, physics do require collision detection and have a considerably heavy impact on performance.

Now think of a situation where you want to check whether a detector part is intersecting with anything else but everything has CanCollide set to false, or the case of a 3D minimap where both collisions and physics aren’t required. This would be a nice way to avoid using a hacky solution with SelectionBoxes for edges in case we don’t want the models to fire any .Touched event or if we just want to save some frame time.

3 Likes
#20

Well, I don’t like to bump a 4 year old post, but in this case I will make an exception. We still don’t have this feature, as time goes on, I find this feature more and more necessary. The standards of making games on Roblox have gotten a lot more professional through the years. Roblox has steadily become more of a concrete and professional career choice for many developers and as such many developers take Roblox development seriously. In other words, we care about optimization, efficiency, organization, and proper gameplay.

Especially in 2020 where many more game genres like Battle Royales are popular, along with the rising popularity of level-based games as opposed to open-world games, I believe it is time to implement this. This is a very basic feature/functionality that Roblox has lacked for years, and it seems that I am running into this limitation much more often than before.

In previous years I didn’t care much to use features like this, but with the addition of mesh deformation, PBR materials, Luau and so many more additions, my determination to make advanced Roblox games has increased greatly. It seems like Roblox is tripping itself while trying to rise up by giving us such advanced features like procedural sky, better volumetrics, better coding/programming, better graphics and materials, and lights while we still don’t have the basic features needed to properly utilize these.

To no one surprise, as Robox adds more advanced features we want to make more advanced games, and many developers such as my self will start needing features like multiple workspaces, AKA scenes and/or levels.

Multiple workspaces not only give us better control over our environments in terms of lighting, color grading, looks, and more, but it also improves optimization and organization. It also makes it much easier to collaborate with team members.

Many new engines have this feature right from the start. It once again seems counterproductive that Roblox is adding all these advanced features to attract more advanced developers and more advanced games when we lack basic functionality to organize our games.

I feel like it is the lack of these basic features that deter and discourage new professional and/or advanced developers from enter/venturing into this platform to give it a try.

It is getting tiring taking entire maps, buildings, and areas of our gaming and moving it far away from the center of the map just so the player doesn’t see it.

This also makes game planning very difficult as we never know how big our map might actually end up being, and if it ends up being so big it that it begins to meet up with the other section of our map/build that we wanted far away from the main map, then we have a problem. This seems like a headache during the beginning and a possible headache in the future, and it’s frustrating to know it can be solved with the implementation of a feature that should’ve been implemented years ago.

Roblox, please do not neglect the basic features in your quest to add more advanced ones as some developers such as my self will learn that it is hard to properly utilize advanced features when the basic fundamental features still need work (or in this case need to be implemented as it does not exist at all).

Please consider this feature.

10 Likes