Advancing the Player
User Interface (PUI)
March 2010
M Resort - Las Vegas, NV
Facilitated by Jeff Wyton & Marc McDermott
OPERATOR & VENDOR DISCUSSION
Slide 2
Agenda
 Why We’re Here
 Operator Vision of the Future
 Player User Interface Overview
 GSA’s Protocols
 Player User Interface Functional Components
 Operator Vendor Discussion
Slide 3
Why We’re Here
 The OAC wants:
 To validate the direction with operators
 To obtain additional input and course corrections from
operators
 Validation of the architecture
Slide 4
Why We’re Here
 So Operators can:
 Help prioritize the OAC’s business requirements to
suit the industry’s needs
 Provide additional business requirements that may
have been omitted
 Assist in refining the architecture so that it provides
value for all operations
Slide 5
Why We’re Here
 For Manufacturers to:
 Leave with an understanding of the operator
requirements
 Understand operators’ requirements in order to
facilitate translation into each manufacturer’s
particular technologies
Slide 6
Introduction:
Jeff Wyton – Alberta Gaming & Liquor Commission (AGLC)
OPERATOR VISION OF THE FUTURE
Slide 7
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 8
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 9
The Services Concept

The Enterprise nature of many Gaming operations is driving interest in Service
Oriented Architectures.

Lower testing/certification costs & faster testing (for vendor and customer) as
only changed services need to be tested/certified in depth vs. whole monolithic
application

Decreased development costs due to service reuse.

More responsive to customer demand (i.e. implementing a service or an
improvement to a service vs an update to an entire monolithic app)
Services must :





Be modular
Be distributable
Have interfaces that are clearly defined and documented
Have the ability to be swapped out for another module that offers the same
service and interface
Have the ability to be shared across an Enterprise
Slide 10
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.
 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)
Slide 11
Carole Hardy - Oregon State Lottery (OSL)
PLAYER USER INTERFACE OVERVIEW
Slide 12
Player User Interface
 What is the Player User Interface?
 A common application and method to
communicate with players through the display
screen in an EGM
 The application will use machine peripherals (touch screen,
card reader, printer)
 A second screen is not a primary option (e.g. kiosk)
Slide 13
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 14
Player User Interface
 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 15
Player User Interface
 What goes on the display? (cont)
 Another game independent of the EGM
 Bingo, sports wager
 Up-selling other gaming products
 Streaming live video
 Amber alerts
Slide 16
Player User Interface
 What goes on the display? (cont)
 Player Self Serve
 Player notification
 Hospitality services
 Order drinks
 Make reservations
 Find a restaurant
Slide 17
Player User Interface
 What goes on the display? (cont)
 Manage Player accounts
 Access “E” wallet
 Winning number list (Lottery)
 Sports or odds lists
 Gaming tutorials
Slide 18
Player User Interface
 What goes on the display? (cont)
 Player tracking
 Player loyalty
 Advertising
 Targeted advertising
 3rd party
 On site casino or Lottery operator
Slide 19
Player User Interface
 What goes on the display? (cont)
 Informed Player (IP) Applications
 View play histories
 Set or change playing parameters
 Pop up messaging when limits are exceeded
Slide 20
Player User Interface
 What operators have discussed over the past
12 months
 We want to communicate and collect information
while a player is at a slot/VLT
 We believe the solution should use computer industry
standards and web browser technology
 The solution needs to be configurable
Slide 21
Player User Interface
 What operators have discussed over the past
12 months
 Game integrity must not be compromised
 There needs to be a distinct separation between a
game and the content displayed on the PUI
 We want a solution that all suppliers can support
Slide 22
Some Discussion?
 What do we think so far?
 Questions or comments?
Slide 23
Ethan Tower – Protocol Director GSA
GSA PROTOCOLS
Slide 24
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 25
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 26
G2S and GDS Interactions
G2S
G2S Host
EGM
EGM
Control
Logic
GDS
GDS Device
Slide 27
mediaDisplay Interactions
G2S
G2S Host
EGM
Content
EGM
Control
Logic
Under G2S Control
GDS
mediaDisplay Device
GDS Device
Slide 28
Content Interactions
S2S
G2S
Other Methods
Application
Server
G2S Host
EGM
mediaDisplay Interface
EGM
Control
Logic
Under G2S Control
GDS
Content
mediaDisplay Device
GDS Device
Slide 29
Operator Perspective
Brian Macsymic – Alberta Gaming & Liquor Commission
(AGLC)
PLAYER USER INTERFACE FUNCTIONAL
COMPONENTS
Slide 30
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 31
Functional Overview of Components
• The functional components can be redrawn as required to
fit any discussion
• This diagram arranges the components to fit this OAC
Player UI standards discussion
Slide 32
1. Player UI Platform – (OAC 25)
 The Player UI Platform manages the hardware I/O at
the EGM and creates a universal operating
environment for the system
Slide 33
2. Player UI Presentation – (OAC 26)
 The Player UI Presentation component provides the
rich dynamic content to the player. Compelling media
content is delivered to the player creating the exciting
visual experience
Slide 34
3. Player Session Manager – (OAC 27)
 The Player Session Manager is the key component
which controls the process and data flow of all
sessions from beginning to end. It is the engine that
drives the implementation of player services
Slide 35
4. Player Rules Engine – (OAC 28)
 The Player Rules Engine component separates the
governing rules for a player session from the session
management application code.
Slide 36
5. Real-Time Events Stream – (OAC 29)
 The Real-Time Events Stream provides the secure
and comprehensive bi-directional communications
between systems and games.
Slide 37
6. Data/Information Access – (OAC 30)
 The Data/Information Access component provides an
enterprise view of all data regardless of where it is
stored
Slide 38
Breaktime
 Let’s take a 20 minute break!
Slide 39
So Why Are We Here Again?
 The OAC wants:
 To validate the direction with operators
 To obtain additional input and course corrections from
operators
 Validation of the architecture
Slide 40
So Why Are We Here Again?
 So Operators can:
 Help prioritize the OAC’s business requirements to
suite the industry’s needs
 Provide additional business requirements that may
have been omitted
 Assist in refining the architecture so that it provides
value for all operations
Slide 41
So Why Are We Here Again?
 For Manufacturers to:
 Leave with an understanding of the operator
requirements
 Understand operators’ requirements in order to
facilitate translation into each manufacturer’s
particular technologies
Slide 42
Discussion Areas
 Comments on the functional components of the PUI?
 Discussion of major components flow
 How do we achieve a common look and feel across all
EGMs?
 What does configurable mean?
 What development environment options are available for
operators to develop content?
 Areas for further opportunities
Slide 43
Questions?
 Questions?
Slide 44
Detailed View

Four Player UI
configurations
options are shown

Each configuration
could operate in a
single environment

The game
environment is
transparent to the
system.

Integration with the
gaming devices is
done securely
through the
backend systems,
maintaining a
separation of
concerns
Slide 45