WebGl support for mobile browsers

Hi all !
Hope you all are doing fine.
So I want to upload my game on server and play it through mobile browser. aftera little bit of searching I found out that webGl is not in good terms with mobile browsers so can you please guide me about:
1: Is there any alternate to place your game on browser and only make it play able through mobile browsers.
2: My game will be multiplayer so given the current conditions can I use photon? Or is there any other plugin which will work better in this case. Also I want my multiplayer rooms to be open all the time so any player can enter them any time he want to.

 

Why not just have an app version for mobile devices and a browser version for desktops?

 

Because client said so. Actually client don't want a desktop version of the game and also the game will be continuously updated with stuff and our client don't want his users to update every time so game will be on browser and will be updated there and user will just browse and play it through mobile that's it.

 

Also you can not take your computer everywhere but you do take your mobile devices everywhere.You can say that the game some much also depends on promotions and promo codes using which users will play and get gifts.

 

Unity officially does not support mobile browsers even though some mobile devices will play the content just fine. I don't see this changing with companies like Apple including only 4GB of RAM in their flagship phones with no page file support.

So use Unity WebGL builds on mobile at your own risk.

 

Also it's a job for unity's Tiny, look at that, as long as you aren't doing 3D (possible but not fully implemented yet) ... Also tiny is experimental so good luck.

 

<3

For this quandary I'd recommend macromedia's flash and prep the end user for a S***load of malware.

 

Hmm... I understand where your client is coming from, but that's not how it works. Whether it's in a browser or a separate install, if you need to get updates to a player then the data has to be delivered. A browser game may in fact require sending more data to users because you don't get full control over downloading and caching yourself - you leave much of that in the hands of browser and/or device behaviour.

Also, check out AssetBundles. You don't need to update your core game every time your content changes. You can just update bits of content on an as-needed basis.

Despite all of that, I fully understand having to do things because a decision maker thinks they're the best solution, whether or not that's actually the case. Just got to do the best work you can in the situation you've got.

If I absolutely had to do this, I'd modify the script which loads the game to check the current platform against a list of supported platforms, and abort if it's not a match. The thing is that browsers are apparently notorious for not reliably reporting their own identities.

There is this library, bestiejs/platform.js, which says it can figure it out for you, so that might get the job done. Last update was 4 months ago, I don't know if that's noteworthy in this area. Note that even if it does work, I'm sure that someone who really wants to could work around it pretty easily. For instance, they could just make a local copy of the page with that script which skips over the check. Or use a browser plugin which spoofs the reported platform. Or run it in an emulator (there's probably no stopping that one). Or... a lot of things, really.

 

First, from my own experiences, there's a misconception that Unity WebGL doesn't work well with Mobile Web browser.
That's 100% false and you can run Unity WebGL quite well even on relatively old mobile devices' browser.
What's true is that Unity WebGL in mobile browsers is not officially supported by Unity, meaning that bugs/glitches/limitations created from the WebGL built that only affects browser in mobile devices are so far down the line of priorities that they might never be fixed at this point. Any problem you face are usually something you got to fix by yourself with little support.

That little message that appears when the page is loaded on mobile devices is just a warning created through the page's javascript and it can be removed or changed. It doesn't stop the page from loading the game at all.

With that said, the things to understand about Unity WebGL on mobile browser is:
1) Tris counts aren't much of an issue.
I was able to run a scene with > 800,000 tris moving around at 30-40 FPS in a mobile browser including world-based UI raycasting and other stuff like that on a 1GB RAM cheap (low-end) tablet and phone. (The kind of phone that have an hard time loading Google Play Store.)
2) Texture count is important, so Atlas as much as you can.
In my project I previously explained, all the UI elements ,except for detailed logos, all fit within a 1024x1024 textures. All the buttons icons, gameplay icons, UI frames, etc. were fitted in that single texture. I wrote a shader that uses barely any textures (all character had the same materials with instanced parameters for customization like team color). Basically, fuse as much as you can.
3) Sounds should be kept small enough.
I would say that a music-based game would have an hard time on a mobile browser when built in WebGL. Sounds is quite heavy on the memory and I optimized my project by limiting the number of explosion/sound effect played at once. (Up to 15 sounds effects + 1 music at once including gameplay & menus sounds felt like okay performance wise.)
4) Use Coroutine wisely instead of Update & LateUpdate()
Coroutine have the quality of not being imprinted into the memory when they are "done", I used coroutine to manage all the "physics" and movement of my project and it worked relatively well.
5) Prepare the game for both screen orientation.
This was my biggest mistake with my project. You can't force a browser to display in 1 orientation as web page loaded in browser has 0 authority meaning they can't force a device to be displayed only in 1 orientation. If the device rotate, you got to prepare not only the game's UI itself, but also the CSS (and web javascript) to adapt to the new orientation or you'll find your game to be visually broken fast.

There are 1 issue with your customer's request.

There will always be update from the user's side.
The way the game is loaded in the browser makes it so that as soon as the game files have changed (updates or whatever), the user will have to re-download the whole content on his/her next visit. This is how browsers works with their cache. The only exception (which still means download) is if the webGL app only load a basic launcher and the user purposely download (through it out externally) a plugin that could store the game's data more permanently and "intelligently".

The concept of having games in browser with the mention "no download required" is false advertising and only a PR stunt. The user will have to download all the game's file regardless of it being in a browser or not. What's true is that there's no installation required and that's actually what's mentioned nowadays (after a few lawsuits where users sued browser game company for false advertising as they had huge mobile data bill because they were downloading the game multiple time in a month whenever it was patched.)

Finally, a multiplayer game in browser is a colossal task that can be seen as even harder than doing it in a standalone app. The main issue is defining proper IDs within the game server. The minimum requirement to counter 90% of the problem is to have a login system because it's kinda hard to setup IP and Authorities from within a browser. For example, what happens if a user open the same page with the same cache twice?

This is not for nothing that over 95% of the multiplayer game in browser aren't truly multiplayer games, but instance-based game where player's data are sent to a server in the same manner as having a score board updated. Even since the half of the Unity Web Player, tons of games that used it couldn't be converted to WebGL specifically because of the issues from the Browser perspective and, on mobile browsers, those problems are exponentially exposed even more. (For example, mobile devices have dynamic IP address that can change all the time as they can connect to different routers or use mobile data. It's relatively really hard to ban or even just detect a player's digital ID in a browser based game.)

This is the link to play the project I previously mentioned :
M3Dieval
You'll notice that some movement may be a bit jerky, but that's because I made it so that the movement of the stuff (which isn't top in the importance) aren't "important" framewise. Save quite a bit in the framerate. (So, some movements are a bit jaggy, but the framerate is consistent.)

The only thing I haven't uploaded yet is the fix for the game orientation when the mobile device is turned to the portrait orientation. I didn't prepare for that (which is why I previously called it "my biggest mistake") so I got to script quite a bit when it come to the UI adaptation and I also faced some issues on the CSS/Javascript side where the game's screen size in the browser was breaking a bit after turning once on some devices.

 

I have a piece of JavaScript that addresses this. I'm sure it's not foolproof, but I think it will work for what I'm doing.

The basic issue for me is that I need my end users to be in either Firefox or Chrome to enjoy the Unity WebGL experience, and I'm going to limit them to desktop versions of those browsers. The information above, about some mobile browsers being able to handle the Unity WebGL content is good information, however for now I'm going to exclude those browsers.

Also I'm excluding Safari in any version. Safari is a tough thing to test for because the userAgent line is not standardized, so every browser sends back a slightly differently formatted set of details when you query that in JavaScript, and both Chrome and Firefox use the word Safari in that information.

So the way I'm trying to test this is in two passes:

1. If there's stuff in the userAgent that indicates you're on a mobile device, it picks up on that and rules out the browser.
2. If there's stuff in the userAgent that indicates you're using Chrome or Firefox, it picks up on that and says the browser is ok, it should be good to go for Unity WebGL.

If it doesn't hit on either of those two things then it assumes you're using Safari, so that's an implicit test. The elephant in the room here, that nobody wants to discuss, is Microsoft Internet Explorer / Edge which this code does NOT test for, either explicitly or implicitly.

In my case, my users have to get past a wall in order to even access the thing that will show them this Unity WebGL experience, and that wall filters out users of the Microsoft browsers, so I won't be getting any of them even trying this. The same thing goes for Opera and other browsers.

Another thing this doesn't test for is the version of the browser. However and again, where i'm posting this really old browsers are a very unlikely scenario, and there is disclaimer language attached to that portal that says you're supposed to be using an up-to-date browser.

So here's this code, in case it helps anyone:

isUnityWebGLReadyBrowser();

function isUnityWebGLReadyBrowser()
{
var DevicesUserAgents = ["blackberry","android","iphone","ipad","symbian","smartphone","ios","windows ce","webos"];
var DeviceUserAgentString = navigator.userAgent.toLowerCase();
var AcceptableUserAgents = ["chrome","firefox"];
var isItTrue = "initial";
var hit = "initial";
//console.log("isItTrue = " + isItTrue);
//console.log("The DeviceUserAgentString = " + DeviceUserAgentString);
for(var i=0; i < DevicesUserAgents.length; ++i)
{
if(DeviceUserAgentString.indexOf(DevicesUserAgents) != -1){
isItTrue = false;
//alert("isItTrue = " + isItTrue);
//return false;
}
}

for(var i=0; i < DevicesUserAgents.length; ++i)
{
if(DeviceUserAgentString.indexOf(AcceptableUserAgents) != -1){
isItTrue = true;
hit = DeviceUserAgentString.indexOf(AcceptableUserAgents);
//alert("hit = " + hit);
//alert("isItTrue = " + isItTrue);
//return true;
}
}

if(isItTrue == "initial"){
isItTrue = "must be Safari!";
//alert(isItTrue);
}
}

 

Ok then, what's the risk.

 

That you spend time and money on a mobile WebGL project which ultimately fails, and can't get help from Unity since you should have known better than to target browsers which are specifically not supported. That's assuming you put value on time and money.

 

First, thanks for all the comments here, they're very helpful. I've a client that could make use of a 2d mobile browser application, and I'm searching for workable technologies. Unity would be ideal because we already have custom scripts that take some fairly hefty data and import into it, but the constraints are: can't be an app because of app store charges on IAP, must be mobile-friendly first. Actually that's about it. Had considered Flash (well not really, HTML5 canvas but using Adobe Animate to create UI, which works but is a bit clunky). As a front end and means for creating the app Unity seems borderline ideal. For deploying given the constraints it doesn't seem to work - unless I'm missing something? All suggestions much appreciated.

 

The status of Unity WebGL builds on mobile browsers is unchanged since this thread was created. Unity specifically states they do not support mobile browsers, which will also mean they do not do any regression testing on mobile browsers. Your app may work or it may not. It may work on some devices and not on others. One problem is mobile devices generally have limited RAM (especially iPhones) and do not support virtual memory.

https://docs.unity3d.com/2020.2/Documentation/Manual/webgl-browsercompatibility.html

 

Is there any word on the future plans of WebGL support for mobile devices?

 

Yeah, if you really care about WebGL you should use Playcanvas or something, because Unity obviously doesn't care enough about this to significantly improve in the last.... 2-3 (maybe more) years?

 

Using Playcanvas is probably the right thing to do but It's not as ideal as if Unity supported mobile WebGL. PlayCanvas is a relatively good engine but it has so many flaws and missing features that make it hard to work with.

 

As to opposed to Unity?

In any case proper support probably won’t happen for a while.

They don’t care, they threw it on the pile of “maybe it will magically fix itself when DOTS / Tiny / whatever” arrives.

 

I am pretty sure they are just waiting for WebGPU to come out instead of sorting out current WebGL.

A lot of the issues come down to browser support and dont sit on unitys side, WebGL is just not the standard everyone hoped it would become, but WebGPU does actually seem promising (but its likely like 2+ years away)

 

However..
"WebGL (the API) is not considered a dead end, not even after WebGPU arrives, because WebGPU adoption will be restricted to Vulkan, D3D12 and Metal capable devices."
https://forum.unity.com/threads/webgl-roadmap.334408/page-10#post-6497713

 

Damn. Looks like we are just forever going to be stuck in limbo when it comes to web....

 

Every engine has flaws, but Playcanvas lacks a bunch of fundamental features that make working with it really hard.

For example, there is no visual animator/animation tool. If you want to animate properties you have to program it using their tween library.
There are also no scene view and inspector for runtime. That makes debugging & bug solving take a lot more time and effort.
Now let's say that you have multiple projects and you want to share a common codebase between them. With any offline engine you'd be able to treat that common codebase as a subrepository and then share it with all your projects. In Playcanvas everything is cloud-based, so you can't do that and their built in source control system is too basic for that.
Not only that but you can't import/export entire libraries of files. You have to manually download each file, and manually reupload it to other projects. You do that without even the ability to keep the folder structure intact.

These and more are major issues that make working with Playcanvas a living hell for any project that is not small.

I'm not too optimistic about project Tiny btw. It's part of Unity but it looks like an entirely different engine with different API's for pretty much everything. It's so young that I'm not sure when it will be ready for serious production

 

Also I thought they said they would be rolling Tiny into the main engine, so not even sure what form it will take in the end making it hard to work with right now

 

I'm assuming we'll just be able to select WebGL or WebGPU from a dropdown (if not "Both" - which would be ideal).. or at least pick one or the other from platforms list. I don't have any major gripes about WebGL as it stands, sure it's not great for mobile web browsers, but neither are half the websites and they're just content + javascript, so if my phone's web browser lags just loading a page of news, there's clearly not much wiggle room.. but for mobile we can publish apps ..of course, originally I thought like "why would anyone ever make an app again!?" until the limitations of mobile web browsers sunk in. The thing is, app stores, companies that own app stores - I don't see them throwing all their weight behind making smooth and silky mobile apps possible in web browsers. That could end up hurting the bottom line. Basic WebGL support? Sure! Make it work as well as an app? *looks away whistling* ..just a thought, I'm sure there's more to it, but does make sense that would be a factor in how far behind the times these mobile web browsers are..

 

I mean, that's not the worst thing, even in Unity I often end up scripting animations, because the animator is too slow to use and there are issues with animation. But yeah I get your point.

Fair enough! I don't have too much experience with Playcanvas, I have just seen a lot of webgl made in Playcanvas that look pretty decent that also play fine on my phone.

 

Its runtime is great. It loads quickly(about 1MB for empty build size) and has some pretty good performance for a JS based web engine. But all the issues I mentioned means working with it can be tough(even though it's very similiar to Unity).

 

In my case webGl + Photon works fine on mobile broweser,
but its lags terribly, although everything is ok in the app
maybe fierce optimization will help, let's see

 

Duh. Of course it's going to run fine in the app only to run poorly in a browser. Browsers introduce a tremendous amount of overhead to everything running within them. You can take your time optimizing till the end of time but you will still never achieve the same performance in a browser that you will in an app. That's just how it is.

All that said if you still want to or have some reason you must make a browser-based app the way you do it is with a game engine that is both designed and optimized specifically for browsers. With Unity browser support is at best a second class citizen and at worst a homeless bum.

PlayCanvas is the engine you want. It supports mobile for both Android (Chrome) and iOS (Safari).

https://playcanvas.com/
https://playcanvas.com/project/433966/overview/photonstarterkit

 

Oh wow, PlayCanvas is amasing!!!
Super useful and exactly what you would expect from Unity to do. But it doesn't :|

 

Not really sure why you expect unity, a generic engine supporting 25+ platforms, to support web as good as playcanvas, an engine that is made specifically for web only. Ofcourse it doesnt do the same thing.

 

Because WebGL is one of those 25 platforms and because those 25+ platforms are not very helpful when you have to deploy 3d content using web technology to mobile devices. Nobody wants to install an app for an ad campaign.
One can expect to use an editor that is already familiar and fast with to deploy to web, especially when it claims to do so. WebGL for mobile works great in Unity when deployed through Forma... so it is possible... just marketing limited by the look of it. One source code multiple deployments, etc.

 

Any updates with Unity optimizing for mobile web browser? Trying to make something 3d and I dislike the appstore lol.

 

None, and if we're being honest you're not going to see optimizations for Unity's WebGL builds that make them viable on mobile devices. Both for the reasons mentioned in this thread but also because WebGL itself is in the process of being discontinued by Khronos in favor of WebGPU (a Vulkan-like API).

If you want to develop for mobile devices using the browser either use PlayCanvas or BabylonJS because unless you just like to sit around twiddling your thumbs those and other game engines made specifically for WebGL are the only short-to-mid term solutions available.

 

Actually you can use webgl in unity for mobile right now, as we did for many clients such as *Removed clients name*, but it is VERY difficult and in general is not worth the hassle compared to using Babylon JS etc unless you are very stubborn or only have skills in unity and do not wish to branch out.

That said, if you did want mobile WebGL with unity, the latest unity versions have the most added that helps it running smoothly. The biggest thing that made it viable is safari now supports WebGL 2.0, which really changes things compared to before (and when we started it was still limited to WebGL 1.0 which made things very hard).

 

Ah it's actually awesome that safari supports WebGL 2.0. Yea I would want it this way to finish the MVP build through Unity to list on the google play store, and then convert as much as possible with WebGL to avoid doing too much rewrite. The MVP itself would probably violate Appstore rules, so I'd like to have a mobile browser version for iOS people to still play-test to some extent and help validate the MVP, even if there's no cross-platform potential between the initial web and android app versions and the web experience is worse.

I hope this last statement isn't too forward, but I'm also curious if you're taking on any new potentially long-term clients for remote, mobile dev work, paid in cash and equity, and if so you can send me a pm. If the market likes the MVP, the company may soon end up competing with Apple and the mobile appstore duopoly.

 

Thanks for the response. Looks like I'll need to look more into PlayCanvas.