It’s a Blast!
Nice little details with facial animation. 
You could use VSM shadows, set up the VSM8, so it looks good, and switch to VSM32 so it looks great on desktop. On mobile it will fallback to VSM8 if float textures not supported. VSM is easier to control how smooth they are, to reduce ladder effect.
Consider using ACES tonemapping with changed exposure, to bring the contrast to the game.
Plays pretty well! 
From gameplay, feels like walking on blast fire after it is exploded, kills you, which is a bit annoying 
So in classic bomberman that was a case too, but there was a clear visibility when that would kill and and when not. Not sure how to overcome it without sacrificing smooth fading out.
The major thing I believe you want to address is initial download size, right now it is 19.8Mb! That is probably way-way too much for initial download.
Checked Network tab in Dev Tools, and straight away: mp3’s and wav’s take 80% of that download size. Simply untick “preload” on those assets, so they are loaded in async, and will be playing once available.
Then you have two day 28.mp3 and DAY 5.mp3, you sure you need both?
Wav is not playable on all platforms, consider using mp3’s.
Using mp3’s might be associated with licensing troubles
map_forest model is 1.7Mb gziped, it seems like you use way too many triangles for it, or not utilizing clones of geometry. Consider optimising it, and reusing tiles/trees so to reduce model size.
And 2k for cubemap faces, looks like they are looped (1 could be used? ) or reducing size of it, could do good save too.
So utilising async assets feature, by unchecking preload on assets that wont need right at the start. And with sounds it is pretty much always the case. Even music won’t need at the start.
Then if entity is shown and requires those assets, engine will trigger loading automatically, and it simply will appear once loaded. If you do want to trigger loading straight after preloading is done, you could simply do this:
- Tag assets you want to start loading after app is started with
postload.
- Then trigger loading for them:
var assets = this.app.assets.findByTag('postload');
for(var i = 0; i < assets.length; i++) {
this.app.assets.load(assets[i]);
}
After some of loading/assets optimisations, you can definitely bring your game under tiny as just 4Mb, and make it already interactive by user. So they can start queuing and enjoying the game earlier.
Bounce rate of user raises with every Mb they have to wait and download
It does seems that you encode your WebSockets traffic already. Are you using protobuff? In https://tanx.io/ we do use them, they did made good difference, and even from code point of view - brought some packets schemas, which is easier to manage.
Consider adding permessage-deflate extension to WebSockets, that enables gzip for larger messages. But if you do already binary (protobuff) that wont make much effect.
