We are happy with the recent announcement of increase performance of Play Solo, however, this has not solved our problems. As we have expanded Pet Simulator 99 to have multiple worlds, 50+ different “mini-dungeons”, 1000+ pets - we have encountered extreme difficulties when it comes to play testing.
Every time we press Play, it can take up to an entire minute before we are able to move our character and test. It has brought development times up significantly, to the point where we avoid testing things until we are entirely done coding.
Furthermore, stopping a test can also take another 30 seconds just to get back to the editor.
We have verified that our library modules are loading in less than 500ms on the client and server, this is not an issue.
From what we can tell, it appears to be something related to assets.
We would like to work with Roblox and identify the root cause of this slow Play Solo issues with Pet Simulator 99.
The maximum amount of time a script can prevent a server from shutting down after all players have disconnected, in order to save to datastores etc, is 30 seconds. This is also maintained in Studio by preventing the Play Test from ending until the blocking scripts finish running or they reach the aforementioned time limit (I believe it also gives an error if the limit is reached, but I’m not sure), if that sounds important.
This is not due to a script running. It gets out of the game within 3 seconds, but then studio lags / is basically frozen for another 20 seconds waiting for assets to load / textures to load.
Can you try disabling all plugins and see to what extent it improves speeds? Specifically, using the “Disable user plugins in Play Solo” setting? A lot of the work in Faster Play Solo was about disabling Roblox plugins, but even Roblox plugins were already quite optimized for play solo time in ways that user plugins are not/cannot be.
All large projects experience these issues and regardless of development environments.
Usually large codebases like this heavily modularize, for example putting the common code into a package and having the tests be a different place might be an option.
Having said that we have ongoing projects to make loading times faster but the gains are going to be gradual.
It’s impossible to take a microprofiler dump because the microprofiler cannot be interacted with while the game is loading in, resulting in useless data.
You should be able to Ctrl+F6 before play solo, click play solo, then dump frames. That shouldn’t provide useless data and you don’t need to interact until it’s finished.
After doing some debugging, it looks like everytime I play-test, it takes a auto-recovery file which takes roughly 12 seconds to complete before the game even starts loading:
13:38:32.441 [Dev] Pet Simulator 99 @ 15 May 2024 13:38 auto-recovery file was created - Studio
I have this completely disabled in my settings, but it is still happening.
Here is a capture I just took, it looks like a lot of packets + random core script stuff, such as PlayerListManager.
The issue is that I have no way to capture the events that occur prior to this, and there is a 10-15 second gap where the entire studio window is frozen whilst the Auto-recovery file is being saved.
I have also confirmed all of those network packets are not being sent by us. We have a centralized system for network events and nothing we are sending matches the frequency of which those packets are being sent.
I tried setting the path to a flash drive, removing the flash drive, and then hitting play - however, it still tries to generate the backup and save it, so this was no help.
For context, I am running:
13900k or 14900k depending if I am at the office (very little difference between both)
128GB or 192GB of RAM
RTX 4090 on both PCs
Windows 10, with very minimal applications installed.
Another dump. It’s extremely difficult to capture the beginning of the play-test. Studio is completely locked up and the MicroProfiler interface does not respond to clicks until after the complete freeze has ended.
First of all, thank you for the microprofiler dumps. We can only make things better together.
As far as the platforms and codebases are concerned, I can relate to the frustration; I’ve run into this multiple times during my professional experience and the two avenues to take were: either improve the dev environment or the codebase. Often both of these approaches are needed.
As far as Roblox Studio is concerned, we’re currently working on improving the auto recovery that you mentioned. The fact that it saves even with the setting disabled is not acceptable.
There is also a workstream to speed up serialization / deserialization.
Our main focus is stability and performance right now as mentioned here and the improvements will keep coming.
