OAC Proposal for a Common Player User Interface (PUI)May 24, 2010Green Valley Ranch - Las Vegas, NV
Slide 2
Agenda
Operator Vision of the Future
Player User Interface Overview
GSA Protocols Supporting the PUI
PUI Functional Components
Questions – Comments - Discussion
Slide 3
OPERATOR VISION OF THE FUTURE
Introduction: Jeff Wyton – Alberta Gaming & Liquor Commission (AGLC)
Slide 4
Role of OAC in the GSA
To reinforce operator objectives within the GSA.
To obtain business requirements and course corrections from operators.
To assist in refining GSA architecture so that it provides value for operators.
To prioritize the business requirements to suite the industry’s needs.
To submit business requirements and priorities to the GSA board.
Slide 5
OAC Vision
1. Explore commonality among gaming operators with respect to Business Needs.
2. The Operator Advisory committee facilitates collaboration between operators and manufacturers, system providers.
3. The committee focuses on functional business requirements to ensure that GSA standards meet market demands.
4. Increasingly we are exploring the use of common architectural components to accelerate adoption of jurisdictional requirements, lower costs, reduce implementation risk and increased speed to market
Slide 6
Business Drivers
Informed Player Choice
Unified Player View
Entertainment and Social Gaming
Changing Demographics
Cost Containment Strategies
Revenue Optimization
Flexibility, Integration and Speed to Market
Vendor and Product Landscape
Slide 7
Why the PUI?
Addressing our market drivers requires a new relationship with our players.
Competing requires that we enhance the current gaming experience through customization and personalization.
We require a method to communicate with our player in a bi-directional fashion.
The technology must scale across our enterprise to all appropriate customer facing touch points.
Slide 8
Why the PUI? continued
The solution must be common across the enterprise and manage a full range of player focused applications (i.e. RG, profile updates, bonuses, multi media etc)
Operators need the ability to configure and control the PUI
Players need the ability to configure and control the PUI
Manufacturers need to build common PUI capabilities
Slide 9
PLAYER USER INTERFACE OVERVIEW
Cornell Balagot - Oregon State Lottery (OSL)
Slide 10
Player User Interface
What is the Player User Interface?
A common application and method to communicate with players through a bi-directional display screen in an EGM
Although the PUI is integrated with the gaming environment, it is separate and distinct from the game
Slide 11
Player User Interface
What the PUI does for an operator
Enables the integration and synergy between different vertical businesses in a Casino and Lottery
Gaming products Food, beverage, hotel services Loyalty programs
Slide 12
Player User Interface
Examples of what goes on the display
Mystery games, bonuses and progressives May or may not have links to the main game
Tournaments Leader Board
Social Gaming Interactive games
Slide 13
Player User Interface
Examples of what goes on the display
Informed Player (IP) Applications View play histories Set or change playing parameters Pop up messaging when limits are exceeded
Hospitality Services Order drinks Make reservations Find a restaurant
Slide 14
Use Cases
What is a Use Case? A technique that describes how a system
responds to a specific request through a series of descriptive steps
They describe the interaction between a player and the gaming system (via PUI)
They provide examples of kinds of information a player can request or receive through the PUI
Slide 15
Use Cases
We defined 22 gaming specific Use Case scenarios Hundreds of specific cases could be
described
Use Case Objectives Use Cases are broad enough to cover
undefined or future applications
Outcomes identify backend systems that need to be integrated in a PUI application
Slide 16
Player User Interface – Use Case
Use Case applications are grouped into 3 categories: Gaming Services Player Management
This is just a starting point
Slide 17
Tournament Status
Description: Player wants to find out how he or she did in a tournament
Outcome: Player sees ranking on PUI
Use Case Example
PUI Control & Display Area
Slide 18
Gaming Use Case
Place Sports Wager
Description: A player wants to place a wager on a sporting event
Outcome: Player places a wager on a sporting event via Player User Interface
Slide 19
Service Use Case
Room Status Message
Description: Property wants to notify a player that his/her room is ready
Outcome: Player learns that their room is ready
Slide 20
Player Management Use Case
Player Tracking
Description: Player wants to check account balances and availability
Outcome: Player views balances and availability via Player User Interface
Slide 21
GSA PROTOCOLS SUPPORTING THE PUI
Jeff Wyton
Slide 22
GSA Protocols
GSA Protocols Relevant to the Player User Interface
GDS – communications between an EGM and its peripherals.
touch-screen, card-reader, and printer protocols.
G2S – communications between an EGM and host systems.
G2S message bar requirements and mediaDisplay class.
S2S – communications between a client application and a host system.
playerInfo, playerComp, and informedPlayer classes.
Slide 23
mediaDisplay Class
Initial effort to provide a standard method for controlling application windows on an EGM.
Specifies the position and behavioral characteristics of the window.
Provides a mechanism for loading the content displayed in the window.
Provides a mechanism for communications between the content and the EGM.
Provides a mechanism for communications between the content and back-end servers.
Slide 24
PLAYER USER INTERFACE FUNCTIONAL COMPONENTS
Operator PerspectiveKlaus Peltsch – Ontario Lottery and Gaming Corporation (OLG)
Slide 25
Functional Overview of Components
EGM
Player Session Manager
Player UI Platform
Player UI Presentation
Real-Time Events Stream
Data/Information Access
Player Rules Engine
Other Event Sources
1 2
3 4
5 6
• All systems which manage player interaction can be mapped to this component model
• As the gaming standards are advanced, these components provide the context to capture and debate the requirements
Slide 26
Functional Overview of Components – Summary of requirements
Decoupled components – not tightly coupled proprietary Integration with the EGM is based on GSA standards Maximum flexibility for operator to interact with player Player interface have no effect on game Common player interface across all EGM’s Content centrally managed Operators able to create content Session flows managed centrally Low latency Separate rules engine to isolate business rules Information exposed and available in real-time
Slide 27
QUESTIONS - COMMENTS - DISCUSSION
Jeff Wyton