Move all game-configuration properties out of workspace an in to a standalone "GameFlagService"

My game has hundreds of thousands of objects in the workspace. It seems every few months there’s more and more properties added to workspace which need checking/tuning. Clicking workspace lags out my studio, and everyone else on the project’s studio for at least 20-30 seconds. This is a very frustrating issue to have during collaborative development.

After 15 years of making games on this platform, 99% of the time I click on workspace it is to check out a slightly different gravity, or now a different wind direction… Configuring things like how sales are processed, animation throttling, animation controllers, signal behavior, physics, etc do not make sense here. It would make more sense to put all these properties in their own service. This way I never have to click workspace again.

This is overwhelming:

7 Likes

This is definitely not an issue of the properties (and is more likely a result of the highlighting behavior). Can you file a separate bug report for this alongside a microprofiler dump?

2 Likes

I know it isnt an issue of the properties. It’s an issue because selecting workspace forces me to select 500,000 instances that are a descendant of workspace in my large game map. The point of this post is to say that I do not want to click workspace ever. It’s slow on big projects. It lags everyone out. Additionally, It’s overwhelming to see a ton of properties in that same service where those properties have no sense being there, but they’re what is requiring I click it in the first place.

If the properties are moved elsewhere, to example a service called GameFlagService, I can click it to my hearts content and never have to deal with having everyone in the team create lag out from selecting half a million instances. It’s like… really bad design.

I don’t think a microprofiler dump is necessary in this case, it’s very easy to reproduce.

2 Likes

It sounds like you’re talking about two separate issues, one can be fixed with performance improvements and the other is your actual feature request. The lag others experience when you select workspace may come from team create showing a selection on anything you click.

2 Likes

i’ve had that issue before, and i still do.

they need to organize the workspace’s properties itself
it’s pretty much a overencumbered feature hell at this point

aftermath?

1 Like

It’s silly to make bug reports about how slow studio gets with hundreds of thousands of instances. Studio was built was QT, which is the bane of all the problems. Without an entire rewrite of the application, I don’t see it getting higher than our current 10 fps in studio. That’ll take years. In the mean time, this is a perfect “low-hanging fruit” solution for all the tunable game-properties that requires I select workspace. Simply put, make it so I don’t have to select workspace that often, or ever.

As a temporary workaround you could use

workspace.PROPERTY = somevalue

in your studio console so you don’t have to worry about it highlighting everything

No it’s not to both! Your performance bug is almost certainly just related to something like highlighting–Qt would have no impact here if it affects other people. Please do file bug reports for performance issues you see.

2 Likes

We get 10 fps in studio because of the size of our game. It is definitely the fault of the UI library powering it–It doesn’t happen live, so it’s not the engines fault. Studio is not designed to create a game to the scale we are creating.

Studio is designed to create games of any scale! Please file bug reports with microprofiler dumps!

1 Like

I do agree on moving all the flags to a new service. Stuff like SignalBehavior and EditorLiveScripting have nothing to do with workspace and are simply put in there for convenance.

If all these properties were deprecated and then given parity to a new GameBehavior service, it would make things much more intuitive and organized.

3 Likes