The problem is, loading things takes different amounts of time. I once tried to implement a real loading bar for an app because it took long enough to load that clients needed some indication that the app hadn't crashed. There were seven steps, so I naively made each step take about 14% of the bar. Then I tested it, and it just jumped to step 4, sat there for the entire loading process, and then jumped to 100%. Because loading isn't linear.

The only way for loading bars to work is for them to be fake.

[–] Chailles 13 points 1 year ago* (last edited 1 year ago)

I've seen other games add a secondary loading bar for the individual task at each step. So, sure, its stuck at 5/7, but then the second loading bar shows it's still processing.

Perhaps the best indication is just telling the user what it's doing rather than an arbitrary progress bar.

Edit: Just gonna add, I've been playing Bannerlord and the game (while heavily modded) just silently freezes when starting a new game. Outside of task manager and watching the game just not do anything for a while, you wouldn't even realize it was frozen.

[–] Razgriz 1 points 1 year ago

Why not make a fake loading screen that adjusts load times based on how long it took to load the previous instance within the same environment?

If I'm using the same version of everything, and same hardware, then those load times would be very similar or near identical, and I no longer have to deal with randomly jumping status bars, no?

[–] [email protected] 20 points 1 year ago

Well, it's not a lie, you don't have to admit it. This is how things work. You cannot count the uncountable, divide undividable into the equal parts, estimate the inestimable, and display the remaining time for the unknown.

[–] trifictional 17 points 1 year ago* (last edited 1 year ago) (3 children)

To the surprise of absolutely nobody….

Loading bars anywhere are an approximation at best.

[–] NewNewAccount 4 points 1 year ago (2 children)

I recall during my CS studies that predicting loading bars with 100% accuracy is literally impossible. Something about the only way to predict it was to actually perform the action and then report back to the user.

Did some quick Googling to find a paper or article on this and nothing turned up, unfortunately.

[–] Thaurin 1 points 1 year ago

Is that It’s an asynchronous operation and you need to send messages in the form of events back to the UI thread. But it’s difficult to predict how much of the total percentage of progress you just finished in the small part it’s doing, since every part is doing something different or longer-taking. So it’ll jump and won’t be steady. Or, you make a fake one that goes steady and shows down at the end, or something similar. So, fake. :)

[–] Katana314 1 points 1 year ago

I kinda wonder if it'd be possible to actually record data on the operations used, and then incrementally use that to inform future loading bars. I guess it'd have trouble if future runs are going to execute on different hardware, but at least on consoles, it could use some sort of learning algorithm to say "30 seconds of 40 finished".

To be fair, I just now realized there's issues like disk fragmentation if someone is on a PS4/XB1...

[–] [email protected] 1 points 1 year ago (3 children)

what do you mean?, ive never heard of loading bars being faked and never had a reason to doubt them, they do what they say. Was i the only one not in on this info?

[–] trifictional 3 points 1 year ago* (last edited 1 year ago) (1 children)

I’m sorry to burst your bubble 😅.

Rather than try to explain it myself, here’s a post from someone else that does a decent job: https://www.maketecheasier.com/how-progress-bars-work/

[–] [email protected] 3 points 1 year ago

Ok, i get it now. Its not fake but rather not accurate. I thought this post meant the loading bars were just made to look like they were doing something, but i do get that sometimes the bar gets stuck on 50% for a while and rushes to 100%. it still is showing the loading % just not accurately

[–] shrodes 2 points 1 year ago (2 children)

Consider this scenario: I ask you how long it would take you to go to the shops and buy a carton of milk.

You could probably give me a good estimate based on your previous experience going to the shop and buying a carton of milk, but to actually tell me how long it would take would need you to go do the thing then come back and tell me.

Even with your estimation, something could always go wrong and cause your trip to take longer than expected. Maybe there was a traffic jam, maybe the shops are sold out of milk, maybe you get mugged along the way.

Loading bars are the same thing. There’s no way to definitively say how long something will take without doing the thing and seeing how long it DID take. The best you can do it an estimation based on known factors (eg. how long does this thing usually take). So in that sense loading bars are fake

[–] GoosLife 2 points 1 year ago

Even worse, the person who has to make the estimate doesn't know anything about the person who has to make the trip. He could live in the store and be done in a single loop, or he could be 90 km out with nothing but a rusty bike for transport.

[–] anewbeginning 12 points 1 year ago

That's true of nearly all loading bars.

[–] blueshades 9 points 1 year ago

I think I can add a little clarification here. It’s not that progress bars are impossible to implement, it’s specifically time-based progress bars that are impossible for the simple reason that you can’t predict how long the task is going to take in the user’s computer.

That being said it’s perfectly possible to implement task-based progress bars. If you have 100 resources to load before showing the next scene, the progress bar can advance 1% for every resource. Some games do that. But what the devs in the mentioned tweets are saying is that doesn’t always “feel” good. If you have 99 small resources and 1 huge resource, to the user it’s gonna feel like it’s “stuck” after flying through the initial 99%. So what they do is voluntarily make the first 99% go slower so the last 1% feels better (and other variations around that).

[–] garyyo 2 points 1 year ago

I have a bad solution to this:

measure the mean and std. of loading times for a given loading task on a wide variety of machines, store this
when a user encounters a load that needs a bar (above a certain time threshold), compare their machine to those stored to get a mean/std
go to your desired confidence level above the mean (say 99.9% of all cases) and use that as a loading time.
progress the loading bar smoothly for that time. If the loading is done before that DO NOT end early, just keep going and record the new time to work it into the mean/std (which should probably be reported back to the dev and fetched by the user's machine daily)
If it goes over on time, just dismiss the loading screen just very very slowly transition to the game, and if its still not done just crash the game. If we cant have an accurate loading time we won't have any loading time.

This should annoy enough devs and users alike and make them admit that fake loading bars are better than accurate ones.

[–] bighi 1 points 1 year ago (1 children)

EVERY loading bar is fake.

[–] [email protected] 5 points 1 year ago

The loading bar that I implemented in our app at work is real. It only advances when it has done something, and it advanced that % of the total when it has done it.

It gets away with that because unlikely other bars mentioned here, what's it's doing is a lot of little things that all take about the same time, and so it's actually a pretty decent approximation of how much is done.

So there's at least one that isn't fake. ;)