Late Game Performance

[rancid rapids]

My Factory is now over 1m Buildings. I have 100% Research done and now just spamming milestone factories to increase my Operator Score.

On this run I have about 275 hrs of game play on it and an Operator Score of 320 or so.

Context. I have done this exact situation on every level besides Hex. Still working on that.

It was at about 650k-700k building that the input lag was getting to be frustrating. I would click to drag a space belt and I would not get the first space I selected. I had to decrease my clicking speed and scrolling speed to allow for selections to be made.

Will this always be an issue? Or will the amount of building limit truly reach an unlimited amount?

My goal: Attempt to use every color or asteroid in some fashion to make a true infinite amount of shapes. But without hurting my eyes to do so.

[turbid nest]

Because of the performance
I don't expand the factory in the end game.
Instead I trying to create a TMAM, which is more challenging and fun than copy and paste the existing factory.

[iron fractal]

Unfortunate reality is there will always be a performance cap eventually but changes are in the works to push that cap much further down the road so you have many more buildings before then

[deft herald]

The devs recently posted that the real limit is 500k buildings before performace drops. This is known, and they are working on it.

[south sable]

See #✨updates

[rancid rapids]

Had started that process. Got as far as colors before I realized I had bitten off way too much by trying to make a 12 belt machine from jump. Think I will revisit this again at some point. Wire logic was never really something I enjoyed in any game.

[cloud nova]

Sure there will be a cap. However performance can degrade in a nice way - for instance simulation gets slower but UI still responsive.

[deft herald]

that is not how Unity works

Unity calls specific functions in a particular order every single frame. A lot of the UI is scheduled for polling and evaluation at a particular phase of evaluating every single frame.

And a lot of this is baked into the Unity engine. I can’t tell Unity to just skip the “LateUpdate” phase for this frame, and go straight to the decommissioning phase. It doesn’t work like that.

[cloud nova]

There is a game architecture decision here to tie the factory simulation into Unity's update loop

The correct and hard path is to run an independant factory simulation and use update only to copy underlying factory progress into visuals

This provides much higher performance for stuff offscreen (running without reference to Unity), enables multiplayer (easier to make raw simulation lockstep) and lets you update or save the factory without tying up the UI

[deft herald]

the factory simulation is most likely its own function, and the most natural/obvious choice is to make sure that it evaluates at a consistent timing wrt unity’s callbacks.

otherwise other functions (especially those related to rendering and music) would be reading the important variables at inconsistent times.

it would be crazy to just have the simulation running in parallel, and just let everything else just query the sim whenever it feels like it.

[cloud nova]

What you do is to create a set of world states

• previous tick (in the past)
• next tick (in the future)

The factory runs at say 10 FPS. Updates query previous and next and interpolate for animation and shape positions between these two states

Once you have the previous sim, you kick off a background task which calculates the next, next state.

In a later update, if the background calc is done and it's time you copy next next into next. You then move next into previous.

If you want to save, you just start saving the next snapshot in the background. No need to lock the UI, since the next snapshot is not going to change.

[cloud nova]

That only matters if you modify the states after the sim is done with them while other things are reading. With snapshots the snapshots do not change.

[cloud nova]

You actually should not do this because update runs at the user's framerate where you want the sim to run at some fixed framerate which is the same for all players

[deft herald]

all ONE player

[cloud nova]

You don't want your tested game to break when some gamer with a 175 Hz screen plays

[deft herald]

you can tell unity to cap the frame rate

and this is likely done in the FixedUpdate loop

i don’t understand what you are getting at, because you are proposing a potential major architectural overhaul, just so the UI doesn’t lag when the sim lags.

[cloud nova]

Yeah, it is something you want to do early in design.

[deft herald]

if you are usuing unity, it is vastly simpler to work within its limitations than to try to circumvent the core features of the engine that you are paying many thousands of dollars to use

[pure quiver]

Tobs recently mentioned they have a working fix that gives something like 45 FPS with a million or two buildings. No test build for players yet though.