Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

What I understand is that each loose file requires an HTTP request.

If you have 1 file with 64 sprites, it is a single request, if instead you divide it into 64 files, you need 64 requests.

That not only decreases the performance of the page, but actually each request has a cost, plus every time you load the game, you must make a request before the browser checks if the file is in the cache or not.

If the files are local, something similar also happens, because each file you read needs to open a thread with the OS.

I have a game with 65,000 files, in the development version we have the loose files in a directory. The loading time is twice as long VS when we package the 65,000 files into a single .PAK that is then read into memory.

Packing those files together is of course the better solution for most cases. Not the least, because you have a 1/2 minimum cluser size waste per file or more, if you have very small files. So a 100 byte file would require 4kb plus the fat entry.

But here is the thing, the web games I play are transferred in one go. There would not be 65000 requests to the server. There would be one for the archive. Unless you have the variety of web game, that indeed transfers each file individually, but if so, it would be very bad practise to request all files, instead of only the files you need.

So in theory you would have assets for level 2 and while playing level 1, those assets would not be needed and not be requested yet.

But I do not see this happening on web games hosted on Itch. There is one big loading bar. Of course, if this loading bar actually transfers all the files inside the zip individually, that would be the worst of both concepts.

Of course, if this is the issue, then the explanation would be performance and server load, and not user side quality experience.

(2 edits)
But here is the thing, the web games I play are transferred in one go.

I think there is something that we are not understanding in the same way.

That loading bar you talk about is NOT from Itch. Unless you're talking about the app, but I understand we're talking about playing on the web through a browser.

Note that NOT all games have a bar and you can do your own experiment, upload a game with an index.html and a couple of large files and you will see that there is no loading bar from Itch.

If Itch really passed the .ZIP to the browser, then it makes no sense to have a limit, because the server would always pass only 1 file, it doesn't matter if you have 100 or 100,000 files inside the zip.

Itch has no way of knowing if a game is optimized or not, if you upload 2000 files, Itch must understand that it will have to deal with 2000 requests and that's why it won't let you upload that.

Itch does not pass the .zip that you upload to the browser, but rather it must decompress and expose the files one by one to the server. If it didn't do that, you would have to upload the index.html outside the .zip



If my game has 2000 sprite files, and I upload that to Itch, Itch has to deal with 2000 loose files.

I take those 2000 files and package them (me as a programmer, NOT itch), and then I tell my engine to access those resources from a single file, for example a .PAK. Now, Itch only sees 1 file and will let it upload and run without any problem.

In both cases, the resources used at the game level are 2000. But in one, there are 2000 individual files, in the other, it is a single file. But you have to do that on your own, Itch does NOT do it.

I just see the results and how it is handled on other sites. This file limit I only know about on itch. Other sites do not have this. And I know that the explanation given was decidedly not about performance when starting a game, nor about server load.

And I also see on most web games, itch or not, a continous loading bar or have a singe up front waiting time, till the game starts. This indicates to me, that all that is necessary is transferred at the start in a continous manner. If this operation is such as to have a single request for each file inside a server side archive, than something should be optimised on browser and server side and the html5 game stuff as a whole.

Also, there should be a html5 specific way of packing assets, precisly to combat such performance issues. Is there? Regular game engines have such a thing. What is best practice for html5?

I suspect that "html5" games using the tech as intended are the exception - like loading levels on demand - and most are just exports of other game engines. But this makes me wonder, if the large number of files is indeed an issue, why do those engines not export the files in a packed way. Instead they bloat their export file to have thousands of files. Are they just bad at it, or is there no good support for this?

So, as I wrote above, what is the intened "native" way for html5 games to handle large amounts of assets?