In July of last year, we posted about some changes that we made to prioritize games that were not in Experimental Mode on searches. We know that Experimental Mode is useful for creating your first Roblox game, but the risk to the security of your game is significant. Due to this security risk, we will be making changes to prevent access to Experimental Mode games to anyone other than your friends. You can find that original post about this topic on the forum.
As a first step to increase security for all users of Roblox, we will remove Experimental Mode games from sorts in the next few days.
Over the next few weeks and months, there will be improvements to make it easier to develop games without the use of Experimental Mode.
Add improvements to Play Solo to improve the accuracy of testing games locally
Implement code wrappers which developers can use to run code on the server when it was previously run on the client in the past
Allow games to run User Interface scripts from the server
CreatePlaceAsync will no longer cause your games to be listed as Experimental Mode
If your game is currently in Experimental Mode, we recommend that you turn off Experimental Mode as soon as possible to ensure that your game is discoverable and playable by others on Roblox. You can find more information about the security issues with Experimental Mode, as well as guides on how to convert your game to Non-Experimental Mode on our Developer Hub.
It sounds like this is going to involve client and server contexts for scripts. If this is the case, will we get a way to toggle the latency for testing with high-ping connections, and potentially be able to change this in real time for unstable connections?
Can we have some sort of quick way to disable experimental modes on all our places? I don’t know if it’s just a glitch, or maybe experimental mode has been on by default, but it’s very irritating that almost every place I’ve published to my profile is apparently in experimental mode
But I certainly didn’t enable experimental mode for any of these places and they’re all already developed with server client connections in mind. It’s kind of annoying.
I’m pretty sure most of these aren’t even actually in experimental mode
If this means that server scripts can modify client UI, I don’t understand why this is a good thing. Server scripts really should not be touching client UI at all. It’s an anti-pattern and often produces undesirable delay times in user interaction and effects. It also pollutes the network with stuff that really doesn’t need to be there. Does this also mean that user input events are going to be replicated to the server? Generally, having a set of endpoints (remote objects in Roblox) where your client talks to your server that explicitly define actions is the best practice. Blindly sending user input and having the server figure out what to do is just unnecessary work for the server and introduces lag time. I think we’re better off not having the option to fall into this pitfall and only allow developers to do this when using Experimental Mode, which is the current behavior. When it comes time to make a real game, best practices should be encouraged rather than letting people shoot themselves in the foot.
Now, I hope that I’m wrong about what this means and if so I’d love to see some clarification as to what is meant by this change.
Are you going to fix not being able to easily tell if your game is in experimental mode? My game was blocked from half of the Roblox audience when it was put on featured a few months ago. I realized this a week in with help from an admin that pointed it out. My test place was filtering enabled but had not been marked as such due to me not joining on the client.
If this is fixed with the other additions you’ve mentioned, we’ll be “A okay!”
This is a very bad idea in my opinion. The current model resembles modern networking and UI having to use the networking tools provided is a really nice stepping stone to further understanding RemoteEvents. Furthermore, the server shouldn’t be communicating with anything UI related at all (as in, the server shouldn’t care about Frames, ScreenGuis, any of that, just the data they’d send), you’re just going to end up with new developers not understanding when to use LocalScripts and we’ll get laggier and laggier UIs.
One of the big ways that games get pushed into Experimental Mode unexpectedly is through the use of CreatePlaceAsync(). We’re going to be changing the behavior of that API so that it doesn’t create places in Experimental Mode by default.
We’re also turning off Experimental Mode for the templates, so that new games will start in non-Experimental Mode status.
If your place was pushed into Experimental Mode by a different way, please let us know!
Not in V1, but we did discuss this for future versions… And yeah, Play Solo will become fully accurate, with separate client & server contexts.
P.S. Oh actually, I think even in V1 the IncomingReplicationLag setting in Network Studio settings will affect simulated ping. It’s pretty obscure, we want to surface this better long term.
We are considering a system where developers have an option to implement their UI actions via server scripts. This doesn’t need to impact developers who want to (rightfully!) continue coding the UI via local scripts - we’d only dispatch events if the server script is listening. This might help people get into writing code on Roblox without having to immediately tackle the complexity of client vs server. Obviously for complex UIs you kinda need to stay client-side.
In fact most of the pieces required for this already work and have worked for some time - you can try this today, but you need to clone UI to PlayerGui on the server manually, since UI is cloned from StarterGui on the client.
I never had a reason to join the game on the website so the game was created as experimental mode and never updated when I uploaded my place. Changing the templates might fix this issue
I know that it won’t impact the status quo, but I feel like you might be making new developers worse off by doing this. Experimental Mode already lets new developers do things on the wrong end (server code controlling client UI, creating instances on the client, etc) to get acquainted and make quick prototype games. But I don’t think this should be encouraged when Experimental Mode is off.
The whole point of turning Experimental Mode off is to take off the networking training wheels and learn the distinction between server and client processes. If new developers are allowed to control the client UI from server code, I think this will blur the line between the two and encourage bad practices.
In this situation, I think it’s better for the developer and for the quality of Roblox games in general if you don’t allow developers to fall into this trap and instead enforce that users do it the right way from the start.
(I’m speaking from experience here – On Scripting Helpers, new developers often run into this problem and I can’t think of a single situation where they would have been better off had they been allowed to control UI from the server. Usually when someone tries to do this, they have a bigger problem or a gap in their knowledge – hitting this wall helps them learn and grow as a developer.)
Anyways, I appreciate the explanation and hope you consider my feedback in your considerations.
How does this work for group-owned games, since groups can’t have friends?
Problem: Client/server communication is too difficult for noob developers to understand Solution: Make it even more confusing by straying from correct implementation that developer will eventually have to switch to anyway when players complain UI is too slow ?
This is a really bad idea. Large numbers of games on the platform are going to feel awful to use because there’s latency for all user input – imagine GUIs as slow as loading web pages. Players are going to think poorly of Roblox, and not the developer. Even the intent of making this easier for new developers is toxic because we’re only making it more difficult for them in the end when they have to rip-off the band-aid. If anything, this just stagnates developers into low skill levels.
I designed my game to share client-agnostic lua objects and modules between client and server scripts, which makes my game start faster when testing. Developers should use RunService:IsClient() and RunService:IsServer() if they need to. PlaySolo’s current behavior also has implications for single-player support if that becomes viable some day.
Would “_G” become different from local/server scripts in PlaySolo?
Would ModuleScripts run twice if required from both server and local scripts in PlaySolo?
Would connecting to RunService.RenderStepped from a server script error in PlaySolo?
Do server and client contexts run on separate cores?
How does this affect plugins running during PlaySolo? (do they run twice?)
I may be understanding this incorrectly, but I don’t think the current behavior should be entirely removed.
I personally think it should be so you don’t have to run a local server that lags 99% of users who use Roblox Studio. Though, if you want the old method, I think having an option for “TreatPlaySoloAsServer” should be a thing.
I just realized Shard Seeker’s entire data system would need to hash, serialize, and replicate tons of data to the client just when I want to test small tweaks unrelated to networking. My game has an entire compile process which fragments, simplifies/hashes, then recombines this data for the live game, but it takes at least 20 seconds (and will only take longer as the game grows). I can test in server-client mode normally, but the game’s fragmented data cannot be recombined unless the entire data system is loaded, so there’s a lot of remote activity. It’s not that much slower, but seconds add up when trying to rapidly test new features. Play-Solo is great for this because the client can access server-defined data with no extra latency.
Right now Play-Solo starts my game in a few seconds, but introducing separate server/client contexts could more than double that. New developers may have trouble figuring out networking so this may be useful as default, but I’ve been developing Shard Seekers for over 2 years and I like my workflow.
Edit: Well, I could probably write a hack that replicates the contents of ServerStorage and runs the entire game on the client context, but I’d prefer not to.
Every change breaks someone’s workflow, and I think more people would benefit from a proper client/server distinction even in play solo rather than keeping it the way it is (in my experience, most people use play solo as a faster version of test server + test player).
