Typical size for HTML5 build

[Bateleur]

Hi!

I just tried exporting to HTML5 and to see how my game would behave on that platform. It worked flawlessly. However, if I zip the whole bundle folder to get a rough estimate of the download size, I’m at 6MB. And I didn’t even start to add sound / music assets. I would simply like to know what is considered small, medium sized or large HTML5 games. Obviously the smaller the better. But considering I still have assets to add and some game logic, am I already overboard?

My issue is with the archive folder which stores the assets. I have a dictionary there which takes about 2MB and it is non negotiable - unless I rearchitect the app to query the dictionary on the server. Other than that I could potentially remove my splash screen, a 1280x720 texture as well as use some form of tiled background for the game itself (it, too, uses a 1280x720 texture). The letter tile textures I cannot remove or change.

I am not done with the game yet. I’m still working on the game play. I might write a dev diary message at some point.

Also I have another question! Word games are not your typical Steam player bread and butter. At first, I thought of distributing as a Windows app which would remove size constraints. But where can I distribute the app if I have monetization in mind? I could do Steam for sure but perhaps HTML5 is a better platform? Monetization is more difficult there. Plus the looks of my game doesn’t fit what is found on Poki. I can reskin it a bit though. One really cool thing I could do is to make it a multiplayer game (2 player game actually). Right now you play against an AI. But that’s another ball game

Thanks!

[d954mas]

It better to upload game and check size in chrome dev tools.
Or upload only wasm in zip to test size local. By default defold build wasm and asm architecture.
Asm is something old, and I think all devices now support wasm.

About web game size.
1)Check build report. It will show size of all you assets.
2)About engine size. Engine is about 1mb in gzip. Less if you remove some parts in appmanifest

[d954mas]

Also it is easy to move music to live update. And load and start track after player start game.

Background music, really take a lot of space.

[Bateleur]

Hi thanks for the reply! I have already used the app manifest to remove some engine features such as 3D engine. I also removed live update but your tip with music is a good one. I will reintroduce live update and perhaps use it for music if I distribute as HTML5. Where is the build report? Is it a file generated somewhere when you bundle your game?

[totebo]

The suggestion of checking the actual download size in the browser is good. Defold exports more than is actually downloaded.

Live update is also great, and I’d recommend loading anything that isn’t critical after the initial load. This can include music, but also backgrounds and other cosmetic objects.

[COCO]

In other engines like Solar2D, the game data and the wasm files are zipped into a bin file, that can be loaded directly by the main html file. why defold don’t do something like that? Defold relies on the server to compress all files at request time?

[AGulev]

@d954mas

It better to upload game and check size in chrome dev tools.
Or upload only wasm in zip to test size local. By default defold build wasm and asm architecture.
Asm is something old, and I think all devices now support wasm.

HTML5 bundle size

Let’s figure out how to find out the size of the #HTML5 bundle. The most reliable way is to upload the build to the target platform (e.g., a test account on poki, or your itch account), open the Inspector in Google Chrome, and check the Network tab. [Screenshot 2023-06-09 at 08.45.25] [Screenshot 2023-06-09 at 08.46.05] I have attached a screenshot showing the size of an empty Defold 1.4.6 build with and without the app manifest. You can check it yourself: Empty bundle without app manifest …

[AGulev]

@Bateleur

Where is the build report? Is it a file generated somewhere when you bundle your game?

[Bateleur]

Thanks all!

Thanks @AGulev for the indications. The report is quite exhaustive. I could see that the texture data is where I should work mainly (4.4MB). The dictionary is 1.7MB which is not too bad. But it can be downloaded while the splash screen and menu are showing. BTW I don’t have a menu just yet either so it’ll increase texture data.

@totebo I would have to refactor the app to isolate various resources to be downloaded at separate times. I thought I would distribute for Windows so I didn’t pay much attention to that. It’s not like my app has levels too : I have just the game. Levels are only parametrized by a few numbers (max word length, some AI parameters for difficulty levels, etc…nothing in terms of new assets, except perhaps music per level but this aspect I have not touched yet so it would be easier to build correctly right off the bat with HTML5 distribution in mind).

[Bateleur]

For people interested, the manual states that:

• Facebook has a recommendation that a Facebook Instant Game should start in less than 5 seconds and preferably less than 3 seconds.
  • What this means for actual application size is not clearly defined but we are talking size in the range of up to 20 MB.

I think I will reach 10MB no more. So I suppose 20MB is for 5 seconds load time which would put me at 2.5 seconds. I should be fine. Especially if I defer loading of the dictionary and main screen background. And music!

[Bateleur]

So I just read the manual and saw that live updates are quite easy to implement. This doesn’t prevent me from having two questions nevertheless:

1. If I want to separate the textures into two packages - one loaded at first with the main app and one I would load dynamically via live updates - do I have to use two atlases or Defold will create my live update package by inferring where I use a texture, notwithstanding the fact that it is in the main, unique, atlas I have?

2. The second question is related to custom assets loaded via “sys.load_resource”. Since this is in code, is Defold still able to infer which collection or package the resource will be bundled with?

I sort of was wrong when I said my game didn’t have levels. It does. Since when I started coding I thought I would have levels with different assets and all, I made a load system and I’m using a collection proxy for the game - the unique level so far. So in my main collection I have the splash screen and a GUI. It loads the game after the splash screen. So it will be much easier for me to use live updates.

But right now, the dictionary is “sys.loaded” in the main collection. If I move this code in the game collection, will that be sufficient for Defold to package the dictionary as part of the live bundle?

[britzl]

@Bateleur

If I want to separate the textures into two packages - one loaded at first with the main app and one I would load dynamically via live updates - do I have to use two atlases or Defold will create my live update package by inferring where I use a texture, notwithstanding the fact that it is in the main, unique, atlas I have?

You need to create two atlases, and make sure that the one you want to download using LiveUpdate is part of an excluded collection, AND that the atlas is not used in the main bundle, in which case it will not be excluded.

@Bateleur

The second question is related to custom assets loaded via “sys.load_resource”. Since this is in code, is Defold still able to infer which collection or package the resource will be bundled with?

These are not automatically included in LiveUpdate. You can put whatever you want in your live update zip archive and when you mount the archive you should be able to load it using sys.load_resource()

@Bateleur

But right now, the dictionary is “sys.loaded” in the main collection. If I move this code in the game collection, will that be sufficient for Defold to package the dictionary as part of the live bundle?

No. See answer above.

[Bateleur]

Thanks Björn! This should not be too difficult to achieve as most of the stuff I use is in the game collection. Only a few assets I use in the main collection.