I’m happy that Solo Play is getting improvements. Opening 3 different studio tabs just to test a minor piece of code is extremely inefficient.
Good work!
5 Likes
Sounds like the real issue is that Test Server + Test Player opens up multiple windows for no reason, condensing it down to tabs has already been suggested.
3 Likes
They can set it to the group’s owner (creator) friends.
1 Like
Thanks for the feedback! I definitely agree that this change isn’t an obviously good one. We have yet to experiment with this from the usability point of view. However, something I want to emphasize - we are trying to solve the problem that new developers encounter when not using Experimental Mode. We really need to force everybody to start with FE (EM off) - this is why we’re switching templates, this is why we’re pushing on Play Solo to be correct (it was always important, but it’s absolutely crucial for this). Starting from EM means that by the time you have a playable game, no matter how simple, it breaks when you switch to FE (which you’ll need to do to have people who aren’t your friends play!). Then you’re faced with a daunting task of a) learning how to do things in FE, b) rewriting many features you’ve already made. This is obviously unhealthy long term. (addendum: not sure about the current state of things, but I remember a conversation with developers of some popular games a year or two ago about their game not using FE and the common sentiment was that it’s so much work to “fix” the game that they’d rather leave it as is and just make a sequel that uses FE from the start)
So the assumption is that FE is on by default, if you’re making a new game it’s FE, and the only real case for EM is “I’ve made a game before 2018” - which is a separate issue. With that in mind, we need to figure out what the absolute simplest way it is to start to build games in FE, and why we’re thinking that a detour - not immediately having to learn the “right way” - may be valuable. There are some thorns in the UI specifically so I’m not sure yet how valuable this can be, but do note that this paradigm is frequently used in many other APIs (you can listen to click detectors, touch signals, tool equip and some other client-side events like that on the server; and of course server in many cases can modify the player-observable world state without client interaction).
As a meta point - I would highly encourage you and others to use the adjective “new” instead of “noob”. In general less aggressive tone is good.
I do not agree that we need to immediately force everyone to learn the “right way” of doing things. I’ve heard this sentiment from developers who already know the right way and have seen the problems of the wrong way, but we need to remember how we all started. The thought here is that assuming FE is always on for you from the day where you don’t know how to write code to the day where you are working on a front page game, what is the learning curve and how to make sure there are as few “bumps” on that curve as possible?
A definite possibility is explaining the client/server split from day 1, and helping with usability of RPC - which we do want to try to tackle as part of this (see “code wrappers” mentioned in OP, or “server blocks” as we call them internally). Unfortunately, it’s hard to do good ergonomics on this - server blocks will help but the extra cognitive overhead will still be there, and it’s hard to remove it.
EM provided a beautifully simple computation model. You can do anything anywhere and it is replicated everywhere. Unfortunately in the world of exploitable clients this model is not sustainable, so we need to break it. But we need to try to preserve the simplicity of writing code, if at all possible. It’s definitely a good thing that you can listen to many things on the server that are initiated by the client (see my previous reply); the only question in my mind is whether a simple UI can be implemented with only server scripts and still be functional - if you need local scripts anyway then the hope is lost and we need to explain the client/server model immediately.
Obviously, if you don’t use local scripts, your interaction latency suffers. But crucially you can fix it later, one step at a time, and your entire game still works - parts of it are less fun, but lots of games that aren’t polished have lots of users; clearly the fact that you can polish things doesn’t mean that everybody does, and we don’t want to enforce quality - we want to make the creation process simple and enjoyable. The code wall doesn’t help this. The client-server wall doesn’t help this. IMO it’s vital to figure out ways to not have to understand these and still make content on Roblox.
5 Likes
Yes.
Yes.
Yes.
Yes, if you have separate cores 
I don’t remember what the resolution for this was 
Maybe @Seranok can comment.
4 Likes
Play Solo as it stands right now is very very problematic for a number of reasons:
- No other context works like this. We don’t anticipate supporting single player games / offline any time soon; the only mode for actual play for the past >10 years has been multiplayer (we’re happy to support solo 1 player/server games, but there needs to be a server).
- It creates a lot of ambiguity in many internal APIs; as a result, they sometimes don’t work or work via special code paths that are never hit in production
- It doesn’t have a concept of network replication and, as a consequence, filtering
Obviously we want to make sure the testing process is as quick as possible; this is why our new version of Play Solo (not sure what the product name for this is?) doesn’t start a new Studio process and has a few internal optimizations to reduce the overhead. It might be slower on really large games that don’t use streaming, but a) you can use streaming! :D, b) you might be pleasantly surprised. And without question we want to keep improving iteration times with or without this change - if your game takes a while to start in test mode, you can always tell us about that and we’ll see if we can help.
I don’t fully understand your use case - feel free to explain it - but it feels like you could rework the play solo specific part of your game to work via replication to preserve the workflow efficiency.
3 Likes
Hey developers,
Heads up that this change is now live! Feel free to comment below on the change.
Happy developing!
1 Like
Just noticed something.
Due to this security risk, we will be making changes to prevent access to Experimental Mode games to anyone other than your friends.
Does this mean every place pre-2015 or so with an inactive developer is effectively dead? Historical classic places like JJ5x5’s Thrillville (which I can for whatever reason still visit), builderman’s old places, etc?
18 Likes
Sounds like it, which is a huge shame. Quite a massive cut in games just buried, with no way to access them. There has to be some middle ground which keeps security at a decent level, while still leaving these games accessible in the future.
6 Likes
My solution that I admittedly haven’t thought about too much is making it so you can’t search for experimental games on the Roblox search and you can’t follow someone into an experimental game. Sounds like a good middle ground to me?
4 Likes
I’m apprehensive about allowing developers to control player GUIs from the server, but code wrappers sounds interesting provided developers use them within reason (they won’t, they’ll do horrible things). I can see this enormously simplifying synchronization for less critical things though, and I’m pretty excited about that.
However, I’m very upset about cutting off the discoverability of experimental mode games. There are millions of old games that I want to visit for one reason or another. I want to visit them for nostalgia’s sake. I want to play those games with friends on a Friday night and abuse gear for an hour. I want to use them for inspiration or reference for other projects. Other players may want to do this, and more, as well.
There’s nothing like joining someone’s obscure pet project cafe, last updated in 2009, with friends, and burning two hours playing with hinge wheel vehicles that flail violently all over the map. I want to be able to find those games.
And, I desperately hope that this quote doesn’t mean outright stopping players from joining those games once they manage to find them.
If you’re going to do this, please at least take into consideration that 13+ users do not need to be sheltered from these games. I don’t see anything here mentioning these changes not affecting older users.
11 Likes
/u/QuiteAmazingStuff on Reddit left a pretty interesting idea which I feel would be one to look into.
The first one isn’t as much, more of a last case scenario, but the second one I feel holds up nicely. The biggest issue I can see here is edge cases such as “what if the original person leaves” and “what about the friends of their friends”, but those would be issues that could be polished up and solved, depending on which angle Roblox wishes to go with implementing this.
25 Likes
I think this is bad in quite a few ways, FilteringEnabled allows developers to make a fresh start on their games, and the reason it exists is for increased security and often decreased lag for players.
Although the basic: not replicating changes made on clients to the server is very much important, what is also important, possibly to a greater extent, is securing Server and Client communications, as well as verifying anything replicated between clients.
The problem I have with this is that I think we’re getting too close to essentially saying lets have filteringenabled in principle, i.e. client and server model, but return to the old system in the way we code things, anyone could quite easily create a client script and a server script which result in replication of everything that’s done on the client to the server, whilst still technically having a FilteringEnabled game, but we don’t do that because it completely removes the point of FilteringEnabled.
Running UI events and actions from the server confuses the setup of the client/ server model, and also causes lag.
I’m not too sure what ‘code wrappers’ really means, but if it means translating previously clientsided actions to serversided actions and clientsided actions respectively; it sounds a lot to me like we could end up replicating things done by one client onto others connected to that server (when not desired).
FilteringEnabled has always been a seal of quality and security, but it’s turning into a sort of hacky setting partway between the old and new system. I feel like experimental games should just be 13+, promoted less, hidden from search and not allowed to be advertised/ sponsored; but no further. It means that if someone wants to make that leap from making fun, recreational games, to making professional and well made games, they need to also make the leap from the old system to FilteringEnabled, and from bad to good code.
The play solo update is great, and very welcomed, as well as the CreatePlaceAsync.
7 Likes
For Experimental Group games, do the visitors have to be a Group member to access it? Asking for a non-Dev friend who has a military Group. Hard to have a warzone if the raiders have to be on your friends list or members of your own army… I’ve been trying to convince him to transition to FE for months, but he prefers those “Ro-Nation standard” weapons that never were designed for Filtering.
1 Like
This is a case where an active game has an active developer. No excuses, fix your game to not be on experimental mode.
2 Likes
Agreed. I don’t know why those war clans cling to such outdated systems and hold them in high esteem. My raycast scripts do more with 50 lines of code than theirs can with 1,500. But mine aren’t “up to standard”…
1 Like
We are not making FE filtering any weaker - all of these changes don’t change the fundamental security model, they just try to make FE more approachable. The problem with the “leap” idea you’re suggesting is that it’s very large, and rarely happens at an instant. Is a game that has 1000 concurrent players professional? What about 200? It’s hard to make a judgment call here. Plus the fragmented APIs mean that the scripts, libraries, toolbox models, etc. may or may not work in either mode.
1 Like
I don’t necessarily define ‘professional’ by player count, I define it by game quality and the intent of the developer. Experimental mode is great for people who just want to mess around with friends and meet new people while doing it, as well as those who have small tightly knit communities on Roblox.
But, in my opinion there is certainly a point, or if you like a line that is crossed, where people decide to make a game with the intent of it becoming popular, or at least working reasonably well and looking good. This is the ‘leap’ I’m talking about, sure, before this you can mess around in studio with parts and scripts, but once you try and make a proper game I think it means you have the willingness to learn everything you need to make that game, therefore, it seems like the perfect step up from experimental to filteringenabled, and weakening FilteringEnabled, (I know that the fundamentals aren’t changed, but the approach Roblox presents to its players towards FilteringEnabled is important) means it’s likely future games by current players who become developers will end up at a lower security and efficiency level than if this change hadn’t been made.
3 Likes
Thank you!
1 Like