OAC Proposal for a Common
Player User Interface (PUI)
May 24, 2010
Green Valley Ranch - Las Vegas, NV
Agenda
 Operator Vision of the Future
 Player User Interface Overview
 GSA Protocols Supporting the PUI
 PUI Functional Components
 Questions – Comments - Discussion
Slide 2
Introduction:
Jeff Wyton – Alberta Gaming & Liquor Commission (AGLC)
OPERATOR VISION OF THE FUTURE
Slide 3
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 4
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 5
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 6
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 bidirectional fashion.
 The technology must scale across our enterprise to all
appropriate customer facing touch points.
Slide 7
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 8
Cornell Balagot - Oregon State Lottery (OSL)
PLAYER USER INTERFACE OVERVIEW
Slide 9
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 10
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 11
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 12
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 13
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 14
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 15
Player User Interface – Use Case
 Use Case applications are grouped into 3
categories:
 Gaming
 Services
 Player Management
 This is just a starting point
Slide 16
Use Case Example
 Tournament Status
 Description: Player wants to find out
how he or she did in a tournament
 Outcome: Player sees ranking on PUI
PUI Control &
Display Area
Slide 17
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 18
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 19
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 20
Jeff Wyton
GSA PROTOCOLS SUPPORTING THE PUI
Slide 21
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 22
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 23
Operator Perspective
Klaus Peltsch – Ontario Lottery and Gaming Corporation (OLG)
PLAYER USER INTERFACE FUNCTIONAL
COMPONENTS
Slide 24
Functional Overview of Components
3
1
Player UI
Platform
2
4
Player Rules
Engine
Player UI
Presentation
Player Session
Manager
EGM
5
Real-Time
Events
Stream
6
Data/Information
Access
Other Event
Sources
• 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 25
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 26
Jeff Wyton
QUESTIONS - COMMENTS - DISCUSSION
Slide 27