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