That would be super useful!
And also, do you use a custom app manifest already?
If not, you can remove for instance the physics engine(s) and the record extension if you want. SHould also save a few bytes.
https://britzl.github.io/manifestation/
Yeap, did that and kept the very minimum needed. Quite amazing how lightweight the engine turns out to be!
I’m using one atlas file, the problem is that it’s 2048x1024 at the moment, I’m going to strip and reduce as much as I can to make it smaller. Otherwise I’ll try @aglitchman way of just putting everything into one .js file, this way I can make it a <5MB ZIP archive.
Make sure you have disabled mipmaps on the texture! And find a reasonable texture compression level. Possibly split into two atlases with different compression levels depending upon acceptable loss in quality.
I tried rewriting the FileLoader inside dmloader.js to use the javascript Fetch API instead of XMLHttpRequest, but that didn’t work either. It worked with a local webserver, but in the Facebook preview tool, the fetch() call errors.
I guess this is part of their requirement “No dynamic asset loading through external network is permitted”, which prohibits XMLHttpRequest and Fetch.
Did you try in the preview tool in the Ads Manager itself? I’ve noticed it behaves differently from the standalone preview tool.
Version 1.1.0 has been released. Now the script has command-line arguments!
--embed-archive-js <arg> Embed `_archive.js` file: true/false (default = true).
# The following arguments passed to Bob.jar as is:
--build-server <arg> The build server (default = https://build.defold.com).
--settings <arg> Path to a game project settings file. Only one occurrance is allowed.
--variant <arg> Specify debug or release (default = release).
--texture-compression <arg> Use texture compression as specified in texture profiles (default = true).
Run gulp --embed-archive-js=false
to build a playable ad with the two files:
/playable_ad/build/output_js-web/YOUR_PROJECT_TITLE/YOUR_PROJECT_TITLE.html
/playable_ad/build/output_js-web/YOUR_PROJECT_TITLE/YOUR_PROJECT_TITLE_archive.js
@Lex Unfortunately, FB requirements are: the whole game unzipped must be < 5MB AND the index + JS must be < 2MB. I’m sure this new option will not help you at all. The best you can do is to shrink the size of your game!
Yes I did. The standalone preview tool doesn’t seem to be aware of the 5MB Zip format.
About the 5MB Zip format:
If the html and any loaded Javascript contributes to the 2MB limit, then what do Facebook expect the rest of the 5MB for? Presumably other asset types such as images.
I’m not a web developer, but is there a viable technique where we could embed resources in images?
Yes!
You can compress any data into PNGs, but its decompression requires accessing raw pixels. To get raw pixels, you have to load a PNG image as data (using XHR/fetch) or via drawing into Canvas (I’m sure it’s slow).
In my opinion, the best investment of your time is to find a better compression/encoding algorithm. Base64 increases the size of the data to 4/3 of the original.
Also, you can ask Defold developers to add the ability to cut off more modules, like the Live Update system, Zip decompressor, PNG/JPG loader, UASTC decoder etc., to be able to shrink the engine’s runtime a little bit more.
The latest Defold 1.2.186 BETA supports removal of the liveupdate
library. It cuts down the resulting file by the extra 50KB.
This is a decent size reduction! And it really shows how important it is to be very careful with what we add to the engine. Every feature, small or large, will have an impact on the size of the engine, and if the user has no way of opting out from a feature you soon end up with an engine that is useless for certain usecases.
Version 1.2.0 has been released! Now the tool uses Facebook’s Zstd to compress files and fzstd to decompress them. The benefits:
- It saves 300KB that you can use for your assets. The size of the Zstd-compressed base64-encoded Defold engine without a custom manifest is 1305207 bytes (before it was 1627392 bytes).
- Asynchronous decompression, i.e. the decompression doesn’t hang the browser anymore as it did on slow devices before.
This is a fantastic improvement! Thank you.
Any idea how to ship the playable ad with a custom splash image ? right now it just pastes it where the build is but doesn’t it bundle in the code, should I open a ticket on the Github repo or any way I can help out with this?
Version 1.2.4:
- Added a command line argument to exclude WebAssembly files (default is true):
--exclude-wasm <arg>
. The argument is added to have an option to include these files. - Updated UglifyJS to fix issue #9.
Fun fact - the single-file HTML game can be run without an HTTP server, i.e. right from the filesystem. Like SWFs in the good old days!
I have updated the information in the first post to the up to date state.
The last update of the tool was 1.3.0. This version has a new --architectures
parameter that keeps only the specified architectures in the resulting file. The default architecture is now WASM, since most browsers have WASM support.
Awesome, thanks for all your work on this, really is a nice option to have everything be in one HTML!
Hi, does someone try this tool for Unity Ads? I’m kinda stuck with MRAID, I just don’t know, if I need to implement it through native extensions somehow else.