I do understand why you guys would want to squeeze in as much power efficiency from the servers as possible however entirely forcing experience servers to run at 30-10 fps (without even a warning) isn’t the way to go. I’m not sure why you guys believe that making such drastic changes without even notifying anyone would not affect anyone. 9/10 times something happens.
That being said, I do like the idea of having server framerates be reduced HOWEVER the framerate reduction should be something done ONLY by experience developers! I don’t think i would mind if i could lower the server framerate in some lighter and simpler experiences however i would also want more demanding and fast-paced experiences to use a high framerate to ensure reliability. I believe adding a MANUAL framerate slider in like ServerScriptService would be best!
Would be good if devs get an advantage for using lower server update rate. A lower framerate is objectively worse for us devs, since we don’t pay the server bills (directly).
If it’s not incentivized, nearly no dev would use it. There’s simply no reason for us to deliberately choose a lower update rate.
A good motivation would be reduced profit percentage cut, but I’m just dreaming now .
Anyways, some users report issues with animations being stuck in an intermediate state. For example being partially sitting/partially standing up.
Can’t say with 100% certainty that it’s due to this, but started occuring yesterday, so most likely due to the latest Roblox update.
Shipping this without telling anyone is crazy. Roblox experiences across the board rely on physics and frequent code updates, both of which suffer heavily from this change. This should have been a survey, then it should have been opt-in with an announcement post.
This is such an obviously bad way to handle this experiment that I find it difficult to explain why. I can’t put myself in the mindset of someone who thinks this is an appropriate way to test a hypothesis. It’s such an obvious mishandling. Any developer could have told you how this would impact games.
Limited the server to 20 FPS, task.wait() goes below 0.05 but task.wait(.01) doesn’t even task.delay is affected so i guess every yielding function behaves like that, at least when limiting server FPS, would be better if they provide a way to test the different frequencies if they really go through with this idea (I personally hope it doesn’t happen)
We have stopped the experiment, and the vast majority of you should no longer experience any issues related to the experiment within the next few hours. The issue will be fully resolved for all in the next few days. Please let us know if you still encounter problems.
We apologize for the inconvenience and thank you for your patience.
For context, we started an experiment on Wednesday to test different server framerate values on RCCs. We tried values of 20, 30, and 45 FPS on small cohorts of RCC instances. This experiment aimed to explore opportunities to improve our hosting resource utilization to offer more capabilities to the developers’ community.
We have received a lot of constructive feedback from the community since the experiment started, and we are grateful to everybody who provided it. We will be better about communicating these experiments proactively in the future and welcome any feedback on the matter.
Thank you for the swift responses and commitment to improving communication over such things in the future. I’m sure that a lot of developers understand where engineering is coming from regarding these changes but they are not a right fit for the Roblox platform at this time, I feel.
I personally would not be opposed to another such experiment in the future if it means better server infrastructure and relaxing costs where required (that can then be delegated to other important areas) but if there’s no input for developers here at all, be it to configure their own server framerates or to even finance better servers themselves, this is a dangerous thing to do unannounced.
I hope that internal Roblox culture will get better at providing developers notices, tooling and alternatives FIRST before performing any backwards-incompatible changes. The platform has been crippled multiple times because of this happenstance and that can lead to time, money and audience loss for developers and the platform together. First-class citizens to Roblox need to be better respected.
Since some of our experiences have been part of this experiment, would you be able to share the summary of the results? I.e. what this means for developers based on what was learned, and explain a little more about expanding capabilities?
Im very intrigued by this, hoping we can get better performance on our train simulator. These types of games are notoriously expensive.
While my experience doesn’t seem to have been affected by this, I am absolutely baffled that no one involved in this experiment threw up a single red flag about how this was implemented.
It seems pretty obvious that this would’ve fundamentally broken a number of fast-paced games.
How does something like this get to the point of being pushed live without anyone realizing what the obvious end result would be??
This was egregiously beyond the point of “we need to do better.”
.
even task.delay is affected so i guess every yielding function behaves like that, at least when limiting server FPS, would be better if they provide a way to test the different frequencies if they really go through with this idea (I personally hope it doesn’t happen)