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.
6 Likes
P.S.: And this post not about build size in new versions. it’s reminder about need of stripping functionality:
1 Like
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.
5 Likes
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:
- The new editor
- Improved 3D support
- Streaming API
- Extensions
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?
3 Likes
Info regarding our work with streaming of game content is described here: Apk-expansion files
1 Like
Updated to 1.2.96:
4 Likes
.
The really cool thing about Native Extensions is what it promises to do with build size in future builds. Our plan is to make Bullet, Box2d and Facebook into public extensions that can be excluded if they’re not used by your game. This will have a significant impact on build size and it’s going to be really exciting to see how low we can go!
10 Likes
Dreams comes true 
And then we will able to mark this topic as solved =)
UPD: topic updated with Defold 1.2.100 data
UPD_1: topic updated with Defold 1.2.102 data
UPD_2: topic updated with Defold 1.2.112 data
6 Likes
Is there an ETA on the auto stripping or similar implementation?
it’s already done! You can remove unused modules using App Manifest
More info here
Or here (rus):
http://agulev.com/defold-umenshaem-razmer-bilda-app-manifest/
8 Likes
Did you see last changes on Google Play?
Looks like Google consider build size one of the most important info about an app.
9 Likes
I’ve made the new release .apk today and noticed that build size rised by a Megabyte from my last .apk. There are no new resources, app manifest, etc, the same project with small texts changing.
See on screenshot:
Hmm ???
3 Likes
It seems that it happened in version 1.2.136
Maybe something of these changes:
3 Likes
Yes, unfortunately, in order to be backwards compatible, we needed to update the java packages. And since google stopped supporting a ready made android-support-v4.jar, we had to create one ourselves.
It’s a tedious process, and we’d very much like to get back to it and perhaps use Proguard (if that helps in this scenario) to remove redundant classes.
9 Likes
I have read this article https://developer.android.com/topic/performance/reduce-apk-size
and what I wanna ask:
As I understand Defold adds to apk the Facebook resources (res folder) even if we turn off facebook using appmanifest. How to avoid this? (I understand that it’s something about100Kb but I wanna back my solitair in 3Mb :))) )
As you mention, currently there’s no easy way of removing those assets. Even google play assets are there, which might conflict if you’re using newer google play libraries.
What we’d like to do, is to build upon the app manifest, to remove (or rather hide) the cumbersom configuration part, and instead specify what features you’d like to include or exclude. E.g. you should be able to uncheck a box next to the Facebook feature, and our tools would take care of the rest.
We’re not quite there yet though, so in the meantime, I wonder if the easiest way would be to unpack the .apk, remove those assets and then repack it again?
(I’d really like us to support custom scripts in when bundling from the editor, so you could automate those steps)
6 Likes
I have no updates for empty project, but for Solitaire game:
asmjs: 4.1 Mb and gzip 1.3
wasm: 2.6 Mb and gzip 1.1
3 Likes