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.
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.
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?
To the surprise of absolutely nobody….
Loading bars anywhere are an approximation at best.
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?
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/
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
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.
That’s true of nearly all loading bars.
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).
