advancing the player user interface (pui) march 2010 m resort - las vegas, nv
Post on 19-Dec-2015
216 Views
Preview:
TRANSCRIPT
Advancing the Player User Interface (PUI)March 2010M Resort - Las Vegas, NV
Slide 2
OPERATOR & VENDOR DISCUSSION
Facilitated by Jeff Wyton & Marc McDermott
Slide 3
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 4
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 5
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 6
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 7
OPERATOR VISION OF THE FUTURE
Introduction: Jeff Wyton – Alberta Gaming & Liquor Commission (AGLC)
Slide 8
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 9
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 10
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 11
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.
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 12
PLAYER USER INTERFACE OVERVIEW
Carole Hardy - Oregon State Lottery (OSL)
Slide 13
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 14
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 15
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 16
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 17
Player User Interface What goes on the display? (cont)
Player Self Serve Player notification
Hospitality services Order drinks Make reservations Find a restaurant
Slide 18
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 19
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 20
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 21
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 22
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 23
Some Discussion?
What do we think so far?
Questions or comments?
Slide 24
GSA PROTOCOLS
Ethan Tower – Protocol Director GSA
Slide 25
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 26
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 27
G2S and GDS Interactions
G2S Host
EGM
EGMContr
olLogic
G2
S
GDS DeviceGDS
Slide 28
mediaDisplay Interactions
G2S Host
EGM
mediaDisplay Device
EGMContr
olLogic
G2
S
Under G2S Control
GDS DeviceGDS
Content
Slide 29
Content Interactions
G2S Host
EGM
ApplicationServer
mediaDisplay Device
Content
EGMContr
olLogic
G2
S
mediaDisplay Interface
S2
S
Oth
er
Meth
od
s
Under G2S Control
G2S
GDS DeviceGDS
Slide 30
PLAYER USER INTERFACE FUNCTIONAL COMPONENTS
Operator PerspectiveBrian Macsymic – Alberta Gaming & Liquor Commission (AGLC)
Slide 31
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 32
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 33
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 34
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 35
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 36
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 37
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 38
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 39
Breaktime
Let’s take a 20 minute break!
Slide 40
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 41
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 42
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 43
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 44
Questions?
Questions?
Slide 45
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
top related