If I understand right, Defold game on HTML5 is not a “real” js program, but asm.js contraption interpreting lua. I can see how that bloats build size and slows down it’s execution.
Ideally (for me) Defold would use something like Haxe that converts to different languages, but that would probably make developing and supporting it way harder.
About build size : 5.3 Mb - it is full version, gzipped version is something about 1.3 Mb.
About “real js”, I don’t know exactly but I think you right, maybe @sven or somebody else can explain this.
Speaking of gzip. Maybe Defold game can have most of itelsf gzipped and inflate itself to reduce install size?
Looks like new feature request - and I think it’s a great idea! =)
Maybe you can create new feature request and let’s see what’s developers team thinking about it?
If you use https://www.s-cdn.com/ the engine runtime files are gziped among other advantages.
68 % savings on the loader (just tested 1.2.88).
77 % savings on the engine runtime - original size: 5238402, compressed size: 1195195 (just tested 1.2.88).
Loading will be faster based on geolocation.
If someone already has the files cached it means instant loading for the engine runtime files, and only time spent loading the game.darc.
Kind of related, but not about HTML5 builds. Is there a reason why the Linux build is so massive compared to OSX (Darwin) and Windows?
With a generic test build:
That puts the Linux build at 6 times larger than the OSX one, and 6.5 times larger than the Windows one.
Historically the Linux runtime has always been bigger. You can see the sizes here http://d.defold.com/stable/ (would be cool to batch check and chart the sizes of all targets based on these files). I assume it’s built in dependencies to make it more portable between the different versions of Linux? The good news is Linux runtime compresses to just 6MB. Desktop file sizes are not as much as a concern honestly. In fact, larger file sizes generally give users more confidence in value.
Regarding the executables, we want to keep them small and uncompressed to maximise app start time (as well as minimise complexity). The linux version is currently an exception to this, mostly because the opt settings we started to use for gcc made massive unrolling of loops, thereby increasing the size a lot. It’s roughly 10 MB larger than it should be. The HTML5 version can be gzipped by web servers, like in @Pkeod’s case.
Regarding content, we use great compressions like webp for textures. Different platforms have also strategies for compression as a part of bundling, like apks for android.
It’s not as easy as blindly gzipping everything, as it affects other things like start time. It’s often better to look at what is taking up the space and fixing that specifically.
If you have a problem with install sizes, please post it here in the forum and describe the specific case.
I think linux/mac/win build size doesn’t matter, because on desktop user all time have a good internet connection and disk free space much more than on mobile.
I had a semi-finished script that did just this. You reminded me to finish it! Enjoy:
Updated to 1.2.93:
A very very slow upwards trend, but not much to worry about considering the new features that have been added in recent releases.
P.S.: And this post not about build size in new versions. it’s reminder about need of stripping functionality:
Just chiming in a bit, as I seem to have come from the same background as @AGulev.
For most game portals, something upwards of 5mb is a complete dealbreaker for sponsorships. Unfortunately the size has to be taken into account before gzip. Optimizations like keeping the actual engine separate in a CDN is generally just not an option supported by most portals.
As an html5 game developer who relies on sponsorships, I would be less inclined to start any project in Defold because of this. I’m still enjoying Defold, but is commercially unviable for me as a tool for html5 web based games.
I think support for manual/auto stripping would be great - in the game I’m working on, I’m using my own custom physics/collision detection engine (just a simple uniform spatial grid) and would be able to do without the hefty box2d engine.
I know that the defold team is probably already weary of this and are doing their best to keep the size low. However, seeing as we’re writing on Lua and the runtime is probably included in the build, that might be where the bulk of the payload size is and would thus never become negligible.
TLDR - size is quite non-negotiable for game portals. Gzip/CDNs is not a factor we can rely on. As it stands, the runtime is just too big to use right now for this use case.
Sorry if my comment is just a bit of a reiteration of most of the comments, but I just felt like I needed to emphasize just how non-negotiable size is for game portals, and is a problem we can’t work around.
Personally, due to how Defold is (3d engine + non-js), I feel like this would always be this big, so it’s just not a fit for games relying on sponsorships. Which is okay, since I think it can fit other niches. I’m of course optimistic as the tech improves.
Lua is a very small language and it is built to be embeddable in systems with very limited resources. From Lua.org - > About:
“Adding Lua to an application does not bloat it. The tarball for Lua 5.3.3, which contains source code and documentation, takes 288K compressed and 1.1M uncompressed. The source contains around 24000 lines of C. Under 64-bit Linux, the Lua interpreter built with all standard Lua libraries takes 245K and the Lua library takes 420K.”
The physics systems (2D and 3D) takes up a significant amount of space, and probably some other parts of the engine as well but I don’t have any exact numbers.
Don’t be sorry! We understand that this is important to you! There is also a lot of internal requests here at King for both stripping parts of the engine and for streaming parts of the game content. Even if we are not in the exact same situation when publishing games on Facebook as on other HTML5 game portals we are driven by the same desire to have a small initial download. In our case we might wish to get the players into the game straight away on first play and while playing we can download maps and other parts of the game.
I’d say that we have four main tracks going on right now in the team:
This means that we are addressing this issue right now but it is not a trivial thing to solve. Sometimes I think to myself “why is feature X taking so long?” but then I remind myself that we’re never doing anything half-assed. When we release a new feature for the engine it should be extremely well designed and built to last and be backwards compatible forever. This is one of our promises to you that we will never break anything you have created in the past. And with that in mind we need to design things well.
I believe @jakob.pogulis is the one with most knowledge of our plans around streaming of game content. @jakob.pogulis, would you mind sharing some additional information regarding this?
Info regarding our work with streaming of game content is described here: Apk-expansion files
Updated to 1.2.96:
.