Personalised Semantic User Interfaces for Games

User interfaces provide a means for players to interact with games. A successful user interface for games should be user-friendly, provide enough information for users to effortlessly play the game and provide all the necessary behaviour for users to have an immersive experience. User interfaces utilise elements such as text, buttons and images to provide users the means to interact with the game. When designing user interfaces, it is not just about the placement of elements on the screen but most importantly it is about providing the best user experience players could experience in a game and to provide the best interaction between the user and the game. User interfaces should provide: (1) clear interfaces and should avoid ambiguity that might cause confusion to players as to how to navigate through the game; (2) must be concise without overloading the interface with too many user interface elements ending up with interfaces tedious to use; (3) fast responsive interfaces; (4) consistent feel throughout the game; (5) aesthetically attractive to provide players an enjoyable experience; and (6) efficiency by allowing the players to perform tasks in a reasonable time.

Game User Interfaces can be categorised as follows: (1) diegetic interfaces are those interfaces included in the game world whereby players access such interfaces through their game character; (2) non-diegetic interfaces are those interfaces rendered outside of the game world (i.e. overlaid on top of the game) and is only accessible to the players (rather than accessed through the player’s game character); (3) meta interfaces are representations that can exist in the game world such as effects rendered on the screen to indicate low health and are normally represented two dimensionally; and (4) spatial interfaces are three dimensional elements that can exist or not in the game world.

Creating video games that are market competent costs in time, effort and resources which often cannot be afforded by small-medium enterprises, especially by independent game development studios. As designing and developing user interfaces for games are labour and creativity intensive, our vision is to reduce development effort and enhance design creativity by automatically generating novel and semantically-enriched user interfaces for games from Web sources. In this paper we envision a user interface generation that extracts information directly from the Web such as extracts user interface elements or images that are freely available on the Web. Following a semantic-based user interface generation approach not only can reduce the time and cost of user interface creation for games but also directly contribute to web-informed yet unconventional game design.

Web content is dispersed over the Internet in the form of blogs, microblogs, forums, wikis, social networks, review sites, and other Web applications which are currently disconnected from one another. The content and datasets created by these communities all contain information which can be used to generate or reuse user interfaces in games, but are not easily discoverable. For instance, the Web contains many user interface elements that can be reused to generate user interfaces for games but these are dispersed and not easily discoverable. The emerging Web of Data trend [5], where datasets are published in a standard form for easy interlinking, enables to essentially view the whole Web as one massive integrated database. Nevertheless, user interface information is still not enriched with meta-structures that could be used both on the Web and also in games. With such rich meta-structures that add more meaning to content, this would enable Web content to be reused to generate user interfaces for games. Moreover, the representation of semantically-enriched and semantically-interlinked user interfaces would enable game generators to infer how content can be interacted within the game world without having to rely on software development procedures that require laborious annotation of how each entity can be interacted within the game.

During the last years we have assisted to the growth of Web applications using or collecting data on their users and their behaviour in order to provide adapted and personalised content and services. This caused the need for exchange, reuse, and integration of their data and user models. Games can benefit from these user models to provide a better player experience by tailoring the game according to the player’s preferences. Specifically, user interfaces in games such as menus and heads-up displays (HUDs) can be automatically customised based on user preferences without the user having to manually customising these himself/herself. Moreover, having user interface preference models in a standard format, this would enable these models to be interoperable amongst different games such that games would automatically adjust interfaces based on these unified standard user preference models and would not require users to setup their preferences in each game. With semantically-enriched user interfaces, these could be interlinked with user preferences so that games could automatically generate personalised and customised user interfaces for players.

In this paper we present the Game User Interface Ontology (GUIO)^{Footnote 1} – a light-weight vocabulary for formally defining user interfaces in digital games, and the Player User Interface Preference Ontology (PUIPO)^{Footnote 2} – a light-weight vocabulary for formally defining player’s user interface preferences in digital games. Through these ontologies, personalised user interfaces could be automatically generated for games.

The remainder of this paper is as follows. Section 2 offers core background information about the Web of data and Sect. 3 reviews current work on semantics in games especially for semantically defining user interfaces for games. Section 4 presents a detailed explanation of the Game User Interface Ontology (GUIO) and Sect. 5 presents a detailed explanation of the Player User Interface Preference Ontology (PUIPO). Section 6 concludes the paper by providing an overall discussion about the future steps of this work.

The Web of Data is evolving the Web to be consumed both by machines and humans whereas the traditional Web resulted to be for human consumption only. Indeed, machines cannot process additional meaning from the content found in Web pages since they are simply text and similarly from the non-typed links which do not contain any additional meaning about the relationships amongst the linked pages. Therefore, the Web of Data provides various open data formats which have emerged from the Semantic Web.

2.1 The Semantic Web

The Semantic Web [4] provides approaches for structuring information on the Web by using metadata to describe Web data. The advantage of using metadata is that information is added with meaning whereby Web agents or Web enabled devices can process such meaning to carryout complex tasks automatically on behalf of users. Another advantage is that the semantics in metadata improved the way information is presented, for instance merging information from heterogeneous sources on the basis of the relationships amongst data, even if the underlying data schemata differ. Therefore, the Semantic Web encouraged the creation of meta-formats to describe metadata that can be processed by machines to infer additional information, to allow for data sharing and to allow for interoperability amongst Web pages. The common format and recommended by W3C for Semantic data representation [3] is the Resource Description Framework (RDF)^{Footnote 3}.

2.2 Resource Description Framework (RDF)

RDF is a framework that describes resources on the World Wide Web. Resources can be anything that can be described on the Web; being real-world entities such as a person, real-world objects such as a car and abstract concepts such as defining the concept of game review scores. RDF provides a framework for representing data that can be exchanged without loss of meaning. RDF uniquely identifies resources on the Web by means of Uniform Resource Identifiers (URIs). Resources are described in RDF in the form of triple statements. A triple statement consists of a subject, a predicate and an object. A subject consists of the unique identifier that identifies the resource. A predicate represents the property characteristics of the subject that the resource specifies. An object consists of the property value of that statement. Values can be either literals or other resources. Therefore, the predicate of the RDF statement describes relationships between the subject and the object. If a triple had to be depicted as a graph, the subject and object are the nodes and the predicate connects the subject to the object node. The set of triples describing a particular resource form an RDF graph.

RDF data can be queried by using an RDF query language called SPARQL^{Footnote 4}. SPARQL queries take the form of a set of triple patterns called a basic graph pattern. SPARQL triple patterns are similar to RDF triples with the difference that in a SPARQL triple, each subject, predicate and object can be bound to a variable; the variable’s value to be found in the original data graph. When executing a SPARQL query, the resulting RDF data matches to the SPARQL graph pattern.

Moreover, the RDF data may require more meaning to describe its structure and therefore, an RDF vocabulary modelled using the RDF Schema (RDFS)^{Footnote 5} can be used to describe the RDF data’s structure. Apart from vocabularies, RDF data may pertain to a specific domain which its structure needs to be explicitly defined using ontologies modelled by RDFS and/or OWL 2^{Footnote 6}. For example, ontologies may describe people such as the Friend of a Friend (FOAF)^{Footnote 7} ontology or may describe information from gaming communities to interlink different online communities such as the Semantically-Interlinked Online Communities (SIOC)^{Footnote 8} ontology.

2.3 Linked Data

As mentioned previously, when describing a particular resource within a graph, a URI is assigned to that resource which can be referred to in other graphs using that particular URI. For instance, if a particular resource represents a person within another graph that describes information about that person, the person’s (resource) URI can be used for example when describing that s/he is the creator of a game review which is described in another graph. Hence this makes it easy to link data together from different datasets and thus creating Linked Data^{Footnote 9}. Datasets which are easily accessible are linked forming the Linking Open Data (LOD) cloud^{Footnote 10} which forms part of the Web of Data. In order to publish data in the LOD cloud, it must be structured adhering to the Linked Data principles as stated in [9] and the Data on the Web best practices as stated in [8].

The benefit of linking data is that links amongst data are explicit and try to minimise redundant data as much as possible. Therefore, similar to hyperlinks in the conventional Web that connect documents in a single global information space, Linked Data enables data to be linked from different datasources to form a single global data space [9].

Semantics in games is still in its infancy and perhaps the closest attempt at using structured real-world data in games is the Data Adventures project [1, 2] which uses SPARQL queries on DBpedia to discover links between two or more individuals: the discovered links are transformed into adventure games, with entities of type “Person” becoming Non-Player Characters (NPCs) that the player can converse with, entities of type “City” becoming cities that the player can visit, and entities of type “Category” becoming books that the player can read. The advantages of using rich semantic information to automatically generate games are numerous [15] as more complex, open-world, non-linear, games incorporating very rich forms of interaction are possible (i.e. authentic sandbox games). Current work in using semantics in games focuses on the use of semantic information to generate game worlds or to describe interactions with game worlds such as the work in [10, 11, 16]. Although these provide useful insights in generic semantic models that describe interactions with game worlds, they do not offer vocabularies for describing game content such as user interfaces and they neither provide a generic approach for reusing Web content to generate user interfaces for games.

Attempts in game ontology creation are relevant to our approach, hence, we outline some key game-based ontologies currently existent. The Game Ontology Project [17] is a wiki-based knowledge-base that aims to provide elements of gameplay. However, this project does not take into consideration game user interfaces. Moreover, it does not provide a vocabulary to be consumed by data described in RDF which could make it potentially useful for game user interface generation. The Digital Game Ontology [6] provides a general game ontology by aligning with the Music Ontology, and the Event and Timeline ontology, to provide concepts that describe digital games. However, the vocabulary is not available and in this regard, it is unclear what game concepts this vocabulary provides. The Ludo ontology [13] provides concepts that describe different aspects of serious games, however, it does not provide detailed concepts for describing game user interfaces. The authors in [7] provide a generic ontology for defining RPG games and do not provide detailed concepts to describe user interfaces for games. Finally, the Video Game Ontology (VGO) [12] provides concepts for defining interoperability amongst video games and the Game2Web ontology [14] focuses on linking game events and entities to social data. Although these vocabularies are useful for describing several aspects of game information, the ontologies are still limited to specific features and hence do not provide features for describing detailed user interface information for games.

Our ontology was created since to our knowledge no ontology exists to describe user interfaces for games and no ontology exists to describe preferences for customising user interface in games.

Overview of the Game User Interface Ontology (GUIO)

Full size image

The Game User Interface Ontology (GUIO)^{Footnote 11} (illustrated in Fig. 1) provides a light-weight vocabulary for formally defining user interfaces in digital games. The process in modelling this ontology involved examining user interfaces in 100 video games from different genres, and common features were extracted resulting in the creation of this ontology.

Game User Interfaces are defined using the main class guio:GameUI. An instance of this class represents formal descriptions of different user interface elements used within a game. These formal descriptions can be used to drive a game engine to generate a game’s user interface either at design time or at run time, depending on how the user interface is implemented within the game. These elements can be used or extended by other video game user interface descriptions. Although this ontology is designed for video games, these element descriptions could also be used for generating user interfaces in software artefacts.

Games are made up of different screens each of which have a specific purpose, for example an options screen provides various settings through which a user could configure and setup a game according to his/her preferences, and a map screen shows the location of a player’s character within a particular level. Each screen contains game user interface elements that provide contextual information and/or means of interaction through which a player can interact with a game. Screens can formally be defined using the gvo:Screen class (described in detail in Subsect. 4.1) and each screen may contain one or more game user interfaces defined by the guio:GameUI class. Instances of the guio:GameUI class may contain one or several HUD (Heads-Up Display) elements defined by the guio:HUD class (explained in Subsect. 4.2) which contain one or several UI containers defined by the guio:UIContainer class (explained in Subsect. 4.3). Instances of guio:UIContainer contain one or several UI elements defined by the guio:UIElement class (explained in Subsect. 4.4). UI elements are linked with actions that define events and methods through which a user could interact with a game. Instances of Actions are defined by the guio:Action class (explained in Subsect. 4.5). In summary, games contain screens that may contain one or several game user interfaces that act as containers for HUDs. HUDs serve as placeholders for one or more UI containers that group one or more UI elements through which a player could interact with a game.

This section provides a comprehensive description of classes and properties for defining game user interfaces.

4.1 Screen

Games are made up of several screens each containing different user interface elements that a user could interact with within a game. These screens are defined as instances of the gvo:Screen class and each screen serve a specific purpose within a game. The gvo:Screen class is part of the Game Visual Ontology (GVO)^{Footnote 12}– a light-weight ontology for defining different visual elements within a game. The following are screens (not exhaustive) that are most commonly found in all games and these are defined as subclasses of the gvo:Screen class:

• gvo:License screen provides information about the end-user license of a game, i.e. who owns the copyright of the game and what rights or permissions a buyer of the game has. The user interacts with this screen by reading the license information and agreeing to the license agreement.

• gvo:Splash screen normally contains a poster-like art image of a game, a logo of the publisher and/or developer, and the current version of the game. This screen normally appears when a game is launched.

• gvo:Loading screen provides some type of animated graphic indicating that the game is loading.

• gvo:Title screen appears after the game is loaded and normally contains the title of the game, a graphic art in the background and a player needs to press either a specific key or any key to load the main menu of the game. Some games do not wait for any user input and provide a cutscene instead or even other games go straight to the main menu screen.

• gvo:MainMenu screen provides a player with several options to choose from before commencing the game. This menu typically contains: choose or create a player name, continue or change player, log in, options, tutorials, settings, credits, cutscenes, scores, and any other option the game provides a player to configure, setup and customise the game.

• gvo:Instructions screen normally contain tutorials on how a player can play the game.

• gvo:Options screen provides players to configure or customise the game and normally include: adjust sound, adjust graphics, adjust playing speed, adjust performance, restart the game, change playing modes, change players, access other levels, access tutorials etc.

• gvo:Settings screen is the same as the gvo:Options screen since in some games the gvo:Options screen is called gvo:Settings.

• gvo:Cutscene screen provides an in-game cinematic or short animation or short movie that is not interactive and breaks-up the gameplay. Cutscenes normally adds more context to the narrative of the game.

• gvo:Scene screen represents the environment and a unique level of a game.

• gvo:Map screen displays a map of the current level or a map of the whole game world.

• gvo:Pause screen pauses the game and provides several options to a player such as return to the game, restart the mission or level or game, save the game, load a game, return to the main menu or exit the game.

• gvo:HighScores screen provides a table with all the high scores achieved in a game by one or several players.

• gvo:Credits screen provides a list of all the cast and crew involved in making the game.

• gvo:Exit screen provides a screen prior to closing the game for example whether the player is sure to exit the game, to save the game before closing etc.

The gvo:Screen class contains the following properties that are related to the classes and properties defined by the Game User Interface Ontology.

• gvo:hasScreenTransform specifies a transform of a screen defined by the guio:Transform class (described in Subsect. 4.6). This defines a position, rotation and scale of a screen relative to the global coordinates of a game.

• gvo:hasScreenAction specifies a generic action defined by the guio:Action class (described in Subsect. 4.5) that can be performed within a screen but are not bound to any UI element actions – i.e. actions over and above the actions bound to UI elements.

• gvo:hasScreenGameUI specifies instances of game user interfaces defined by the guio:GameUI class provided within a specific screen through which a player can interact with a game. Screens can be linked to one or several Game UI instances.

• guio:width specifies a width dimension of a screen in pixels.

• guio:height specifies a height dimension of a screen in pixels.

4.2 HUD (Heads-Up Display)

The HUD (heads-up display) provides a means by which several pieces of information is provided to a player in a visual form as part of the game’s user interface. Instances of guio:GameUI class may contain one or several HUDs defined by the guio:HUD class. The guio:GameUI class contains the guio:hasHUD property that specifies a guio:HUD instance. Instances of the guio:HUD class provide several game user interface elements that provide means for a player to interact with a game or provide information about aspects of a game to a player. This information, for instance, includes (but not limited to) the health status of a player’s character, the current weapon selected, the amount of ammunition left etc. Each piece of information is defined as an instance of a subclass of the guio:HUD class. The subclasses – the different types of HUD information – include the following (not exhaustive):

• guio:Health displays the current health of a player’s character, of other characters such as allies or opponents, or the health of every unit visible on screen in real-time strategy games.

• guio:Lives displays the amount of lives a player’s character has left or other characters have left.

• guio:Time displays either the time left for a player to complete a task or the time elapsed for a particular task, or the in-game time system in-built within a game.

• guio:Weapon displays the current weapon selected and/or the available weapons a player’s character can use.

• guio:Ammunition displays the available amount of ammunition a player’s character has.

• guio:Inventory displays the available objects and items which a character carries after the character has either picked up or purchased during the game.

• guio:Capability displays available gameplay options that a player can access during gameplay such as spells.

• guio:Menu displays a menu with options such as to change settings or exit.

• guio:GameProgression displays a player’s current gameplay progression for example the current game level.

• guio:Speedometer normally a gauge displayed when a player is using a vehicle to measure the speed of a vehicle.

• guio:Tachometer normally a gauge displayed when a player is using a vehicle to measure the revolutions per minute.

• guio:Reticle displays markings of a sighting device such as a scope.

• guio:Cursor displays the mouse pointer in a game.

• guio:Crosshair displays an indication where the character is aiming at.

• guio:Stealthometer displays the awareness level of enemies towards a player character’s presence (normally used in stealth games).

• guio:Score the player’s current score.

• guio:Money the amount of money a player has within the game’s economy system.

• guio:CharacterLevel displays the current character’s level (of experience).

• guio:ExperiencePoints displays the amount of experience points the character currently has.

• guio:Radar displays a radar that show’s a player’s surroundings and the positions of objects, vehicles and enemies.

• guio:Compass displays a navigational instrument that aligns itself with the game world’s magnetic field and indicates where the character is heading. Some games use a compass to guide a player towards the next objective.

• guio:QuestArrow are markers that indicate the location of quests.

• guio:MiniMap displays a small, simplified version of a larger game map.

• guio:ContextSensitiveInformation display important contextual information or messages when required.

The main properties of the guio:HUD class include the following:

• guio:hasHUDAction this defines a general action bound to an instance of the guio:HUD class defined by the guio:Action class (described in Subsect. 4.5).

• guio:hasHUDUIContainer defines a container for one or more HUD elements and is defined by the guio:UIContainer class (described in Subsect. 4.3). HUDs can contain one or several UI containers.

• guio:hasHUDTransform specifies a transform of a HUD defined by the guio: Transform class (described in Subsect. 4.6). This defines a position, rotation and scale of a HUD relative to a screen’s local coordinates within a game.

• guio:hasHUDType specifies how a HUD is displayed in a game and is defined by the guio:HUDType class. The guio:HUDType class consists of the following types defined as subclasses: (1) guio:Diegetic specifies that a HUD instance is included in the game world whereby players access HUD instances through their game character; (2) guio:NonDiegetic specifies that a HUD instance is rendered outside of the game world (i.e. overlaid on top of a game) and is only accessible to players (rather than accessed through a player’s game character); (3) guio:Meta specifies that a HUD instance is rendered as effects on a screen for instance blood splatter to indicate low health; and (4) guio:Spatial specifies that a HUD instance may appear in a game world but is not part of a narrative or action but are there to provide more information to the player (than a character should be aware of). For example an object a player needs to interact with might glow or jump.

• guio:width specifies a width dimension of a HUD in pixels.

• guio:height specifies a height dimension of a HUD in pixels.

4.3 UI Container

The UI container, defined by the guio:UIContainer class provides a container and placeholder for UI elements defined as instances of the guio:UIElement class (described in Subsect. 4.4). UI containers also serve to group UI elements together so that they could be rendered together. Moreover, any actions bound to the container would be applied to all the UI elements within that specific container. The following are different types of UI containers (not exhaustive) and are defined as subclasses of guio:UIContainer:

• guio:Accordion defines a container that allows players to expand and collapse a group of UI elements.

• guio:Modal defines a small window overlay containing several UI elements that requires the player to interact with before closing the window and returning to the flow of the game.

• guio:Card defines a small rectangle or square container containing several UI elements.

• guio:Carousel defines a container that allows players to browse through and interact with a set of UI elements.

• guio:Sidebar defines a container on the side of a HUD that displays a group of navigational UI elements such as buttons or UI elements that provide information. This container could be visible or collapsed.

• guio:TabBar provides a container with UI elements that allows a player to switch between different modes.

• guio:Toolbar defines a container on which UI elements are placed and grouped together.

• guio:Pagination defines a container whereby UI elements are placed in different containers within the pagination container and allows a user to skip between the inner containers or go through the inner containers sequentially. The pagination containers and the child containers are linked using the guio:partOfUIContainer property described below.

• guio:BentoBox defines a container that organises UI elements in a grid.

• guio:HamburgerMenu defines a container that toggles a menu containing several UI elements. The icon of this container are three horizontal lines on top of each other.

• guio:DonerMenu defines a container that toggles a menu containing several UI elements. The icon of this container are three vertical lines next to each other.

• guio:MeatballsMenu defines a container that toggles a menu containing several UI elements. The icon of this container are three horizontal dots next to each other.

• guio:KebabMenu defines a container that toggles a menu containing several UI elements. The icon of this container are three vertical dots on top of each other.

The main properties of the guio:UIContainer class include the following:

• guio:hasUIElement specifies a UI element defined by the guio:UIElement class (explained in Subsect. 4.4) that is contained within a UI container. UI containers can have one or several UI elements.

• guio:hasUIContainerTransform specifies a transform of a UI container defined by the guio:Transform class (described in Subsect. 4.6). This defines a position, rotation and scale of a UI container relative to a HUD’s local coordinates within a screen.

• guio:hasUIContainerAction this defines a general action bound to an instance of the guio:UIContainer class defined by the guio:Action class (described in Subsect. 4.5).

• guio:partOfUIContainer specifies that a UI container is part of another container – i.e. a container within another container.

• guio:width specifies a width dimension of a UI container in pixels.

• guio:height specifies a height dimension of a UI container in pixels.

4.4 UI Element

UI elements, defined by the guio:UIElement class, are visual elements on a computer screen that provide information to users or help users to interact with a game. UI elements are contained within UI containers. The following are different types of UI elements (not exhaustive) and are defined as subclasses of guio:UIElement:

• guio:Checkbox specifies an option that can be selected by a user. Normally, checkboxes are grouped within a set of checkboxes allowing a user to select one or more options. A set of checkboxes can be grouped within a UI container defined using the guio:UIContainer class (explained in Subsect. 4.3).

• guio:Radiobutton specifies an option that can be selected by a user. Normally, radio buttons are grouped within a set of radio buttons and allow users to select only one option from the whole set of radio buttons. A set of radio buttons can be grouped within a UI container defined using the guio:UIContainer class (explained in Subsect. 4.3, and an action bound to a container containing radio buttons would control and ensure that a user selects only one radio button from the whole set.

• guio:Dropdown specifies a list of items that allows users to select only one item at a time. The action bound to a dropdown list would control and ensure that a user selects only one option from the list of items.

• guio:Listbox specifies a list of items that allow users to select more than one item at a time.

• guio:Button specifies a UI element that a user could interact with by clicking or touching. This element typically consists of a label using text, an icon or both. The action bound to a button controls the event, and a method or function bound to the action is executed once the event is triggered by a user.

• guio:Toggle allows a user to change a setting between two states.

• guio:Text specifies a label that can be displayed for information purposes. Text wraps accordingly to the dimensions specified by the UI element in relation to the dimension of the UI controller where the text is contained in.

• guio:TextField allows a user to insert text in a game – for example to provide a name for a character.

• guio:Image specifies an image to be displayed.

• guio:Picker allows users to select a date and time.

• guio:Breadcrumb specifies a trail of links that helps a user figure out where s/he is in a game – for example Main Menu –>Settings –>Display Settings. Each link would be bound to an action that will direct a player to a specific area in the game represented by that link.

• guio:Slider specifies a UI element that allows a user to select a value or a range of values by dragging the slider – for example to adjust the volume, or to adjust the brightness of a screen.

• guio:Stepper specifies a UI element that allows a user to adjust a value in predefined increments.

• guio:Tag defines a label which a user could use to label content.

• guio:Icon defines a simplified image serving as a symbol used to provide visual information to a player or help a player to navigate within a game.

• guio:Tooltip specifies a UI element that allows a player to see hints either when the player hovers over an object or item within a game, or pop-up accordingly as contextual help within a game.

• guio:ProgressBar specifies a UI element that indicates where a player is whilst advancing through a series of tasks or steps.

• guio:Notification specifies a UI element in the form of a message that announces something new for a user to see such as when a task is completed successfully.

• guio:Messagebox specifies a small window that provides information to a user and requires the user to take an action before continuing forward.

• guio:Loader specifies a UI element to inform a player that a game is completing an action in the background and the player should wait until that action is complete.

The main properties of the guio:UIElement class include the following:

• guio:hasUIElementAction this defines an action bound to a UI element defined by the guio:Action class (described in Subsect. 4.5).

• guio:hasUIElementTransform specifies a transform of a UI element defined by the guio:Transform class (described in Subsect. 4.6). This defines a position, rotation and scale of a UI element relative to a UI container’s local coordinates within a HUD.

• guio:hasUIElementFont defines a UI element’s font details defined by the guio:Font class (described in Subsect. 4.7).

• guio:width specifies a width dimension of a UI element in pixels.

• guio:height specifies a height dimension of a UI container in pixels.

4.5 Action

The guio:Action class defines events such as mouse input, keyboard input, game controller input, motion sensing input, gyroscope input, touch input etc., bound to a specific method or function that a game can execute once the event is triggered by a user. The main properties of the guio:Action class include the following:

• guio:hasActionEvent this defines the event that is triggered by a user using an input device.

• guio:hasActionMethod this defines the method or function the game executes once an event is triggered.

• guio:appliesToDevice this defines to which device or devices the action is bound.

4.6 Transform

The guio:Transform class defines transformation properties that can be applied to Screens, HUDs, UI controllers or UI elements. The properties include the following:

• guio:hasTransformPosition defines the x, y, z position coordinates of an object relative to the parent’s coordinates.

• guio:hasTransformRotation defines the x, y, z rotation coordinates of an object relative to the parent’s coordinates.

• guio:hasTransformScale defines the x, y, z scale coordinates of an object relative to the parent’s coordinates.

4.7 Font

The guio:Font class defines font properties that can be applied to UI elements to visually format the text contained in the elements. The properties include the following:

• guio:hasFontFamily specifies the font family name for an element – for example “arial” or “times”.

• guio:hasFontStyle specifies the font style for a text element which could be set to either normal, italic or oblique.

• guio:hasFontSize specifies the length of an element which could be set to either centimeters (cm), millimeters (mm), inches (in), pixels (px), points (pt) or picas (pc).

• guio:hasFontWeight specifies how thick or thin characters in text should be displayed which could be set to either normal or bold.

• guio:hasFontVariant specifies whether or not text should be displayed in small-caps, which could be set to either normal or small-caps.

Overview of the Player User Interface Preference Ontology (PUIPO)

Full size image

The Player User Interface Preference Ontology (PUIPO)^{Footnote 13} (illustrated in Fig. 2) provides a light-weight vocabulary for formally defining player’s user interface preferences in digital games. Preferences are defined on top of formal descriptions defined using the Game User Interface Ontology (GUIO). Using these preferences, games could render user interfaces according to the player’s preferences thus enabling personalised user interfaces in games. Preferences are defined as instances of the main class of this ontology – the puipo:PlayerUIPreference class. This following are the properties for defining player’s game user interface preferences:

• puipo:hasFontPreference specifies the font preferences of a player that are applied to UI elements. The font preferences are defined as instances of the puipo:FontPrefernce class (which is a subclass of the class guio:Font) and has the puipo:appliesToUIElement property to define to which UI elements the prefernce would be applied to.

• puipo:hasTransformPreference specifies a player’s transform preferences for any elements in a game. The transform preferences are defined as instances of the puipo:TransformPreference class (which is a subclass of the class guio:Transform) and contains the following properties: (1) puipo:app- liesToScreen specifies to which screen the player’s transform preference is applied to; (2) puipo:appliesToHUD specifies to which HUD the player’s transform preference is applied to; (3) puipo:appliesToUIContainer specifies to which UI container the player’s transform preference is applied to; and (4) puipo:appliesToUIElement specifies to which UI element the player’s transform preference is applied to.

• puipo:hasHUDTypePreference specifies which HUD type a player prefers (i.e. whether diegetic, meta, spatial or non-diegetic). The HUD type preferences are defined as instances of the puipo:HUDTypePreference class, which is a subclass of guio:HUDType class and contains the property puipo:applies- ToHUD to define to which HUD this preference applies to.

• puipo:hasActionPreference specifies a player’s action preferences for example configuration of game controller buttons (i.e. customising which buttons linked to specific events). A player’s action preferences are defined as instances of the puipo:ActionPreference class, which is a subclass of guio:Action and contains the following properties: (1) puipo:appliesToSc- reen specifies to which screen the player’s action preference is applied to; (2) puipo:appliesToHUD specifies to which HUD the player’s action preference is applied to; (3) puipo:appliesToUIContainer specifies to which UI container the player’s action preference is applied to; and (4) puipo:applies- ToUIElement specifies to which UI element the player’s action preference is applied to.

• puipo:hasDisplayPreference specifies a player’s display preferences that are applied to screens. The display preferences are defined as instances of the puipo:DisplayPreference class that defines preferences such as: (1) resolution, (2) refresh rate, (3) texture quality, (4) anti-aliasing, (5) VSync, (6) tessellation, (7) ambient occlusion, (8) anisotropic filtering, (9) high dynamic range, (10) bloom, (11) motion blur, and (12) field of view.

In this paper we presented the Game User Interface Ontology (GUIO) a light-weight vocabulary for formally defining user interfaces in digital games, and Player User Interface Preference Ontology (PUIPO), a light-weight vocabulary for formally defining player’s user interface preferences in digital games. Player preferences, defined using PUIPO, link to formal descriptions of user interfaces, defined using GUIO, that can guide games to render user interfaces customised to players’ preferences thus enabling personalised semantic user interfaces for games. As future work, we will develop software tools that render automatically user interfaces based on these ontologies.