Please clarify, is this about big browser games or browser games with many files?
And do you need to close the browser to run the download version of such games or is the web export just so bad from those engines?
I understand a size limit, but the file counter limit is quite Itch specific and a rather indirect explanation was given, that would have little to do with the browser filling up the ram. That can be done with a few files just as well.
I think the problems occur when you export games from game engines as browser games. But you can also develop games specifically for browsers (without game engines) and split the graphics into many small files so that the graphics are only loaded when needed and therefore quickly.
But I don't want to complain here, because I'm glad that I was able to upload my game to Itch. It's just a shame that I probably won't be able to update it before it reaches a size of 50mb.
My statement should only serve as information about what you should consider with Itch for larger browser games.
and split the graphics into many small files so that the graphics are only loaded when needed and therefore quickly.
... many small files is precisly what the restriction on Itch does not allow for arbitrary reasons. It is a 1000 file limit. The size limit of the zip is 500MB, individual files 200MB.
https://itch.io/docs/creators/html5#zip-file-requirements
The size limit is explained on the faq. The file limit is not. Very large HTML5 games tend to be a poorer experience
There is this box hinting that they want to discourage engine exports. But as you just showcased, many small files is actually the way it would be developed directly in html5.
Or is number of files really a hallmark test to distinguish lazy engine exports to html5 from hand crafted html5 development? My guts tell me, it is the engines that would handle packed ressources better. On the other hand, I did see extracted rpg maker downloadables with like 10k files. But this brings me back to thinking, file number does not say much about the quality or the optimisation for web.
--
Oh, and I believe, if your game is only 50MB, downloading the whole chunk in one go is better for performance, instead of retrieving every tiny bit on demand. The exact opposite as html5 games were intended once. The concept is outdated or rather not optimised for all gaming scenarios. For complex online multiplayer games or such, loading on demand is better. For any single player experience with a "small" size like 50MB, one download should be better.
I think it's more complicated than that. Downloading 50Mb at the start of the game is ok if you're on a PC with a reasonably fast internet connection. If you're on a cell phone (which usually has a slower connection), and you have to pay for the amount of data you download, it becomes problematic.
If you expand the game over time and it becomes significantly larger than 50mb, it will take too long to load on a PC too.
If you don't use spritesheets (as RPG maker does in some cases) and don't put thematically similar graphics in sheets, this increases the number of files significantly.
In my opinion, it is difficult to find a sensible solution for what is allowed and what is not. That's why I asked support how strict the 1000 files rule is. The answer was that exceptions to the rule are really exceptions.
As soon as the game reaches a certain size and you have a version 1.0, you should make it downloadable and installable.
Games on Itch are usually not "installable", they are unzip and run.
Commendable that you do use the html5 features for loading on demand. This is why I a voice my bafflement about the restriction. This is not the only thread about this topic.
I have yet to see a good explanation why the number of files indicates a lazy export from a game engine that results in a bad user experience.
Because as I understand it, you did not export this and had a lot of files because of that, but you developed for web directly. Making this explanation "many files = lazy engine export" be rather questionable.
Would not an engine developer quickly learn about such restrictions and have an option to reduce file number, but otherwise be as lazy an export as before?
I would understand it, if it was said that number of files puts strain on the servers or any other explanation. But I do not follow the chain of logic that is currently used. Or that is used as far as I understood the explanations.
In one of those threads the developer tried to pack the files only to find out that the packing method used could not be used over web, because the unpacking method is not allowed for security reasons and only works on a development build on local client. Did not sound like a lazy engine export either.
I do understand the discouragement of lazy engine exports that would work better as a download version. But I question the method of using a file counter as an indicator for this.
