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.
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
<3
For this quandary I’d recommend macromedia’s flash and prep the end user for a shitload 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.
2 Likes
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.
16 Likes
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:
- 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.
- 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?
1 Like
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?
1 Like
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.
1 Like
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)