Changes to Experimental Mode games: now hidden from sort

Updates Announcements
#17

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.

4 Likes
#18

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.

1 Like
#19

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.

2 Likes
#20

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).

4 Likes
#21

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
#22

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
#23

They can set it to the group’s owner (creator) friends.

1 Like
#24

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).

#25

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
#26

Yes.

Yes.

Yes.

Yes, if you have separate cores :slight_smile:

I don’t remember what the resolution for this was :frowning: Maybe @Seranok can comment.

4 Likes
#27

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
#28

Hey developers,

Heads up that this change is now live! Feel free to comment below on the change.

Happy developing!

1 Like
#29

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
#30

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
#31

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
#32

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.

10 Likes
#33

/u/QuiteAmazingStuff on Reddit left a pretty interesting idea which I feel would be one to look into.

image

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
#34

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
#35

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
#36

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