Is inconsistent load times bad UX experience? (artificial load time)

[kupo15]

Would you consider having the same action that results in different load times bad design for UX even if the goal is to cut down on load times when possible so the player doesn't have to wait the full length all the time?

Example: You have two players that are selecting from a roster of characters to play.
-If they both select different characters the load time will be the max load time (say 5 secs)
-If they choose the same character the load time will be shorter (say 3 secs)

However if during the game both players go back to the character select screen and swap characters there is no need to tex_flush then prefetch the same characters again. In this scenario there will be no load times (0 secs)
One could design the loading system to take advantage of this shortcut and have 0 load times as an option instead of simply tex_flushing every time you go back to the CSS but the load times will be wildly inconsistent.

Naturally I think this is good design because its reducing load times a lot through a play session but I wonder if the variety of load times could be a jarring experience if the player doesn't realize the system is smart? If you are used to several 3 or 5 sec load times then all of a sudden you get no load times, would that be a pleasant or unpleasant surprise? Conversely you are used to a lot of 0 and 3 second load times, then you get a long 5 second one.

Do you think it would it be better to add in artificial load times to make the loading experience consistent and predictable?

 

[Jack Matthew]

I don't think there'd be any problem with inconsistent load times, if anything the user would be happily surprised to skip a loading screen. Making sure the player doesn't waste unnecessary time would be a bigger priority than consistency here.

 

[elsi11]

Do you think it would it be better to add in artificial load times to make the loading experience consistent and predictable?

Yes.
If loading stuff is inconsistent, people will think it's a bug, and it will be a negative thing. If you mask it with some kind of cool transition animation, it will be always the same, and no problem.
People don't like unpredictability in solid systems such as menus.
Here's a wild idea. What if, when the player changes characters during gameplay, you play an animation of the old character saying bye and leaving the screen, while the new one tags in.
Or you can just have a fancy screen saying new challenger or something. Depends on your theme.

 

[sylvain_l]

whatever you do there are some players who will find a way to complain

Do you think it would it be better to add in artificial load times to make the loading experience consistent and predictable?

personnaly: loading screens sucks! so rule is simple, the less loading screen the better (who the hell want to play game to watch loading screens ?)

some players are going to complain if they have a 0s CSS is why the hell does it not work for the other charachters the same ! it's tolerable if your rig has the bare minimum specs, that you can load only the required thing for playing. But if you have a beefy rig, and the game just used 50% (or even much less) of your RAM/VRAM, etc... feels like they could use that to prefetch in background more data to remove any further loading time.
of course, if you do a lazy loading in background while already starting the play some players would certainly complain; something is wrong, because game start and then you can see that memory while playing double/triple or even more! there must be a memory leak the dev are incompetent !!!

 

[Yal]

However if during the game both players go back to the character select screen and swap characters there is no need to tex_flush then prefetch the same characters again. In this scenario there will be no load times (0 secs)

It still needs to load the stage graphics, though, right? Simply have stages auto-randomized (or have "random" be the default option in the stage select menu) and you'll introduce some real loading, the players will never notice!

 

[kupo15]

I don't think there'd be any problem with inconsistent load times, if anything the user would be happily surprised to skip a loading screen. Making sure the player doesn't waste unnecessary time would be a bigger priority than consistency here.

That was my initial thoughts too.

Yes.
If loading stuff is inconsistent, people will think it's a bug, and it will be a negative thing. If you mask it with some kind of cool transition animation, it will be always the same, and no problem.
People don't like unpredictability in solid systems such as menus.
Here's a wild idea. What if, when the player changes characters during gameplay, you play an animation of the old character saying bye and leaving the screen, while the new one tags in.
Or you can just have a fancy screen saying new challenger or something. Depends on your theme.

Playing an animation during loading as far as I know isn't possible in GM unfortunately otherwise this really wouldn't be an issue...if it even is one that is haha

It still needs to load the stage graphics, though, right? Simply have stages auto-randomized (or have "random" be the default option in the stage select menu) and you'll introduce some real loading, the players will never notice!

Unless of course I extend the system to stages too! Like if they swap characters and go back to the same stage, 0 load time haha

I'll probably move forward to eliminate the load time and at least have the option to set a timer to extend the load time if it becomes jarring. My instinct says that reducing load times where ever possible is always a good thing. Thought it was an interesting thought experiment in design for things that are really repetitive and the difference in load times would most likely be noticeable. I'm still interested to hear other opinions on the matter if anyone has a differing opinion

 

[RangerX]

I vote consistant load times. This said, if its for the "same element" in the player's point of view (like loading a choose character).
The point with consistant loading is that the player can't really ask himself questions. He just needs to accept it takes the time it takes. Eliminating questions in the mind of the player is probably good.
+ people are confortable in habits, in homogenous things. Consistency in most sphere of designs is good imo.

 

[kupo15]

I vote consistant load times. This said, if its for the "same element" in the player's point of view (like loading a choose character).
The point with consistant loading is that the player can't really ask himself questions. He just needs to accept it takes the time it takes. Eliminating questions in the mind of the player is probably good.
+ people are confortable in habits, in homogenous things. Consistency in most sphere of designs is good imo.

That was my original thinking too...less questions that pop into mind the better. I implemented it already and the faster load time is really refreshing to me maybe because I know it exists. Maybe I could use a timer to bring it up to the average load time instead of the absolute max. I think forcing a < 1 sec load time up to 7 seconds is a bit extreme. Bringing it up to 3 secs would seem better, though if I can spread the load time out in some way I could probably not add any extra time for consistency.

 

[GMWolf]

I think you are thinking way too much ahead.
Step 1: Make your game as best you can. By best, I mean technical best.
Step 2: add logical design decisions.
Step 3: release.
Step 4: get feedback.
Step 5: notice most people wont notice the fraction of a second longer time it takes to load.

 

[kupo15]

I think you are thinking way too much ahead.
Step 1: Make your game as best you can. By best, I mean technical best.
Step 2: add logical design decisions.
Step 3: release.
Step 4: get feedback.
Step 5: notice most people wont notice the fraction of a second longer time it takes to load.

haha as I always do! (over thinking) but I think its an interesting thought experiment nontheless. Though I wouldn't say its a fraction of a second difference, its actually about 4-5 second difference which for me feels like an eternity and is noticeable! You are right though, sometimes its good to get feedback and adjust instead of trying to be the smartest person in the room and solve problems that aren't problems. I actually very much enjoy the speedier loading times when they come. Pretty satisfying!

I'll probably make a short video to share the difference just for the fun of it

 

[GMWolf]

haha as I always do! (over thinking) but I think its an interesting thought experiment nontheless. Though I wouldn't say its a fraction of a second difference, its actually about 4-5 second difference which for me feels like an eternity and is noticeable! You are right though, sometimes its good to get feedback and adjust instead of trying to be the smartest person in the room and solve problems that aren't problems. I actually very much enjoy the speedier loading times when they come. Pretty satisfying!

I'll probably make a short video to share the difference just for the fun of it

4-5 seconds per character? wow! that is a lot of data!
Ballpark numbers - how big are your character sprites (in MBs)?

 

[TsukaYuriko]

I'd say leave it up to the player. Bonus points if it's not just about this particular scenario, but more about loading in general:
When does loading happen - as soon as you select a character/stage/etc. or when confirming to start the round? (With loading times of 4~5 seconds per character, this would need to be on a separate thread. May or may not be technically feasible - this is all theoretical.)
Should there be a consistent loading screen length at all times, even if not needed, like illustrated above, or should they be kept as short as possible?
Should anything not used in the current scene be unloaded from memory to keep memory usage down? (For some people, this is still a concern, and it also is especially a concern for 32-bit applications as they are limited.)

I'd make the default be the one that's the least noticeable to players - which, for me, would be a transition that integrates into the game's scenery and masks that there could be a loading screen at all. I avoid explicit loading screens like the pest and generally try to either load during natural transitions or before what I'm loading is even needed (for example, loading stuff for every room I could go to from the room I'm currently in). Great caution has to be taken to ensure that this will not impact the player's gameplay experience, though - for example, preloading causing lag, or messing up timings they thought are somewhat constant (speedrunners will hate you for this - do not anger speedrunners, they are among the biggest exposure sources you can get).


To summarize, there are different kinds of players which experience your game differently, more positively in some ways, more negatively in others. This topic is a perfect example of that. Give them the option to turn some of those potential negatives into positives and the user experience will be more satisfying overall, at the cost of more development effort.

 

[Siolfor the Jackal]

I appreciate as little loading as possible. I think artificial load times would be a mistake. I know I have played a fighting game or two that do what you have suggested, and you do notice it but not so much in a jarring way as a "oh cool, no loading screen!" way.

 

[kupo15]

4-5 seconds per character? wow! that is a lot of data!
Ballpark numbers - how big are your character sprites (in MBs)?

Yeah it is though that 4-5 seconds is the total loading time I've experienced. Some of that time is the stage loading, character sfx and background music loading, and also tex flushing and sprite_delete all the menu assets. I'm externally loading sprite_add/delete all the pre-game menus figuring its a smart way to cut down on memory. I'm thinking about doing the same with stages so that the IDE

The last time I isolated tested a single character it was 3 seconds I think. I have a bit more animations in there now so I should test it again. This is because we are trying to have the characters be displayed at true 1080 scale. Better to shoot for the moon and scale back if we hit a wall.

I'm not sure how big in MB but the last I previewed the tex pages my current character took up around 7 full 4096x pages. There still is a lot of tex optimizations I need to do. Its nice that all the transparency is cropped around each frame but I still need to break each frame up into parts to further remove transparency. Also maybe there are better external programs that pack textures better. I'll give you more precise numbers and post that video when I get home tonight!

When does loading happen - as soon as you select a character/stage/etc. or when confirming to start the round? (With loading times of 4~5 seconds per character, this would need to be on a separate thread. May or may not be technically feasible - this is all theoretical.)

I'd make the default be the one that's the least noticeable to players - which, for me, would be a transition that integrates into the game's scenery and masks that there could be a loading screen at all. I avoid explicit loading screens like the pest and generally try to either load during natural transitions or before what I'm loading is even needed (for example, loading stuff for every room I could go to from the room I'm currently in). Great caution has to be taken to ensure that this will not impact the player's gameplay experience, though - for example, preloading causing lag, or messing up timings they thought are somewhat constant (speedrunners will hate you for this - do not anger speedrunners, they are among the biggest exposure sources you can get).

Interesting idea to offer the option of "Smart Loading" or not. All loading and unloading happens when you confirm your characters and stage. I would love to have a separate thread help with loading the other character or load while I have a graphical transition but from what I've been told you can't use multithreading with the graphics pipeline. I hope I misunderstood.

I have a transition from menu to stage however, currently my transition is designed to be seamless. So masking it with say a fade out would destroy the seamless design I was going for. Instead having it load on the menu screen (similarly to how Melee did it) keeps the seamless effect even with the loading pause. Loading the characters in another thread during this transition would be ideal of course. I do have an option to skip the opening transition so that would be the perfect candidate to hide the loading within a fade out to black.

I appreciate as little loading as possible. I think artificial load times would be a mistake. I know I have played a fighting game or two that do what you have suggested, and you do notice it but not so much in a jarring way as a "oh cool, no loading screen!" way.

Me too! I'm getting the same experience with my new system for my game, doesn't feel as jarring as I thought it would be. I did experience long load times in another fighting game I'm beta testing (Icons Combat Arena) and it was frustrating. I think for fighting games this inconsistency is more welcomed because the faster you can get to the match the better!

 

[GMWolf]

I'm not sure how big in MB but the last I previewed the tex pages my current character took up around 7 full 4096x pages.

0.o wow.

Now i understand why guilty gear went though the trouble of going with 3d graphics ^^

This is when it would be nice to have more control over how textures work. Having them saved as DDS with DXT compression would be nice. (IDK how GM handles their textures).
In my current engine i have tested ~10 1024x1024 textures in DDS format. they load super fast.
they are about ~2-3x smaller than TGA files on average too.

 

[kupo15]

0.o wow.

Now i understand why guilty gear went though the trouble of going with 3d graphics ^^

This is when it would be nice to have more control over how textures work. Having them saved as DDS with DXT compression would be nice. (IDK how GM handles their textures).
IN my current engine i have ~10 1024x1024 textures in DDS format. they load super fast.

Yeah, and to think I need two different characters loaded at once...plus a full background with Npcs and more graphical effects. Its clear that its going to be very important to decide what we can get away with not being full 1080. I don't think its feasible to have the entire game be full 1080 textures.

How much memory do those page take up? Is it simply a matter of seeing how big each tex page file is and adding them together? (doubtful) Also is there a way to alter how the tex pages are created? Like if my assets are at 1080 size in the IDE, have gm create the texture pages from them to be half the size without manually replacing every sprite?

I'm not familiar with DDS, hopefully this and more texture options are coming.. @Mike?

I'm sure that is one reason for GG, but the main one is probably for safety reasons related to fluid hand drawn animations as an art style being super time consuming, expensive and risky.

 

[kupo15]

4-5 seconds per character? wow! that is a lot of data!
Ballpark numbers - how big are your character sprites (in MBs)?

Alright here are the numbers. I tested using current_time

Flushing the menu: 18ms
Loading HUD: 95ms
Loading Stage: 227ms
Loading 1 HD character: 2507ms

Total 2847ms

So I guess the character only took 2.5 seconds instead which is better

Here is the loading feature in the discussion. Looking at it from afar it doesn't seem as bad as it feels. The first loading is the initial load of everything, the second time is everything except for the character loading because I kept it in memory
https://streamable.com/ttv4n

And the so far without the extra optimization efforts I plan on doing the current HD character takes up 9 4096x pages

 

[GMWolf]

The page number is ok, as each character will only really do 1 page swap every frame. (In dx9 you can get away with even 50 page swaps, dx11 it isn't really an issue)
However you may want to check they all fit in video memory, if you use more than 1.5gigs of vram at the moment you are cutting it close.

Loading times seem perfectly acceptable. You may even be able to shave off a bit by loading asynchronously. This would also alow you to show a small loading animation too.

If you do run into memory issues, the only trick I can think of right now to preserve your 1080p scale is to reuse animation frames (not necessarily consecutively) but I assume you are already doing that.

 

[kupo15]

The page number is ok, as each character will only really do 1 page swap every frame. (In dx9 you can get away with even 50 page swaps, dx11 it isn't really an issue)

yep that's what I thought, no worries on the number for me. Just thought that would help with answering your MB question

However you may want to check they all fit in video memory, if you use more than 1.5gigs of vram at the moment you are cutting it close.

That's my main fear at the moment, how do I figure out how much video memory I'm using? I checked task manager and the numbers are moving strangely to me. Is it normal for them to spike up then come all the way down even though nothing (I believe) is getting flushed after loading?

Here is loading the game itself. Only things that are loaded are sprite_add some 1080p menus and some shared menu button things. Goes up then comes down

Spoiler

And here is when I load that single HD character with the current HD stage resources as well

Spoiler

Loading times seem perfectly acceptable. You may even be able to shave off a bit by loading asynchronously. This would also alow you to show a small loading animation too.

Really? I thought this was only for html files. How do I do this? Is it via Image Loading Event or the Load/Save event? Do I need to use buffers for this and or can I use resources that are in the IDE or one ones that use sprite_add?

If you do run into memory issues, the only trick I can think of right now to preserve your 1080p scale is to reuse animation frames (not necessarily consecutively) but I assume you are already doing that.

I'm not actually I know how wasteful that is and it definitely is something that crossed my mind. For example to funnel likewise animation endings into a common ending which I may end up doing. If we can add more of a magical touch without reusing we will be trying that but I know if we can't reusing won't be a problem

 

[GMWolf]

Check VRAM usage witha tool like msi afterburner or open hardware monitor.

Really? I thought this was only for html files. How do I do this? Is it via Image Loading Event or the Load/Save event? Do I need to use buffers for this and or can I use resources that are in the IDE or one ones that use sprite_add?

You can use sprite_add, but give it the path as a url.

I'm not actually I know how wasteful that is and it definitely is something that crossed my mind. For example to funnel likewise animation endings into a common ending which I may end up doing. If we can add more of a magical touch without reusing we will be trying that but I know if we can't reusing won't be a problem

Fair enough.

Check your texture pages too: If they have lots of empty space, maybe split your sprites into sections. It should allow the texture packer to pack them more efficiently. It can also help to reuse animation. For example, walking with a 2 upper body stances may have the same leg animations.


But back to your original question, as long as you do not reach the 5 second load time, you dont need loading animations. And as long as you dont cross the 10 second threshold, no one will think the game is stuck.
So you just make the loading times as short as possible

 

[kupo15]

Check VRAM usage witha tool like msi afterburner or open hardware monitor.

Thanks I'll check it out and report back!

You can use sprite_add, but give it the path as a url.

How do I do that? I tried this but it didn't work, the debugger says

HttpError:HttpSendRequest: The server name or address could not be resolved

// Space Pressed
test[0] = sprite_add("http://texture_17.png",0,false,false,0,0);
test[1] = sprite_add("http://texture_18.png",0,false,false,0,0);
test[2] = sprite_add("http://texture_19.png",0,false,false,0,0);

// Async - Image Load Event
sprite_index = test[0];

Check your texture pages too: If they have lots of empty space, maybe split your sprites into sections. It should allow the texture packer to pack them more efficiently. It can also help to reuse animation. For example, walking with a 2 upper body stances may have the same leg animations.

Yeah lots of space indeed.

Spoiler

Take this frame for example. So much wasted space. This would be a better way to cut it up

But back to your original question, as long as you do not reach the 5 second load time, you dont need loading animations. And as long as you dont cross the 10 second threshold, no one will think the game is stuck.
So you just make the loading times as short as possible

I'll have to check out the numbers using that MSI tool but it sounds like if the loading time doesn't get to 10 secs then I shouldn't be at risk for getting near the vram limit maybe? I would assume that longer load times equates to more vram usage but I could be wrong

 

[GMWolf]

I'll have to check out the numbers using that MSI tool but it sounds like if the loading time doesn't get to 10 secs then I shouldn't be at risk for getting near the vram limit maybe? I would assume that longer load times equates to more vram usage but I could be wrong

nah, loading time are mostly bound by disk speeds, and sometimes decompression, or data modification.
For example, loading an OBJ into an indexed vertex buffer requires quite a bit of data manipulation, in my implementation, its easily the slowest part of loading

Cutting it up like you showed would really help, but it will make drawing harder! I strongly suggest you write some smart data driven code to make it easy to piece it back together.

your http URL is not doe the right way , it has to be a full path. TBH I cant remember the exact format needed, but I have seen it done successfully.
Another option is to not load everything at once, load it in the step event (This is the way I usually go)

 

[AriesGames]

Just a newbie comment passing by...

If you'd crop those images at the beginning you probably wouldn't need so complex drawing systems to build in the first place.
Just the fact that you use 4000x images and the game didn't broke its amazing, from a newbie perspective.
Your foundation is clearly solid, but for instance when I did the same mistake, I had to rebuild the whole game.
My point, better do it sooner then later.

Also do what GMWolf said, if it doesn't slow the game, load the data in-game, behind the scenes, of course if the data allows it and doesn't need to be used instantly.

Also think of this from a design stand point, invent a period of time before each fight designed for loading, like a sparring time, in which the data used is minimal.
Even better, do cutscenes after each loading time, as a way to steal more time and load more data.
Anyway none of this is possible if you don't crop those texture pages...

Off topic: How did he managed to not get pass the cap with that size? Engineering, sorcery, MAGIC !
Why did you focused so much on creating a system that can hold that size when you could just crop...*facepalm*

 

[kupo15]

Cutting it up like you showed would really help, but it will make drawing harder! I strongly suggest you write some smart data driven code to make it easy to piece it back together.

Not at all! Drawing is super simple all because GM auto crops each frame when its put in the tex page. Abuse this with the duplicate sprite function to keep the origin in the same place. The onion feature makes it easy to block out what you need on a blank image then you can overlay it and remove the blacked out part
Here is an example of me using random cutouts that aren't necessarily the most efficient. The purple is the negative image of the first mask essentially. All that is left is to simply draw each sprite and GM will line them up automatically

Spoiler

All that empty space gets auto cropped and the origin stays intact.

your http URL is not doe the right way , it has to be a full path. TBH I cant remember the exact format needed, but I have seen it done successfully.
Another option is to not load everything at once, load it in the step event (This is the way I usually go)

Nooo that's what I was hoping to find out! Maybe @MishMash might know the correct url of a file that isn't actually a url since he mentioned the async method to me in his multi thread post. I tried "http://working_directory/texture_17.png" to no luck as well. Would love to know how to do this if its even possible. I think it would solve all my issues with loading in the background!
Perhaps I'm using the wrong Event? Should I be using Async Load/Save instead of Async Image Loaded?

I did think about loading things into vram on the fly in the step event but its not possible. Even loading in a single 4096x texture causes enough stutter to make the game unplayable. Even loading a single 1048x tex causes too much stutter so everything has to be loaded in at once

If you'd crop those images at the beginning you probably wouldn't need so complex drawing systems to build in the first place.

I did otherwise you would see much more space around in that big tex page I showed before, its just an IDE display actually. When you have all the images in a single sprite it uses the maximum size needed for all images but when GM creates the tex pages it crops the transparency around every single image. Cropping inside the IDE essentially is not necessary at all

Also do what GMWolf said, if it doesn't slow the game, load the data in-game, behind the scenes, of course if the data allows it and doesn't need to be used instantly.

Wish I could but prefetching anything always causes an unacceptable amount of stutter and to my knowledge you can't load JUST the image you are drawing. GM has to load the entire tex page that image is on. The only method I just thought of an tested would be if you create a tex group for each sprite so that each tex page is really small...which would be insane!! I would have over 800 tex groups if I did that! I still think there would be a slight stutter from flushing the previous sprite and prefetching the next sprite. Doesn't seem like a good method to me.

Also think of this from a design stand point, invent a period of time before each fight designed for loading, like a sparring time, in which the data used is minimal.
Even better, do cutscenes after each loading time, as a way to steal more time and load more data.
Anyway none of this is possible if you don't crop those texture pages...

With the standard prefetch method you can't do this because the game freezes. So cutscenes or sparring times isn't possible either. Sounds like that async loading thing is the trick to be able to do what you just said in which case I'm in business! Just need to figure out the proper "path" to use an http function with a resource that is in the included files

Off topic: How did he managed to not get pass the cap with that size? Engineering, sorcery, MAGIC !

I'm honestly not sure! From my rough testing with the MSI tool it "looks" like I'm at 2.3gb of vram but I really don't know how to use the program yet. Also my test wasn't that clean either. In any case somehow I've yet to hit a memory wall

 

[AriesGames]

You're prefetching those texture pages...

Actually you're perfectly right that its not possible the way I said it. You need some sort of async system, indeed.
Just the size and the ways of this project got my attention, can't wait to see the game when it reaches beta stage or even alpha.

Building a fighting game is one of the hardest things in this industry, above that you choose huge size. I wish you good luck.

This is soo beyond my current knowledge, so I am out. >.<