G2S Building blocks May 2010 Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes SoftLab

1. G2S Building blocksMay 2010Green Valley Ranch - Las Vegas, NV Ales Gornjec, Hermes SoftLab How to speed up the implementation of GSA standards into new products

2. Agenda • Why GSA and G2S • Approach to providing G2S solutions to gaming machine vendors • Why developing our own set of tools? • Generic implementation versus specific • Integration challenges and solutions • G2S host and S2S protocol building blocks

3. Hermes SoftLab At a glance HERMES SoftLab is an international provider of software engineering services & IT solutions • Established: 1990 • Member of ComTrade Group since 2008 • Headquarters: Ljubljana, Slovenia, EU • Employees: 850+ • Main markets: • gaming & storage industries • telecommunication service providers • financial institutions and the public sector • Quality certificates: ISO-9001/TickIT by BSI

4. The need for GSA and G2S? • For heavily regulated industries (like gambling) standards are very important • Single vendor environments are easier to build but – players require variety • Standards break vendor lock-in situations • First important steps already made • Now certification program and GSA university are also available

5. Complexity -GSA Protocol sizes and growth *SAS included only for comparison of spec and functionalities covered

6. Hermes decision and goals? • Previous experience with industry standards • Knowledge transfer from other segments (XML, SOAP, security) • The need • Due to its complexity G2S requires significant investments (time, resources, knowledge) • Standards can’t be deployed successfully without wider vendor support • Vendors are asking themselves: • to develop or • to buy and integrate? • Implementation goals: • Compatibility with vendor platforms (OS and language) • Low resource consumption (ram and processing power) • Easy integration • Clear separation between protocol stack, integration and platform to allow easy maintenance

7. Build or buy decision Buy (+) Build Full control No external dependencies Optimal implementation and integration into the platform Possibility to reuse platform features (persistence, logging, …) • Shorter time line • Portable design • Clear and stable API • Proper support for extensions • Phased integration – low risk from the start • Maintenance covered • Internal resources not locked into long implementation project

8. Timeline projection

9. Project – investigation & planning • High level management decision: we need G2S! • Project team is formed to • study the protocol basics, • investigate feasibility and • prepare high level estimates • takes 2 months, estimates 10 EM for basic implementation • Implementation team is formed to prepare • high level architecture, • designs and • project plan • takes 3 months, plan to finish in 8 months, discovered that testing will be difficult and testing tools need to be developed or acquired ...

10. Project risks • When building own solution for G2S • Resources • Engineers • Know how • Product: • Performance impact • Interoperability • Compliance • When buying and integrating • Platform compatibility • External dependencies • Difficult to evaluate quality in advance

11. Platform requirements • Persistent Memory usage • G2S with three main classes: ~6 kB raw data (30kB with SQLite) • G2S with all 23 classes: ~84 KB raw data (150kB with SQLite) • Minimal system requirements • Memory (RAM): 20 - 50 MB • CPU consumption • Game-cycle simulation: about 20ms/cycle • That is 50 games per second can be simulated on a dual-core PC

12. Phased integration process • Main goal is to identify and mitigate risks as early as possible • Designed in a way to answer critical questions early: • Is platform able to fulfill G2S requirements ? • Integration feasibility (interfacing, process and threading model, resource management...) ? • Hardware: are CPU and memory resources sufficient ? • NVRAM usage • Prof of concept phase gives basic working integration • Additional functionalities integration is dictated by customer and it’s priorities • Final phase helps with certifications and product deployment

13. Integration points and APIs • High level API is easier to integrate • Covers 90% of class functionality (ordinary use) • Can be combined with raw G2S API for special cases • Raw API is a direct mapping of G2S commands: • Classes • Commands • Similar structures

14. Protocol versions and maintenance • Currently 2 major G2S version branches (1.0.3 and 2.0.3) • Only deployment of version 1.0.3 is publicly known • Several S2S versions released • Several version deployed • Several dialects • Interoperability problems quite common • Maintenance cost can be considerable • Upgrades to new versions • Interoperability fixes • Backward compatibility issues • Using a generic implementation is a good path to • Reduce costs, • Reduce interoperability issues and • Shorten time to market • HSL host implementation provides multi-version support

15. Supporting G2S tools • Needed for stack development and testing • Internal tools allow our own pace for supporting new versions • Possibility to develop different incarnations • Complex GUI for manual testing • Console application for load/performance testing • Scriptable client for test automation

16. Testing • Unit testing • over 200 unit tests, cover all G2S commands • System testing • test cases for each class ( 30-100 test cases per class) • Automation • host simulator workflows • Performance • latency and CPU usage measurement • Stress testing • using command line EGM simulator • EGM simulator instance with 200 game devices ~16MB of RAM • for 1000 instances, 16GB RAM.

17. Interoperability • Problems seen: • optional commands, elements and attributes • protocol versioning • protocol backward compatibility is not 100% • problems with extensions • How to improve: • defensive approach to design and implementation • design with multi-version in mind • version and extension agnostic APIs design • protocols need to improve in this area too

18. What is still ahead of us • Wider product support (both host and EGM side) • Push seen from distributed gaming side (lotteries) • Individual deployments with some operators • Push in some jurisdictions • Initial interoperability issues resolved • Still a lot of work needed • Improvements in products based on new features available • Bigger push /need from operators will come after that

19. Questions?