i would need at least 1500 file space .... 1000 is just not enough: ( i was told i can request more file space? im trying to host an RPG Maker MV game for webplay and 1000 is max but i need to use 1250 files : ( else the game wont work. i posted a ticket over a year ago asking for help and have not heard back from anyone D:
While the answer to this is "quality", this is not about the size of the files, but the number of files. There is an arbitrary limit to web games of 1000 files in the zip. The limit once was 500.
As far as I understood and remember it, the reasoning was stated as, if you do an export and your crap non-web-optimised engine will resort to export thousands of files, the user experience will be better, if you do not use a web export of an engine that does not optimise this and just lazily dumps all, but instead provide a downloadable file.
I honestly do not grasp the reasoning, since if the files are in the zip, only the size of the zip should matter. But I also saw that a thing like rpg maker just uses very large amounts of files - for download versions no less. But I also know a html game which has a download size of maybe 20mb and includes over 10k files, but I do not know how to play it as a zip. And yes, having multiple versions of the game on my hard disk did slow down my computer for certain file operations. (The game is not on Itch. But I think it is hosted somewhere as a web game. This 1000 file limit is an arbitrary Itch thing and has little to do with tech capability or how game engines work or are supposed to work ).
Presumably the logic was that 1) computers have grown more powerful on average in recent years and 2) with certain popular engines, it was too easy to fall way short of the old limit. Hence the increase. But having to load lots and lots of assets in a single web page is still a serious performance issue, which impacts the player's experience. Hence, quality.
As I said, I do not understand the limit. This is Itch specific. If other sites do it, I did not notice back when I tried to learn about this.
And if it is in an archive or if it is in another sort of archive, the assets are still taking up space and it still takes computation to extract them. So what is the difference in "quality", if you have your moving animation of a sprite as 8 files or as 8 tiles of a bigger image file or as a separate engine specific archive file that is equivalent to a zip with 8 files.
I can imagine, that it might hamper performance if there are many assets, but on the other hand I also know that these types of performance issues are a thing of the past. Or they should be. Doing things in a file system is overhead. Yes. But if the game file is transferred to the client and is not "physically" extracted, it should not matter at all, how the insides of that archive are managed.
What I also would understand, if the assets are kept on the server, and there would be network traffic necessary, including lots of headers, for each tiny asset transferred. But the way most web games load, I suspect that this is not true for most games, as they have one long loading bar indicating that all is transferred in one go.
And, well, what difference in quality/performance is there, if I have the big number of files on the client as a downloadable zip or as a web game zip in the browser's cache. Limiting file size for web games makes a lot of sense. Limiting the number of files inside that web game, I cannot understand.
What am I missing here? To me it looked like an attempt to discourage web exports from engines that are bad at this and have as a common trait that they use a large amount of files by doing some lazy export thing. Similar to a "pdf export" that is just a series of images, instead of a document.
Is there a guide for html games, how assets should be handled? Some best practice? Something that tends to output low number of files? Because if this boils down to use something like renpy does with their rpa files, we are at square one, imho, since putting the assets in a zip is already minimizing files - to one, the zip file.
There is a sticky about reduzing build size. But this talks only about size and not number of files. If number of files really is an issue, a sister sticky about reduzing files in a web build might be a good idea.
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.
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?
