next »

[DingusKhan]

I'm writing a system for caching my game resources, and I was curious what you guys would think. I'd personally prefer the longer initial loading time, since it'd let me go to the bathroom or grab some snacks to prepare, and I wouldn't have to wait as long afterwards.

EDIT:
These are just "ballpark" figures to give me an idea of what people would prefer in general.

[agersant]

Both options sound very slow compared to most games. What kind of game are you making and what platform is it for?

[DingusKhan]

Sorry for the lack of detail, I was in a rush to leave as I wrote the description part of the post. The question is supposed to be open and general, to give me a rough idea of what kind of loading system people would prefer. Main platforms are PC/Mac/Linux, but the code is being used for frameworking as opposed to a solid game idea right now, so these are just "ballpark" figures. The crux of the issue is really whether people would prefer a longer initial loading time to decrease later ones, or longer loading times for the sake of getting to the game faster. The thing that brought the issue to my mind was when I was playing Bloodborne, and noticed that it seemed to get into the game quickly, but loading times between areas (and after dying) were rather long.

I'll update the initial post.

[ThemsAllTook]

I prefer to have everything in memory and ready to go by the time it's needed. That might sound like option 1, but there's another way: Intelligent background loading. At the earliest possible time you know the next thing you need, a secondary thread could already be working on it while other things happen in the game. Couple that with whatever optimizations are necessary to reduce load time overall, and it's entirely reasonable for the player to never have to see a loading screen.

[ProgramGamer]

Why not have a pre-launch prompt to chose which option the user prefers? I'd like to have the choice because sometimes I want to play a quick game of something as opposed to a long multi-hour marathon. Both options are valid in certain situations.

[agersant]

The crux of the issue is really whether people would prefer a longer initial loading time to decrease later ones, or longer loading times for the sake of getting to the game faster. The thing that brought the issue to my mind was when I was playing Bloodborne, and noticed that it seemed to get into the game quickly, but loading times between areas (and after dying) were rather long.

I feel like you're approaching this issue from a strange angle. The main reason Bloodborne has such long loading screens is because all their levels and assets don't fit in memory at the same time. When you teleport somewhere else, the game needs to purge assets from the current level and load different ones from disk. It's not like they could put a 10 minutes loading screen at the start of the game and call it a day, it simply wouldn't fit.

I think the wiser approach is to determine how much content your game needs to load and from there figure out a solution. If numbers are small you might be able to load everything at the start and call it a day, if they're a bit larger you may need to swap the heaviest things in and out at runtime, and if they are very large (or unknown - which they shouldn't unless you're writing a very generic engine) then you can look at more complex solutions like streaming like ThemsAllTook is mentioning.

[Schoq]

Isn't loading all assets into memory at the start the reason most game maker games run like ass?

[Lares Yamoir]

I would prefer no visible loading time at all, so option 3: background loading

If for some reason this is not at all possible (for example because my pc's spec wasn't good enough, so it would be a problem on my end!), I would go with option 1: Longer initial load times and little loading when necessary.

[s0]

Isn't loading all assets into memory at the start the reason most game maker games run like ass?

nah

edit: it might be a problem for big games, but once you get to the point where you can make big projects with GM, you'll have figured out how to load and unload external resources at runtime (which is something GM can do). my last game has almost no internal assets.

i honestly think GM's biggest problem even beyond any performance concerns is that the way it's set up encourages bad dev practices. for starters, the drag&drop stuff is literally pointless to learn how to use unless you want to make pacman and space invaders clones all days erryday.

[Armageddon]

Man, this is making me reconsider how I'm doing levels in my game. I'm doing basically small segments of the world and you're meant to spend a lot of time in each one before moving on, load times are less than 5 seconds though, so far. Another implication of streaming is that level design can't overlap between levels. Which is good I guess, unless you want to do some Shining impossible layouts.

[ProgramGamer]

The drag and drop is useful when you want to quickly tie an event(input/collision/other) to an atomic action(quitting the game/setting motion/changing sprites). For complex stuff you do need to use the code features though, the D&D can only go so far in terms of complicatedness.

[Sik]

I come from the cartridge era so anything beyond 1 second is just way too long. (but yes, loading in the background before you actually switch to the relevant screen is a good way to hide loading times)

Source (or at least Valve's games) does the worst of both worlds by having a huge upfront loading time and then large loading times across the map. Dang it.

[MeshGearFox]

loading times
loading times
I KNOW WHO I WAAAAAAAAAAAANT TO TAKE ME HOOOOOOOOOOOME

[Nelvin]

With a decent caching system it should be neither of the two besides games that need a huge amount of very different assets all the time. But that's nothing lots of indies should have to think about.

I usually access all my resources through a caching abstraction. I.e. each time I render an image/tile/sprite, display a text or do anything else I request the actual resource from my caching system. What's not in the cache already get's loaded immediately. At a given threshold - depending on the game and target hardware, I purge the least used resources.

If you don't need huge amounts of resources immediately you usually can get away even without prewarming this cache but it's also simple to do a little preloading during intro/main menu etc. states in the background. And if you want to make it really good, you remember/check the last savegame of the user as chances are high, that's where he/she'll continue to play, and preload whatever's required for the level/section of the world.

[AceOfAces_Mod]

RAM is faster than HDD, so caching files there is helpful as long as  you have a good system. But sometimes, when the player has low RAM, it can break the game. A more dynamic caching system could be useful.

[Endurion]

You're missing option 3, close to no loading times.

Prepare data to block load as much as possible into RAM. Not millions of little objects that are all loaded byte per byte.

This may include an extra build step to convert your data to something more easily loadable.

[Sik]

Or just put everything into a single ZIP file and use that as your game's filesystem. Opening a file has a huge overhead (so reading tons of tiny files is much worse than reading a single huge file), but in this case you only open a single file (the ZIP) and keep it open for the duration of the game. Loading times will spike like crazy if you had lots of small files before.

Also depends on how large are your assets... Sol needs more RAM than hard disk space, I wonder why I don't just keep the entire archive in RAM and then decompress as needed x.x (then again loading times are still like 1 second at worst)

[FREAKNARF]

I think that both of these loading times are way too long, and it could dissuade me from playing it :/ I could barely tolerate it on "AAA" games, so i'm not sure that it would OK on smaller projects.
Maybe background loading, or a better asset loading optimisation are good solutions as it's been said?