Is there any way to keep the mouse cursor in the Unity web player window? I’m using mouse clicks in my game and they don’t register when the cursor is outside the player window.
Is there any way to disable the default right click function in the web player? I’d like to use the right mouse click for a game function, but it only works when the player is in full screen.
Thanks!
#1 is actually a huge problem when using the mouse input for navigational purposes as well as clicks. Same with #2 and also scroll wheel stuff for zooming or whatever. I’m not sure how you guys could solve this, it happens with Flash and ShockWave too I think. Is there anyway to force the focus onto the Unity web player? I guess we could all put a disclaimer at the bottom of our web players saying “full functionality only available in fullscreen”?
I don’t see how you could limit the cursor to just the web player. That would prevent the user from using their cursor to select something else, another window, another app, etc… Although it could be confusing, you could do a fake cursor that you control. That would be easy to keep in the view. If doing that I would probably make it look at least a little different from the real cursor.
I also had problems using the cursor keys (up/down, left/right) with the web player. Unless the mouse was over the Unity window, the keys tended to move the page up and down. I love the look of a Unity player integrated into a web page. Gives the game a very professional, finished look. Has anyone come up with a clever solution to this problem?
Or, if playing the web player in a window won’t work, is there a way to automatically launch the web player in fullscreen mode? I’d rather not do it that way as it forces me to stay with one resolution/aspect ratio, but is that the only solution (other than delivering as a stand alone)?
It’s not a problem of visually keeping the cursor within the boundary of the player, it’s keeping the focus of the mouse input on the Unity player. I also sometimes have the problem of keyboard input not being recognized by the player, and in that instance you have to click back onto the player. That’s fine for people that know that you have to bring the focus back onto the player, but the average user might not realize this and get frustrated, and therefore move on. Web surfers are all afflicted with a serious case of ADD and might move on at the first instance of inoperability.
Quoted for agreement. You’ve nailed it on the head!
I’m having this problem with some of the people I’ve distributed early tests of my game to. Some of them gave up, not because they were inattentive, but because they just didn’t know much about the common-sense we take for granted with computer users.
I can’t think of an easy solution besides requiring full-screen. But that’s another step someone has to remember, and no matter how simple, I’ve discovered recently that some people get confused very easily on the simplest instructions.
What if you put something like this in your game before it starts:
You could have nice clean white text on a black screen, then alter the text at runtime depending on Application.platform. (You’d tell Windows users to right-click.)
If you wanted to be really draconian, you could not load the actual game until Screen.fullScreen is true inside of a coroutine checking every frame. Of course this screws machines that can’t go into fullscreen in the web player.
-Jon
Good idea (breathes fire).
In shockwave you can disable the menu with the publish settings if you want to and a mouseloc is available via an extra.
As long as we’re thinking of constructive upgrades to the Unity web player I just wanted to mention a recent experience I had at an Apple store. I walked up to a 30 inch LCD screen and thought, “damn, let me see how the FPS tutorial would look on this huge screen.” I fired it up into fullscreen and to my dismay it went into some pixelated crappy representation ( I’m guessing it was 640x 480). It looked awful. It would be cool if the default fullscreen resolution of the web player was the current fullscreen resolution of the user machine. I’m sure there’s some reasoning behind the current settings, but it really shocked me to see this web player so poorly displayed on a top-of-the-line machine.
Another big vote for that. There’s nothing worse than that except for seeing someone else go fullscreen with your project on an LCD and think, “eww.” This happened to me recently and it sucks.
Nope this would be a very bad idea as this would mean that a) you would disable the fullscreen experience for a lot of users due to that the larger resolution also means a huge performance hit and b) as long as there is no mouseloc it will decrease the user experience depending on the steering for those who would have to stay in windowed mode.
The only reasonable solution i can think of is that choosing the resolution as quality settings are made available in the web player’s selection menu if the author wants it and/or the settings the author would like to offer in the application on his own.
The web player full screen resolution is the default full screen resolution in the standalone, which you can set in the player settings.
You might argue if 640*480 is the right setting for the fps demo though.
Doh! I didn’t even think of that 
The frustrating thing I run into is since I have Expose turned on using the corners I will accidentally trigger Expose when playing something in window mode if I am using the mouse. It always takes a second or two for it to register what has happened :lol:
Yes, this was what I hoped I could do in Unity.
I guess the bottom line is this:
For game control in “windowed” web players, don’t use the mouse, cursor keys, tab key or any other key used in the browser.
IMHO, the “full screen” mode in the web player is nearly useless. Without knowing what resolution or aspect ratio the player’s screen is set to, you risk playback that is distorted or too “blown up”.
The only other option, at present, is to deliver the game as a stand alone.
Man, that is a lot of keys NOT to use. Then if you add the problem of Keyboard specs not following any sort of standard, combining any of the “allowed” keys has to be added to your list of no-no’s.
What about a javascript running in the .html that handles the focus? Does the Unity web player accept input from browser generated events? html javascript functions calling Unity JIT compiled javascripts?
Cheers,
-VicTom
Regarding focus of the web player instance.
The problem here is that the Web Browser doesn’t make the web player instance focused until you click on it. There is not much we can do about it as this is determined by the Safari / Firefox / IE. You get the same behaviour in Flash or any other web player.
So the trick is to make the user click on the web player instance, once he has done that, input will only go the plugin and eg. arrow keys will not scroll down the window anymore. Everything will behave like you want it.
The traditional way of forcing the user to focus the web player is to just have a button somewhere he has to click. Once he has done that, you can use arrow keys in your game without problems.
What about an option where full screen mode shows the game in the resolution selected on the Build Settings and places a border, perhaps black, around it to the edge of the screen?
You have control over the players screen resolution. You can set it in Edit → Project Settings → Player, modify the full screen width height. Also if the users machine doesn’t support the specified resolution the closest one supported will be chosen instead.