UPS is obviously the biggest performance bottleneck for huge megabases.
Just wondering what systems would be affected considerably negatively, if the game was designed around, say, 5 UPS?
That means, the animations would stay at the same speed, but 30-seconds research would be completed in 150 updates instead of 1800, in the same amount of real-world time.
This is not a suggestion, I'm sure 60 UPS is well-justified, I'm just curious.
External link →Specifically if there is no update happening, the content on screen would not change. Therefore it makes no sense to render more frames than updates.
I disagree, the UI gets super hard to use when UPS is poor because these are tied together.
There are numerous UI elements and interactions which have precisely zero effect on game state, which don't need to be slowed when UPS is poor.
Specifically, anything where the user expects graphical changes but hasn't selected a game-changing action yet; eg finding the correct spot for a blueprint, selecting items to hand-craft, moving windows around, naming entities, typing messages in chat, scrolling/zooming the map, etc.
Solving these problems might require a higher level of replication abstraction for multiplayer to work - no-one can see you selecting and moving a blueprint, they only see when you place it. so why is selecting/moving tied to UPS when those actions haven't affected gamestate yet?
Of course, placement needs to confirm against gamestate as another player may have placed a competing blueprint in the same area, and so the placement action must be tied to UPS.
No-one can see you opening your inventory and moving your mouse to select items to hand-craft - but starting the hand-craft needs confirmation against gamestate. Why is moving the mouse to select the thing or choosing the appropriate tab slowed down?
No-one can see where you've moved windows to. Why does that need to wait for a game update?
No-one can see you typing a new name for something - only the actual name change commit action needs to become part of game state.
No-one can see you in the process of typing a message in chat - only the sending of the message needs to be commuted to game state.
No-one can see what part of the map you're looking at or trying to look at, why should moving the view around the current game state's map require a game state update for each frame?
And when I say 'no-one', that includes the "game state server" in whatever form that takes in both single and multi player instances.
/u/klonan, what do you think?
We had some discussion internally before, about the idea of decoupling GUI frame rate from the uodate logic.
And it is still a nice idea, but priorities are as they are, and UPS problems realistically only affect a small number of players
devtrackers.gg