BACHELOR THESIS
Developing an Interface for a Multi-Touch
Application
Albert Öhrling
2015
Bachelor of Science in Engineering Technology
Computer Game Programming
Lule˚
a University of technology
Bachelor Programme in Computer
Engineering - Thesis
Developing an interface for a
multi-touch application
Author:
Albert ¨
ohrling
Supervisor:
Johannes Hirche
October 20, 2015
Abstract
At Nuiteq, an application is developed using the company’s own Snowflake suite, which allows multiple users to make use of a multi-touch surface to play simulated boardgames. The purpose of this project is to develop an interface for this application. How to present the possible interactions to the users will be examined. Several new features to the application are developed to create a better interface. These include a synchronization zone object to make network transmissions easier, a way to place markers on game objects, a pop-up menu containing relevant functions for a given object, a stack object to handle collec-tions of objects and a content view to easily manage a stack’s contents. This application will only simulate three specific board games, no other games are considered in the development of the interface. The result is a simple, highly usable interface that gives users control over the simulated games.
Sammanfattning
P˚a Nuiteq utvecklas en applikation p˚a f¨oretagets egen Snowflake svit. App-likationen l˚ater flera anv¨andare utnyttja samma multi-touch yta till att spela simulerade br¨adspel. M˚alet med detta projekt ¨ar utveckla ett gr¨anssnitt till denna applikation. Hur man presenterar de m¨ojliga interaktioner som finns f¨or anv¨andarna kommer att unders¨okas. Flera nya funktioner till applikationen utvecklas f¨or att f¨orb¨attra gr¨anssnittet. Dessa inkluderar ett synkroniseringszon-object f¨or att underl¨atta n¨atverks¨overf¨oringar, ett s¨att att placera ut mark¨orer p˚a spelobjekt, en popup-meny med relevant information f¨or ett givet objekt, ett stapel-objekt f¨or att hantera samlingar av objekt och en innehllsgranskare f¨or att enkelt f˚a ¨oversikt ¨over vad en stapel inneh˚aller. Denna applikation kommer bara att simulera tre specifika br¨adspel, inga andra spel har ¨overv¨agts under gr¨anssnittets utveckling. Resultatet ¨ar ett enkelt, anv¨andarv¨anligt gr¨anssnitt som ger anv¨andarna kontroll ¨over de simulerade spelen.
Contents
1 Introduction 1
1.1 Goal and purpose . . . 1
1.2 Limitations . . . 2
1.3 Background . . . 2
1.4 Related work . . . 2
1.5 Social, Ethical and Environmental Considerations . . . 2
2 The Digital Tabletop 4 2.1 Features . . . 5 2.1.1 Companion App . . . 5 2.2 The Games . . . 5 2.2.1 Playing Cards . . . 5 2.2.2 Chess . . . 5 2.2.3 HeroQuest . . . 5 2.3 Game Objects . . . 6 2.3.1 Counter Object . . . 6 2.3.2 Card . . . 6 2.3.3 Document . . . 6 2.3.4 Die . . . 6 2.3.5 Game Piece . . . 6 2.3.6 Game Board . . . 6
3 Design and Implementation 7 3.1 New Features . . . 7 3.1.1 Stack . . . 7 3.1.2 Pop-Up Menu . . . 8 3.1.3 Sync Zone . . . 9 3.1.4 Content View . . . 10 3.1.5 Markers . . . 12
3.1.6 The Side Menu . . . 12
3.1.7 Reset Game . . . 13
3.2 Game Objects . . . 14
3.2.1 Counter Object . . . 15
3.2.3 Document . . . 15 3.2.4 Die . . . 15 3.2.5 Game Board . . . 15 3.2.6 Game Piece . . . 15 3.2.7 Stack . . . 15 4 Results 17 4.1 The New Features . . . 17
4.1.1 Stack . . . 17
4.1.2 Sync Zone . . . 17
4.1.3 Pop-Up Menu . . . 17
4.1.4 Content View . . . 18
4.1.5 Markers . . . 18
4.1.6 The Side Menu . . . 18
4.2 The Game Objects . . . 18
4.2.1 Counter Object . . . 18 4.2.2 Document . . . 19 4.2.3 Dice . . . 19 5 Discussion 20 6 Conclusion 21 7 References 23
Chapter 1
Introduction
Multi-touch surfaces are a common sight today, replacing the older technology that could only handle a single touch at a time[1]. To make proper use of a multi-touch screen, an application has to be developed specifically with this technology in mind. Such applications are what Nuiteq[4] specializes in. At Nuiteq an application is developed using the company’s own Snowflake suite, which allows multiple users to make use of a multi-touch surface to play simu-lated boardgames. All users have to be able to simultaneously use the surface to interact with the simulated games. These games should have the same func-tionality and user friendliness that their physical counterparts have. The fact that the players have to use the same surface for input can cause problems. To solve this, all forms of interaction with the application will be limited to locally interacting with a single object. This means that input can be measured per object; in this way many users can interact simultaneously as long as they do not touch the same object. It is important that the application supports many different features and that the access to these features is not degraded by limitations being set by the access model.
1.1
Goal and purpose
The purpose of this work is to develop the interface for an application on a multi-touch device. All the features that exist in the application will be examined. For each one of them, a solution is presented that prioritizes usability. The final product must not be limited by this focus on usability. The application is a simulation of a table for playing board games. It has a list of features that require an interface for users to access. The objects that exist on the simulated game table will have many different possible interactions. How should the application present which interactions that are possible for a given object? How will users be able to access the different functions? New features will have to be developed to accommodate the solutions.
1.2
Limitations
The application is limited to three specific board games. The interface is de-veloped with these games in mind and no consideration is made towards other use-cases. The actual development of the application and it’s features are of no consideration for this project, with the exception of the application’s interface and usability concerns. Neither will any consideration be made towards the aesthetic aspect of the user interface.
1.3
Background
Large screens with multi-touch capacity are very practical, as they allow mul-tiple users to interact with the same application simultaneously[1]. A problem with this type of application is that the input coming from a user must not interfere with the other users. As an individual, one should not have to care for what other users are doing, with the exception of the purely physical aspect of where one keeps their hands. This suggets some limitations for the users; you cannot rely on certain interactions that are common in surfaces meant for just one user. For example, a context-less double tap is not possible to listen for, as it it would occur constantly when different users tap the surface at the same time. It is also not possible to count a touch outside of an object as being relevant to that object, as such a touch is most likely originating from a different user. This discards conventions such as tapping outside of a menu to close it.
1.4
Related work
An application to play Poker using a multi-touch surface and a set of connect mobile phones was developed by A. Sahmi, T. Dring, P Parvahan, B. Ahrens, A. Schmidt[2]. The application in this project differs from it in that it attempts to create general solutions that can be applied to a diverse set of games, not just Poker.
Tabletop Simulator[5] is a computer game that simulates board games. The Digital Tabletop application differs from Tabletop Simulator in that it focuses on directly simulating the interaction, as if the users were actually playing on a real table.
1.5
Social, Ethical and Environmental
Consid-erations
The application requires users to utilize their own private phones or tablets to make full use of its features. This can be a concern for some, who would rather not have the use of their device be occupied. Playing board games in a digital environment instead of with physical materials can be a boon to the environment, as no physical game materials need to be produced, nor do they
need to be transported. However, it has to be pointed out that the kind of multi-touch screen required for the digital tabletop application is not yet a common item for private use. This means that attempting to replace physical board games with digital would be expensive for the users.
Chapter 2
The Digital Tabletop
The functions of the Digital Tabletop application are specified in this chapter.
2.1
Features
The application is meant to be as close to real board games as possible. The simulation consists of an empty space that represents the table. The table is viewed from a top down perspective, as the application is intended to be used on a horizontal surface at table height, with a group of players surrounding it.
2.1.1
Companion App
When playing board games, it is very often necessary to keep some information hidden from the other players. For example, when playing Poker, you do not want anyone else to see your hand of cards. This interaction is very complicated to emulate on a single screen, so to enable such gameplay, the digital tabletop has a companion app. This app runs on a tablet or phone and can connect to the digital tabletop (henceforth referred to as the table). When the app is connected to the table, it can be sent game objects from the table to store on that device. This gives the players an option of true privacy, as long as they own a compatible hand-held device to utilize.
2.2
The Games
Three games were chosen as use cases for the digital tabletop.
2.2.1
Playing Cards
Regular playing cards are the only materials needed to play thousands of games. Other types of cards are common in many different board games. For this reason, simulating cards is a priority of the Digital Tabletop.
2.2.2
Chess
Chess is a very old game with millions of players worldwide. It is commonly thought of as the defining board game and it’s core mechanics of pieces moving a board are indeed common in many modern games. Therefore, if the digital tabletop can simulate chess, it will have the necessary structure to simulate many other games.
2.2.3
HeroQuest
HeroQuest is a board game from 1989 created by Stephen Baker. Players each take control of a character and go exploring a dungeon together, fighting mon-sters and finding treasure. The game was chosen to be included because there was a need for a complex game; one that included many different types of game material.
2.3
Game Objects
The games are composed of a collection of game objects. Game objects come in different types; each type has different functionality. General object types are used, which can build many different types of games. These are multi-touch interactable objects; users can move them around with their hands.
2.3.1
Counter Object
Counter objects are numbers that track a value. Users can change the value of the counter. This allows them to utilize counters to keep track of properties of the game. An example would be keeping track of a character’s health points in HeroQuest.
2.3.2
Card
Cards are simple objects with few unique features. They have two sides and depending on the context, it may be necessary to show either. In the real world, cards are thin, flat and often put together into stacks. It must be possible to simulate this behavior.
2.3.3
Document
Documents come in the PDF format, which means that they can contain any form of written and visual content. Documents can have several pages, which means that users need controls to scroll through the document.
2.3.4
Die
A die can be rolled; displaying an effectively random side.
2.3.5
Game Piece
Game pieces are the simplest objects. They only demand the basic functionality of a standard chess piece; the ability to move it around on a board.
2.3.6
Game Board
A game board is another surface that is placed beneath the rest of the ob-jects. The purpose of the board is usually the placing of game pieces in specific locations on it.
Chapter 3
Design and Implementation
The process of developing an interface for the application is outlined in this chapter.
3.1
New Features
To facilitate the accessibility of the application, new features had to be added.
3.1.1
Stack
Figure 3.1: A stack of cards. The num-ber is a counter that shows how many objects that are in this stack.
Keeping a large amount of game ob-jects on the table can quickly get messy. It also creates problems with managing the board state. For ex-ample, if a few objects are placed on top of each other, they can no longer be moved as one unit, like they could in real life. Instead, only the top-most card is moved. This makes some common use-cases, such as a deck of cards, very hard to simulate. To solve this problem, a new type of game ob-ject is added, the stack. A stack is a collection of other game objects that have been moved off the table, they are now kept only inside the stack ob-ject. Only the top object of the stack is visible to the users, the rest are hid-den beneath. Objects that are in a stack retain all of their usual proper-ties, such as being flipped or having
markers attached to it. The only
ex-ception to this is that objects in a stack are transformed uniformly. To avoid confusion, stacks are given a background to distinguish them from singular ob-jects. Only certain objects can be placed in a stack; cards, game boards and game pieces. Out of these types, objects may not be mixed. A stack may only contain one type of object. Objects can be dropped on top of a stack to place that object into that stack. Drop a stack on top of another stack to merge the two stacks. If a stack is pinned, attempting to move it will instead grab the top card and move it.
Figure 3.2: A device connects to the ta-ble and this sync zone is created. The color is chosen randomly.
3.1.2
Pop-Up Menu
All game objects are based on the same basic object and behave in the same way in many cases. However, most of the types of objects need to have their own functions. For exam-ple, a die needs a function to roll that die. It makes sense to gather all these functions in a unified interface. That way, everything that is outside of this interface will be the same for all game objects. Any differences can also eas-ily be presented to the user through this interface. The implementation of this interface is a menu that is local to a game object. The controls in the
menu will be different, depending on which type of object it belongs to. All the controls in the menu affect that object only. The menu will pop-up
when a user taps any game object. A tap is defined as a near zero length touch that lasts no longer than a tenth of a second. Pressing any button in the pop-up menu will close the menu. The menu can also be closed by tapping the object again. Some users may expect to be able to tap outside of the object to close the menu, but this is not possible on a multi-touch screen that several users are interacting with. The menu will appear around the point that was tapped. An exception is made if this would cause the menu to end up outside of the screen, then the menu is moved to appear completly inside of the bounds of the screen. The menu is laid out in a circle around the tapped point. This gives the most convenient and quick access to every button in the menu[3]. The buttons are sorted with default controls first, followed by any controls that are unique to that object.
3.1.3
Sync Zone
There is a need for a control for sending objects to a device which is running the companion app. This control needs to allow users to specify exactly which device they are sending the object to. The first attempt at solving this was to add a control for each object, which allows users to send that object to a connected device. This was implemented as a button in each object’s pop-up menu. This control became very unwieldy, as there was no practical way for users to specify which device they wanted to send to, unless a button was presented for each connected device. To solve this, a new type of game object was added, the Sync Zone. This is a special object that cannot be manually created or destroyed. Each sync zone that exists is created when a device connects to the table. It is linked to that device and will be removed when it disconnects. When an object is placed on top of the sync zone, that object is sent to the linked device. This gives users control over sending game objects. Likewise, when an object is sent to the table application from another device, the object will appear on top of that device’s sync zone. The sync zones themselves, despite being game objects, cannot be sent to another device.
3.1.4
Content View
The content view exists to quickly display the content of a stack without break-ing the stack open. A new window is opened in which some of the objects are rendered. The user can scroll the content view by sliding up and down. Scrolling causes the content view to display other objects, letting user browse through all of the objects in the stack. If the user slides the content view left or right an object will be grabbed from the stack. The object that is picked is naturally the one that the user was sliding their finger over in the content view. If a user drops an object on the content view, the object will be inserted into the stack at the position where it was dropped. The content view was set up to open up po-sitioned diagonally from the stack object. The direction of its offset is towards the center of the board. This avoids the issue with the content view ending up outside of the screen. It also means that the content view cannot completely cover the visible part of an object near the screen’s edge, as long as the case of an object begin stuck too far into a corner is prevented. Always opening the content view in the direction of the center creates a consistent behavior. The scroll area of the content view is always aligned along the table’s y axis. This will not change no matter where the content view is opened. However, to accommodate the opening of a content view from multiple directions, the area will be aligned towards the side of the table that is the closest.
3.1.5
Markers
Figure 3.5: Two markers were placed on a card.
Some board games demand that play-ers make note of the progress on a scorecard. This is the case in Hero-Quest, where users must mark their character sheet to keep track of, for example, how much damage their character has taken and what loot that has been acquired. To enable this behavior, markers can be placed on game objects to signify something. Markers stick to the game objects they are placed on, they will update their relative position, rotation and scale accordingly. There is no limit to the number of markers that can be placed on a single object. To facili-tate the addition of new markers, a button is added to the pop-up menu of all objects. This button attaches a
marker to an object. To move a marker around, just touch it and drag it. This will move the marker and not the object it is attached to. In order to remove a marker, the user only needs to drag it outside of the object’s bounds and drop it.
3.1.6
The Side Menu
One final addition has to be made, there is a need for a way to easily create new game objects. Here, a solution was sought that closely resembled reality. When playing a physical board game, game materials would be taken out of the box that the game came in. In the digital board game, this is represented by a menu containing all necessary material used to play the game. The difference is that the menu only has to contain one of each item, whenever a user picks an object, a copy of it is created. In order to not obscure the play area unnecessarily, the menu is hidden by default and can be brought forth by pressing a button at the edge of the screen. To close the menu, this button must be touched again. When it appears, it is locked to that edge of the screen, only taking as much screen space as it needs to to show all the game objects. To further reduce the menu’s need for screen real estate, it is split into tiers. The first tier contains object types. Nothing can be picked from this menu, rather, all the controls select an object type and open another menu tier for objects of that type. The next tier contains all the objects of the type that was selected in the first. Finally, a third tier exists to allow users to create a single card out of a deck.
Figure 3.6: This menu displays the game pieces we can create.
3.1.7
Reset Game
Users of the application will need a control for resetting the table to it’s default state, even if this function just clears the table. The key consideration here is where such a feature should be placed. The side menu only contains object creation, so this feature could be misplaced there. Placing such a control in a up menu for single object makes little sense, as all other buttons inthe pop-up menu only affects the object that was tapped. In Nuiteqs[4] snowflake suite, a corner menu handles a number of general controls available in any application. This corner-menu is where the Reset Game button was added.
3.2
Game Objects
Any special functions that a game object needs are added to the pop-up menu for that object. By default, interactible objects in Nuiteqs[4] Snowflake suite are resized by touching with two finger and moving them closer or further from each other. This is closely related to the controls for rotating an interactible, which is done by touching with two finger and twisting. But when playing a board game, it is very annoying if the pieces begin to change size when one tries to rotate them. Because of this, game objects have their size locked. In order to alter the size of an object, a control was added to the popup menu for all objects. This button puts the object into a mode where it can be resized. While in this mode, the object cannot be rotated. Pressing this button again will return the object to its default state. It can be useful to prevent any transformation being applied to an object, including moving it. To not overload the menu with too many different toggles and states, there is just one button that locks and unlocks movement, scaling and rotation. Objects can be removed from the table. This control is also accessed through the pop-up menu. It is not possible for game objects to be outside of the screen space. If an object’s center ever ends up outside of the screen it is forced inside again. This keeps objects from dissappearing off the table, while allwing users to partially hide object to save table space.
When placing different types of game objects on a real table, we tend to do so in a certain order. We do, for example, most of the time put cards and game pieces on top of game boards. In the application, we simulate this by ordering the game objects by type. When game objects are ordered, they are rendered in reverse order, causing some object to always render on top of other. This order is used for touch input too. If a user touches a game piece that is on top of a game board, only the game piece will be touched. This is a must since we would otherwise be unable to separate objects. This order of objects is as follows:
• Counter objects • Game pieces
• Stacks of game pieces • Cards
• Stacks of cards • Documents • Game boards
• Stacks of game boards • Sync zones
3.2.1
Counter Object
Counter objects are given two new menu buttons, one to increase and one to decrease the value. Because the user is likely to press these buttons several times in a row, they do not close the menu.
3.2.2
Card
Users can flip the cards to show the other side. A new button is added to the pop-up menu of cards to control this function.
3.2.3
Document
To enable scrolling through the document, the most convenient thing is to keep it on a whole page and then let users turn to the next or previous page. Two buttons for this are added to the document’s pop-up menu. It may be necessary to scale up a document to quite large proportions in order to properly read it. For this reason they were kept low in the render priority list.
3.2.4
Die
The action to roll the die has to be added to the menu, as all direct interaction with a die is occupied by other functions.
3.2.5
Game Board
Game boards are functionally very similar to game pieces and cards, but they have one important distinction. When another object is placed on top of a game board, that object sticks. It will not continue sliding as it usually does. Since game boards are flat, double-sided objects, it is practical to allows users to treat them like cards and flip them.
3.2.6
Game Piece
Game pieces handle exactly like a normal interactible, with the exception that they can be stacked. This is necessary because some games, like HeroQuest, have a lot of game pieces of the same type. Managing these are much easier if the players only have a stack of pieces of each object, from which they can grab a game piece when they need it.
3.2.7
Stack
In order for stacks to be able to simulate a deck of cards, it has to be possible to shuffle the stack. This function was added to the pop-up menu of the stack. The user also needs to be able to look at the stack’s contents. This will be achieved with a content view. When the user presses the View Content button, the content view is opened for that stack. Finally, we have to be able to create
stacks. To do this, all objects that can be stacked gets a menu button to create a stack that contains only that object.
Chapter 4
Results
The final result of the interface is described in the chapter.
4.1
The New Features
4.1.1
Stack
The implementation of the stack closely fulfills the needs that the application had.
4.1.2
Sync Zone
The Sync Zones work very well for sending and receiving objects. However, they have one crucial problem: They demand a lot of screen space. In order for a sync zone to be of functional use, it has to be large enough for users to comfortably drop items on top of it. But this means that when many players connect their devices to the table, the sync zones start to consume a lot of the available screen estate. This problem is noticeable already with 4 connected players.
4.1.3
Pop-Up Menu
The big question that had to be answered was how the varying functions of different game objects should be presented. This came to be solved by the pop-up menu. While the menu does a good job of delivering these controls to the user, it has some inherent problems. First, the buttons in the menu has to be aligned by some axis. The digital tabletop however, is intended to be used by several different users standing around a table and thus viewed from different angles. Whichever way the menu buttons are aligned, they will be upside down, or sideways for most of the users. This makes it harder for users to read the icons in the menu and understand what they do. Naturally, it is not possible to determine which person touched an object to open a menu, or where that person
is standing relative to the multi-touch surface. If it was, a solution could be to always open the menu aligned with the view direction of the user who opened it. Another issue is that since different game object types do not have the same amount of buttons in their menus, the layout is going to be different. This is problematic because it means that default functionality, such as removing an object, will not always be in the same place relative to where the menu was opened. This forces the user to constantly evaluate the menu they just opened.
4.1.4
Content View
The content view has a similar problem to the pop-up menu in that is has to be aligned. But the content view has to not only be aligned visually, but it also has to determine a scroll direction relative to itself. If the alignment is never changed, then some users will have to access the content view as if it was on it’s side, from their perspective. In the solution presented here, the content view does not change it’s alignment, so these problems remain.
4.1.5
Markers
The markers fulfill their purpose, but the feature needs to be expanded to fill all use cases. Users need to be able to place several different types of markers, with different images.
4.1.6
The Side Menu
Creating objects from the side menu is easy and intuitive. One problem that remains is that game materials in the menu are not appropriately separated by game. This means that both chess boards and board for HeroQuest are found in the same sub menu.
4.2
The Game Objects
4.2.1
Counter Object
One problem with counter objects is that they do not have a control for changing the value by more than one. This is particularly problematic when the players want to start the game with one or several counters that are set to relatively high value, such as 50. It will take some time to achieve this initial setup. Two solutions for this were considered, but could be implemented because of time restrictions. Firstly, holding down the buttons for changing the value could rapidly change it, after a small delay. Secondly, it could be possible to create counter objects that default to other values, such as multiples of 10.
4.2.2
Document
Documents end up having the crucial problem that they just take up too much space. A typical PDF document demand such a high resolution to be read that it will essentially cover the table. During the project, no appropriate method to deal with this problem in the interface was developed. The most convenient solution for users is to only read their documents on the companion app. Another option is to create more suitable PDF documents that contain more easily readable text at lower resolutions.
4.2.3
Dice
Some users may express disappointment in not being able to handle a die the way they would in a physical game: by picking it up and throwing it. And indeed, not having this feature is a shortcoming of an application that tries to closely model reality. However, the implemented solution has some distinct advantages. For example, the dice is guaranteed to stay in one place and never fall off the table.
Chapter 5
Discussion
The outstanding issue with making an application on a touch surface is that users only have two dimensions to interact with the application in. This means that such an application is limited in the way it display the board; it has to be two dimensional in a way that fits the screen. This may seem like a negligible difference for board games, at first. It is after all, just two dimensional cards on a two dimensional table. But in reality, cards still have some thickness, a property that we can interact with. If a small stack of cards is placed on a table, we can separate them into two piles by only pushing on the edge of some of them. Such interactions cannot be done on a digital table, we can only touch the top side of the card and move it around by that. Mastering this limitation is the key to creating a good interface for the digital table, but even then, we must expect users to drop any expectation that the experience can ever be exactly the same.
Chapter 6
Conclusion
The project to create an interface for the Digital Tabletop application was a success, with the exception of a few concerns. The Digital Tabletop exists in a complete state, with all the necessary controls in place. The six basic types of game object contained in the application were given interfaces that allowed their function to be easily accessed. New features were added as needed to provide the application with the level of control users should expect. However, no user testing could be performed, which undermines the results. During such testing, more concerns could arise. HeroQuest, in particular, could contain problems, but the game is too complex to make any additional guesses without proper testing. An overarching problem is that the nature of the game materials is creating problems. For example, documents being hard to read at low resolu-tions, or game pieces not being designed to be displayed from a top down angle. Future work in the area should focus on the design of digital game material that avoids these issues and better facilitates the strengths of the platform.
Chapter 7
References
[1] Bill Buxton, Multi-Touch Systems that I Have Known and Loved, Microsoft Research, Version: Feb 12, 2009, Original: Jan 12, 2007
[2] A. Sahmi, T. Dring, P Parvahan, B. Ahrens, A. Schmidt, Poker Surface: Combining a Multi-Touch Table and Mobile Phones in Interactive Card Games, Pervasive Computing Group, University of Duisburg Essen, Septem-ber 15 - 18 2009
[3] J. Callahan, D. Hopkins, M. Weiser, B. Shneiderman, An Empirical Com-parison of Pie vs Linear Menus, Computer Science Department, University of Maryland, 1988
[4] http://nuiteq.com/company/about/, Natural User Interface Technologies AB, 22 May, 2014
[5] http://berserk-games.com/tabletop-simulator/, Berserk Games, 22 May, 2014
