I would like to create a web browser game, if Armory3D can create desktop games with large file sizes, can Armory3D upload a similarly large web browser game too
There is no restricted “maximum” file size. However, like with most online interactions, it’s highly encouraged to keep file sizes and HTTP requests to an absolute minimum if possible. Here’s some of the file size related settings Armory supports for reducing export file sizes:
I find armory is really good at optimizing games for HTML, with lower file sizes and fast processing if the render path is configured properly. Especially compared to other engines like Unity.
Hmm. I wonder why that is. Actually, that could be a good video idea! Something that isn’t a tutorial, but an overview of aspects of how Armory 3D does things compared to other game engines (like handling optimizations on export).
I don’t think larger game engine companies bother with HTML5 exporters much, as they don’t see the platform as viable for game development due to bandwidth and HTTP request restrictions.
Unreal Engine for example, officially deprecated their HTML5 exporter in version 4.23, although there is a plugin that allows HTML5 exporting in latest Unreal versions.
Godot’s HTML5 exporter isn’t the best either, like Unity’s.
To be fair though, all of these mentioned game engines are extremely powerful and just because they don’t handle HTML5 well (or even support it), doesn’t mean they’re bad game engines. It has to due with more in terms of monetization and raw man power.
Now, I definitely want to see a more detailed comparison to other engines and a breakdown of how, why, and how much Armory does it better.
Why would HTTP request limiting be a concern, unless you’re making a multiplayer game of some kind? For context, I don’t really know anything about HTTP request limiting.
Not all browsers support a large amount of HTTP requests. See here for a comparison table list.
Each external asset is an HTTP request. A typical game would usually require a lot of assets, not all of them packaged into a singular file, so it would make sense to reduce as many HTTP requests as possible, else you may find yourself not being able to import assets fast enough or even at all.
Every time an HTTP fails, the browser will usually attempt to resend the HTTP request until a certain timeout has expired. Every time an HTTP request fails, this adds more loading time usually for a game, unless the external asset isn’t necessary important/needed.
There are also sync and async loading. But that’s a different topic.