We created and deployed a .io game with Unity, costs to deliver are significant

Hi there,

We created an .io multiplayer game in Unity. It is ad-supported F2P. Our bandwidth for multiplayer isn't too bad (we are using our own solution), however the game files themselves tend to get very large. We have minimal assets, and yet the asm and data webunity files total to almost 8MB, which means that we incur a non-trivial amount of bandwidth cost just to deliver the game to people.

Would it be possible for everyone to use a shared hosted location for these large files, and have the Unity editor properly choose the right files at build time?

 

Try the Brotli compression option if you haven't to see if it can reduce your file size.

I'm also curious how much you're paying per gigabyte delivered. Perhaps there's a CDN that's cheaper than what you're currently paying.

I was curious so I did some math. S3 costs 9 cents per GB, so for every dollar spent on bandwidth you get about 1400 plays. That means you need an eCPM from your ads of $1.40 to break even. That may be achievable depending on your audience but I can see why it would be a bit steep.

 

You also have to consider the multiplayer element. Web games are server-authoritative, which requires additional bandwidth that cuts into the profits. The servers themselves need to maintain a certain number of CCU to pay for themselves. In the end, the cost per client can be significant. In our case, the cost to deliver the game is comparable to a long play session. It can be taken down (and client cache space saved) by providing known, cached locations for the dependent files. I think it would help the Unity community as a whole.

 

Sure, I only focused on the bandwidth aspect since that's what you were complaining about. In my game, the bandwidth costs are less than 20% the total server hosting cost.

I think the real issue here is that your revenue model isn't effective enough. Unity could reduce your bandwidth costs a bit if they added that feature, but regardless of that happening, you need either something players want to purchase or a better ad strategy.

Bandwidth these days is relatively cheap and will only fall over time, so I doubt Unity will spend significant resources in this area.

 

You can cache the client locally by checking "Data caching" in Publishing Settings.

 

@Fizzer , I know what you're saying, however when I compare a unity-based web game to a game using a dedicated javascript engine, the difference is very significant. I've compared our game with about 100kB worth of assets to every other .io game that is out there right now. Our game is 10x larger, because over 7MB is the support files.

Our game is kazap.io. If you compare it to starblast.io, we have significantly less content, but are over 10x larger. Bandwidth during play is reasonably optimal, and we are able to eliminate the bulk of it, however nothing can be done about the delivery side, unless Unity were to offer CDN hosted versions of asm.js and data.asm.

 

You're absolutely right. Unity WebGL is very heavyweight compared to other javascript frameworks.

Your request is reasonable -- I'm not trying to tell you that it's not. All I'm saying is that I don't think Unity will do it.

What I think they will do is to optimize away and slim down more of the bloat that isn't needed to reduce filesizes and decrease load times. I desperately want to see them do this as well, as I'm very dissatisfied with the current load times. But that will probably be something that improves slowly over time, so my recommendation is to focus on what you can control.

 

It's just not feasible. A huge memory benefit is stripping unused code/classes/etc. from the Unity game engine. Every project will have a different code base. On top of that, every unity release (including beta and patch releases!) will almost certainly require new javascript/webassembly. There's a lot of Unity versions out there!

While conceptually the idea is fine, I just don't see it as a feasible solution in the foreseeable future.

 

So I have an update: The size of the Unity runtime, while large, becomes less significant once you start getting more traffic. At the moment. For May we paid over $200 for Cloudfront, vs $120 for compute and $40 for gameplay bandwidth. We made a lot more than that off of ads.

However, there is a problem we are having a hard time quantifying:

Our game can take a very long time to load on some hardware. This could be because the runtime is so large, and it could also be the odd compression format Unity seems to be using that appears to rely on a javascript decompressor. We haven't found a way to effectively turn this off (yet), though it might just require a Unity update. In general, it is better to use server/browser gzip than it is to use a decompressor in javascript - it will simply be much faster.

The result of this long loading time seems to be contributing to a high bounce rate.

 

Kind of off-topic, but how do you handle the server-side part? I'm using photonengine and I'm curious about the alternatives.

 

It's completely our own implementation: A stand-alone back-end server with a C++ core and a C# script interface. It is effective a game engine that 'renders' to the network.