From WebKit to Windows 8: Touch Events

As a Windows 8 game developer, you are tasked with the difficult challenge of trying to adapt your game to a myriad of different devices that luckily all run the same operating system. Windows 8 devices range from standard desktops/laptops with keyboards and mice to touchscreens and convertible slates. Being able to think through all the possible ways a user will interact with your game is critical to its success. In this post, I will cover some of the differences between WebKit touch events versus how touch is handled in Windows 8 HTML/JS apps.

Understanding User Input

When it comes to user input, especially in games, we have to take the following types of input into consideration:

  • Keyboard
  • Mouse
  • Touch
  • Other (such as pens, game controllers, etc.)

In Windows 8 apps, we have very granular control over detecting the type of input our app is receiving, which you may not have access to on other platforms. When it comes to WebKit games, there is a clear distinction between touch and mouse clicks. Usually in a WebKit app, you would do something like this:

var touchEnabled = 'createTouch' in document

From there, you could split up the logic in your app to handle touch differently than mouse controls:

If (touchEnabled) {
  //Touch is enabled
  canvas.addEventListener( 'touchmove', onTouchMove, false );
} else {
  // Use mouse events instead
  canvas.addEventListener( 'mousemove', onMouseMove, false );
}

Instead, on Windows 8, you can simply handle all mouse and touch events the same since you have access to an input abstraction class called the MSPointer. On Window 8, we refer to this as “handling touch-first input without compromising mouse” and there is a great article on it here. It’s also important to note that you can also check if the device is touch enabled, just like you do on WebKit, like so:

var touchEnabled = window.navigator.msPointerEnabled

To help illustrate how touch and mouse input is handled on Windows 8, let’s take a look at this visualization of the MSPointer class:

Pointer events encapsulate input from touch, pen, and mouse making it easy to build experiences that are hardware independent.

As you can see, references to a pointer object abstracts the type of input and gives you the necessary x,y values along with other properties you would need to have access to in your game. At first I didn’t understand why I would want something like this over the WebKit touch events, but after playing around with building game controls on several different types of devices, I have learned the true value of this approach.

One of the biggest issues I have had with WebKit touch events has always been testing them. Because you have to split up the event logic between mouse to support desktop systems and touch for tablets you end up with a difficult way to test if touch actually works. Normally, I would have to load up Apache locally and then open the hosted project from my iPad, and if anything happened, I would have to go back to my code, make a change, and reload on the iPad. On Windows 8, you can do all your testing and validating on your dev computer since it doesn’t make a difference to your game if the player is using the mouse or the touchscreen. Obviously, things like multi-touch are difficult to test with one input device if you are using a virtual on-screen controller, but you can still test one button at a time with the mouse to do a simple sanity test. Let’s take a look at how it works.

How Touch Events Work in Windows 8

When it comes to WebKit touch events, you would usually set up the following three events:

canvas.addEventListener( 'touchstart', onTouchStart, false );
canvas.addEventListener( 'touchmove', onTouchMove, false );
canvas.addEventListener( 'touchend', onTouchEnd, false );

This would cover your three main input states. In Windows 8, it’s very similar. The only difference is that you need to reference the MSPointer event instead:

canvas.addEventListener('MSPointerDown', onTouchStart, false);
canvas.addEventListener("MSPointerMove", onTouchMove, false);
canvas.addEventListener('MSPointerUp', onTouchEnd, false);

As you can see, the two are basically the same. If you wanted you could easily detect the platform and swap out the correct event ID if you are building a cross-platform HTML5 game. One of the advantages of supporting this in your Windows 8 app is that IE 10 also supports the same touch model, so it will work flawlessly the web as well.

From here, there are a few additional differences in the event that you would get back in Windows 8 vs. WebKit. In WebKit, you could get the touch point’s ID via the .identifier property. In Windows 8, you would use .pointerID. From there, you can continue to access x/y and clientX/clientY just like you would do in WebKit. After that, your code should work basically the same. Also, since input can come from multiple sources in a Windows 8 game, you can test the pointerType of the event object you receive with the following constants:

MSPOINTER_TYPE_MOUSE  4
MSPOINTER_TYPE_PEN    3
MSPOINTER_TYPE_TOUCH  2

Simply get the value of pointerType from the event and see if it matches up to one of the above values. This is critical if you want your game to ignore mouse input and use the keyboard only or show virtual controls when it detects a touch event. As you start to anticipate your game being played on devices with and keyboards, you may want to enable or disable the touch controls based on the input. I have seen this in several apps that will show the on-screen keyboard when a touch is detected versus a mouse click.

W3C Pointer Submission

I’m also happy to announce that as of today, the W3C has accepted and published Microsoft’s submission for using the Pointer Event as a new specification. Here are some details about the W3C submission, and the comment from the W3C team on the W3C site. The best part is that MSPointer is already implemented in IE 10 and Windows 8, so when you build touch-based games in Windows 8 you’ll have a lot of experience using it. This is a big win for web developers since the Pointer combines touch-first support with support for mouse click and pen, all in a single API, so that developers don’t have to spend a time and effort figuring out what kind of device they’re running on as I’ve shown above. I’ll keep you posted on the submission and hopefully it gets moved to the recommendation track and across each of the other browsers very soon.

Subscribe To My Mailing List

Want to learn how to make a game? Not sure where to start? Even if you are a seasoned game maker there is still a lot you can learn from my free 15 page guide on how to build, release and market a game.

Simply sign up for my mailing list and also get access to great tips and advice on how to make better games. I promise to not spam your inbox!

Join Now

More in Articles (22 of 45 articles)
pixel-art-feature