Clicky

Construct 2 Tip #1: Implementing Snapped View State - Jim O'Neil - Technology Evangelist - Site Home - MSDN Blogs

Construct 2 Tip #1: Implementing Snapped View State

Jim O'Neil

Technology Evangelist

E-mail  Twitter  LinkedIn  RSS Feed  About me

Check out my new blog at http:>//codocent.com

Construct 2 Tip #1: Implementing Snapped View State

Rate This
  • Comments 1

This is the first of a short set of blog posts (following up on my article on Construct 2 Starter Kits) in which I want to touch on a few techniques and lessons I learned while building games and applications for the Windows Store using Scirra’s Construct 2. This post specifically covers how I’ve been implementing the snapped view state, which per item 3.6 of the Windows 8 application certification requirements is a must for an application to be accepted into the store.

Snapped view state refers to the docking of one Windows Store application to the right (or left) side of the screen while a second Windows Store application runs along side. Per the requirements: Your app must remain functional when the customer snaps and unsnaps the app.

There is however a bit of leeway with “functional”: take a look at the default experience for the Windows Store app itself below left. Yup, it’s perfectly ok to just put up a logo or some static screen if your app really can’t do anything useful in the amount of real estate provided in snapped mode. What’s not ok, is to have the user experience suffer, such as by truncating the display (below right).

Acceptable snapped view state implementation        Unacceptable snapped view state implementation

In your Construct 2 game, you’re probably using (or should be) the Letterbox scale mode so that your game or application adapts well to the various device sizes and configurations your users may employ. When using that mode with Construct 2 though, the entire screen is scaled, so the dimensions in snapped mode are something along the lines of 320x180, and for most games and applications you’ll build, it’s unlikely the default full-screen experience will translate well.

In the applications I’ve published, I’ve taken a route similar to the Windows Store application and simply provide a logo and some narrative text to let the users know they need to get out of snapped mode to fully experience the application. Below for instance, is what I’m doing for my Twelve Labors of Heracles application:

Snapped view state experience

Each of the starter kits I described in my last post provides an experience similar to this, but if you’re building a new Construct 2 app from some of the additional File>New Templates in the tool, you’ll need to build your own mechanism for snapped view. Doing so isn’t too hard, and you can use the same pattern employed in the starter kits.

Including an event sheet within another If you open up one of the starter kit files, you’ll note it has an event sheet named Windows8Events, and that event sheet is ‘included’ in each of the other event sheets that drive a particular layout in the game. Remember, the user could snap your game while on any screen (layout) you provide, so you need a decent experience for each.

Within the Windows8Events sheet, I take advantage of the built-in Windows 8 plug-in provided with Construct 2 by simply dragging and dropping it onto one of the layouts (you’ll find it under the Platform Specific category in Construct 2’s Insert New Object dialog). Like the Touch plug-in, once you add it, it’s available across the project.

The Windows8 plug-in has a number of events you can use to detect and leverage platform-specific options for Windows 8, like view state, sharing, and in-app purchases. For snapped view, the primary condition to detect is a view state change:

Windows8 plug-in events

Here’s the code for the Windows8Events sheet of one of my apps, with a line-by-line narrative following:

Sample Windows8Events implementation

Line 1 This is a simple check for whether the application (remember it’s HTML5/JavaScript at its core) is running on a Windows 8 device. Strictly speaking it’s not required, since the events that follow will silently fail if the application is not running on Windows 8.
Lines 2 - 5 There are four discrete view states for Windows 8, so when any of those are triggered, an call is made to a function, SetSnappedMode, to make the necessary UI adjustments. The parameter to that function indicates whether you’re transitioning to (1) or away from (0) the snapped view state.
Line 6 Function declaration
Line 7 This branch is called when an argument value of 1 (snapped view) is passed in. In response, there are a few actions that occur:
  1. A “SnappedMode” event group is activated and an “UnsnappedMode” event group is deactivated; more on that just below.
  2. Specific layers in the layout are hidden or shown. You’ll need some sort of convention here across each of your layouts within the game (assuming you “include” this event sheet in each layout), because there is no way to enumerate layers within a given layout.

    In this application, each of my layouts has layers with the specific names “SnappedLayer”, “GameLayer”, and “UILayer”, and “SnappedLayer” is what should show in snapped mode, while the others are hidden. If a layer doesn’t appear in a given layout, that’s a silent failure, so as long as your script addresses the union of all layers across your layouts, you’ll be fine.
  3. Silence any and all audio that's current playing
  4. Pause the game by setting the time scale to 0
Line 8 As you might expect, the processing for coming out of snapped view state is essentially the inverse of what was described above.
Line 9 -10 Set up the SnappedMode event group; in Construct 2, a group is a subset of events and actions that can be enabled or disabled via a single operation (the Set group <name> activated/deactivated action you see in Lines 7 and 8).

This is necessary because even though the layers within your game may be hidden, the elements are still there and can respond to user input events like taps, clicks, and keyboard entry. The SnappedModeGroup you see in the Windows8Events sheet contains the only input events that should be recognized while the app is in the snapped view state, and that’s to try to unsnap whenever the user taps anywhere on the screen in that view.

In response, the TryUnsnap action is executed, and all events within each of the UnsnappedMode groups, which should be present in each of your game layout screens (like below), are now back in play.

Implementing unsnapped mode from within an event sheet

That’s the gist of it. Unfortunately, you can’t test these events within Construct 2 itself, so you will have to export the project and run from within Visual Studio to make sure you’ve covered all the bases.

Join the Conversation
Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post
Read What Other's Think
  • Nice tutorial ever..

    I have some question about metro-plugin-r10 and about the topic related in snap view and  give me a suggest about my apps.

    1. I used construct r132(newest that compaible with window8 apps.

    But I need some event to completed my demo game. Than I try t use the plugin, but After i installed the plugin. And remove some useless file and run in on local/simlator always get propt

    "Unhandled exception at line 77, column 3 in ms-appx://12a280b7-2502-4285-87a8-c198e3606158/index.html

    0x800a1391 - JavaScript runtime error: 'jQuery' is undefined". What wrong with the plugin?

    2. Does newest construct dontn't need plugin anymore for sanp view compatibility?

    3. I have 3 layout that for splash, stage1 and boss.

    Windows layout and splash with the set screen 1366x768.

    Stage1 and Boss are set 8000x2270 for the large maps. How to manage or manipulate it for windows8 and windows phone resolution?

    Best regard...

Page 1 of 1 (1 items)