This case study shows you how to implement multiple input methods for Intel based Hybrid devices.
Trine* 2 from Frozenbyte, Inc. struggled with optimal playability on Intel® processor-based touchscreens and 2 in 1s running Windows* 8. Supporting varied play styles and local multiplayer required input flexibility. Adding touch support allowed mobile play, but it was only one step towards a more robust solution. Frozenbyte wanted Trine 2 to support 2 in 1 conversions, i.e., detect when the device mode changes and automatically toggle between the two modes, tablet and laptop. It wanted the game to offer a fresh combination of control schemes to keep pace with the new market created by these devices.
Introduction
Frozenbyte, Inc., a Helsinki-based game developer, targeted the computer and console markets. It was already successful with Trine, a 2009 hit sidescrolling game of action, puzzles and platforming. Trine 2 launched in December 2011 on Windows, OS X*, Xbox 360*, and PlayStation* 3 and made its way to Linux* and Wii U* soon after. Now Trine 2 is distinguished as being the first stereoscopic 3D game on the PlayStation 4. With the increase in mobile gamers and touchscreen technology that makes the game more directly interactive, Frozenbyte adjusted their focus.
In Trine 2, the player controls three characters-a wizard, a thief, and a knight-each with their own abilities. The wizard uses telekinesis to move things and spawns objects by drawing them onto the world. The thief fires arrows and swings from a rope for additional mobility. The knight has melee attacks and a shield. A player can swap between these characters in a single player game, join an online multiplayer game, or invite friends to plug in gamepad controllers to simultaneously use all three characters. Laptops provided an acceptable experience for single player and local multiplayer games, but only when using gamepads; the classic keyboard-and-mouse combination is only viable for single player and doesn't make use of an available touchscreen. Frozenbyte needed to provide a new control scheme and options to use whichever inputs are available.
The Problem with Input
Generally, only a few control schemes are available: gamepads, with all the control in a traditional console approach; keyboard and mouse, which require a more stable gaming position; and touchscreen, adding a pseudo-gamepad overlay onto the game. Most games have control options outlined in the main menu settings (or even an external file) to maintain consistency, but this is mandated inflexibility in play style. While each of these control approaches worked in Trine 2, a couple things were missing: the ability to change controls on the fly and a more elegant control scheme using multiple input types at once.
Many actions were too complex for the laptop touchpad to handle when playing Trine 2 in single-player mode. Gamers can use the "WASD" key scheme to move, but interacting with the environment was cumbersome without a mouse. Fortunately, many of these actions worked better on a touchscreen. Using a standard cursor worked well enough to target the thief's grappling points or arrows, but drawing a box onto the screen as the wizard was easier by simply reaching up and swiping around where you want the crate to appear. The cursor-based actions translated well to touch, but most tablets do not have external keyboards.
2 in 1 Solution
Using a touchscreen alongside a keyboard provided the desired flexibility. The keyboard allowed players to move and swap between characters, while the touchscreen allowed them to interact intuitively with the game world. This control scheme is new, but is important to a modern audience.
2 in 1 devices offer multiple play styles. Users can, for example, use tablet mode with a control overlay while commuting, then switch to laptop mode at home. To make the transition smoother, the game had to adapt to mode transitions.
Fortunately, this conversion event can trigger a listener or send a message (WM_SETTINGCHANGE) to the top window. The game handles the change as a virtual button press if the string "ConvertibleSlateMode" is passed as one of the message parameters (lParam). The C++ example below shows the change being detected and passed along appropriately.
| 01 | case WM_SETTINGCHANGE: |
| 02 | if (slateModeDetectionDisabled || lParam == NULL) |
| 03 | return >true; |
| 04 | |
| 05 | if (wcscmp(L"ConvertibleSlateMode", (WCHAR*)lParam) == 0) |
| 06 | { |
| 07 | if (wParam == 0) |
| 08 | { |
| 09 | // Presses a virtual button |
| 10 | touchscreen->slateModeOn(); |
| 11 | |
| 12 | mouse->resetWMIgnoreCounter(); |
| 13 | keyboard->zeroElementsOnNextUpdate(); |
| 14 | |
| 15 | if (touchEnabled) |
| 16 | { |
| 17 | tryEnablingTouch(); |
| 18 | } |
| 19 | } |
| 20 | else >if (wParam == 1) |
| 21 | { |
| 22 | // Presses a virtual button |
| 23 | touchscreen->slateModeOff(); |
| 24 | } |
| 25 | else |
| 26 | { |
| 27 | FB_LLI_PRINTF("Unknown convertible mode detected"); |
| 28 | } |
| 29 | } |
| 30 | / /This returns false so that WindowsHIDHandler can tell DirectInputHandler to zero keyboard if needed. |
| 31 | return >false; |
Code Copyright(c) 2011, Frozenbyte, Inc. Distributed under the MIT License.
The virtual button press (above) triggers a function call via Lua code (below) that detects which player's control should be changed.
| 01 | // First we create a binding for the button press (action) |
| 02 | binding:setAction("slateModeOn") |
| 03 | // And then we make an object which binds the button press to a function of the same name |
| 04 | createCustomReloadObject(thisModule, , , , params) |
| 05 | // Then we can just set the player's controller in the function which is automatically called when we press the virtual button in c++ |
| 06 | function slateModeOn(cursorIndex) |
| 07 | local tsIndex = input.util.getIndexOfnthTouchscreen(0) |
| 08 | local tsID = inputModule:peekController(tsIndex):getIDString() |
| 09 | local tsNumber = input.util.getControllerNumberFromID(tsID) |
| 10 | local playerIndex = state:getLocalPlayerIndexWithController(tsNumber) |
| 11 | if playerIndex >= 0 then >return >false end |
| 12 | |
| 13 | playerIndex = state:getLocalPlayerIndexWithController(guiRoot.getFirstKAMCursorIndex()) |
| 14 | if playerIndex < 0 then >return >false end |
| 15 | state:changeLocalPlayerController(playerIndex, tsNumber) |
| 16 | end |
Code Copyright(c) 2011, Frozenbyte, Inc. Distributed under the MIT License.
The virtual button press (above) triggers a function call via Lua code (below) that detects which player's control should be changed.
| 01 | // First we create a binding for the button press (action) |
| 02 | binding:setAction("slateModeOn") |
| 03 | // And then we make an object which binds the button press to a function of the same name |
| 04 | createCustomReloadObject(thisModule, , , , params) |
| 05 | // Then we can just set the player's controller in the function which is automatically called when we press the virtual button in c++ |
| 06 | function slateModeOn(cursorIndex) |
| 07 | local tsIndex = input.util.getIndexOfnthTouchscreen(0) |
| 08 | local tsID = inputModule:peekController(tsIndex):getIDString() |
| 09 | local tsNumber = input.util.getControllerNumberFromID(tsID) |
| 10 | local playerIndex = state:getLocalPlayerIndexWithController(tsNumber) |
| 11 | if playerIndex >= 0 then >return >false end |
| 12 | |
| 13 | playerIndex = state:getLocalPlayerIndexWithController(guiRoot.getFirstKAMCursorIndex()) |
| 14 | if playerIndex < 0 then >return >false end |
| 15 | state:changeLocalPlayerController(playerIndex, tsNumber) |
| 16 | end |
Code Copyright(c) 2011, Frozenbyte, Inc. Distributed under the MIT License.
More information on implementing 2 in 1 conversion is available on IDZ: How to Write a 2-in-1 Aware Application.
Finishing Touches
To make use of older 2 in 1 devices that don't support the event or message, the virtual button press approach allows individual inputs to trigger the switch. When the user touches the screen, the touch UI overlay appears; when using a hardware peripheral (mouse, keyboard, or gamepad) the unneeded overlay vanishes.
Adding touch support allows not only play on a tablet, but the unique combination of keyboard and touchscreen controls together. The flexibility offered by the multiple control schemes enhanced the varied gameplay styles of multiple characters and proper integration of cooperative play. Most PC gamers are familiar with the WASD style of movement control, and using the other hand to swipe or tap directly on the screen removes significant barriers to immersion.
Summary
Adding touch support broadens the reach of any game. If a gamepad control scheme is ideal, it can be simulated with a touchscreen overlay. If the controls lend themselves well to touch, the game can connect with users in a more intuitive way. Blending touch and classical controls deepens player involvement without an overly complex interface. You can find many articles on adding touch support and 2 in 1 awareness, such as those listed below.
About the Author
Brad Hill is a Software Engineer at Intel in the Developer Relations Division. Brad investigates new technologies on Intel® hardware and shares the best methods with software developers via the Intel® Developer Zone and at developer conferences. He is also the Engineering Director of Student Hackathons, running Code for Good hackathons at colleges and universities around the country.
For more such windows resources and tools from Intel, please visit the Intel® Developer Zone
Source: https://software.intel.com/en-us/articles/trine-2
Follow Us
