Preparing for LEGALIZATION
October 1, 2010
No Comments
The prospect of federal and
state legislation to regulate online gambling in the United States has ignited
debate and speculation on how to prepare for and successfully launch and
operate online gambling operations in the country
The prospect of federal and state legislation to regulate online gambling in the United States has ignited debate and speculation on how to prepare for and successfully launch and operate online gambling operations in the country.
One of the major challenges for operators and game platform developers will be their ability to provide robust and scalable game content to address the large and sophisticated preferences of the U.S. population. The act of crafting an online game strategy and executing the production, delivery, operation, integration and maintenance of games, game platforms and payment processing together with age, identity and location verification are worthy of some serious planning. Whether you decide to license or build your own, the following points should be taken into consideration:
1) Online gaming is fundamentally different then most Web applications.
Its systems are complex and are held to higher standards than other applications. It is transaction-intensive. The amount of transactions that occur per second in a popular online gaming site far exceeds anything on a standard e-commerce site. Game applications are “state machines” that must be aware of what has happened, at a detailed level, at any instant in time in order to proceed to the next state. They require the capture and storage of every detail of game play. This level of detail is required to support the state machinery, to address the need to audit previous game activity and to support financial transaction processes. Underlying the game play is a banking operation that has to be 100 percent accurate. Platforms have to be secure to avoid internal and external attempts to influence outcomes and/or to steal or extort funds from the system. Multiplayer games are social networks that include interaction in both social and financial terms. And gaming sites are subject to legal scrutiny by state and federal authorities.
2) It is all about the data base.
In almost every online game system I have built, managed or operated the DB has been the primary challenge. In the early stages of development, DB selection, architecture, IT layout, query creation and table design need to be fully vetted. This requires projection of loads, data types and usage patterns. Each DB has its strengths and weaknesses. The way it is constructed has an impact on performance, security, reliability, costs and the talent required to make it operate efficiently. If a system/DB fails to address these fundamental requirements the results could be incorrect outcomes, hesitation in game play and slow response times. The DB is largely responsible for making sure the game platform is in equilibrium, stable and viable.
So obviously data base selection is important. Developers and business owners have their prejudices, but these should not cloud your judgment. Data bases used in high-transaction banking operations come closest to the types of DBs appropriate for gaming systems. However, these can be costly and prohibitive for startup operations. Certain open-source DBs are good alternatives, with the caveat that architecture and design are even more critical when selecting open-source solutions.
Avoid monolithic data bases. Segment. The divide-and-conquer approach provides isolation and will help to avoid an overload of any one server. Design a DB to allow it to be spread over multiple machines. This provides you with the option of adding hardware to address DB performance issues.
Game development organizations should have a DB architect on staff to implement a design, create tables, create queries and interact with business owners, project managers and developers to determine the philosophy, design, table structure, layout and setup of the DB. The responsibilities of a data base architect are different than a data base administrator’s. An architect establishes the DB design, creates tables and queries. An administrator loads the DB on the hardware, does the backups/restorations and sets up the monitoring.
3) Consider the application layer.
The games will need to run on their own hardware separate from Web-serving and data base activity. This will optimize game performance and provide isolation in case there is a problem. Reacting to problems quickly is important because of the financial implications. No single application server should act as a “controlling” or traffic router. This will defeat the purpose of distributing traffic to decrease the risk of impacting the entire system if one server has an issue. All application servers should be created equal.
4) Web Servers have their own role.
Web-server technology, load balancing, logging, etc., have become standardized, allowing operations to handle large transaction volumes. Keep game play responsibility away from Web servers. Web servers will handle registration, log-in, traffic-monitoring and content-serving. The heavy lifting will be done by the application servers and the DB. One exception is graphic content. Place graphics on separate Web servers.
5) When is caching most effective?
Caching is a way of storing information/results on an application or Web server without having to go the DB to fetch them. It is most effective when certain data is consistently being used and retrieved. This will off-load strain on the DB and distribute the load to the application and Web servers.
6) Plan and design for multiple delivery platforms.
Do not design your game platform to deliver content in only one environment. Develop your application to be deployed in social networks, on mobile devices and with multi-language support. And bear in mind, the age of heavy, large and complex game clients is gone or has been marginalized for use in console game environments or MMOG worlds. Keep you client development lightweight, allowing players to quickly engage (download) your games.
7) Age, location and identity verification are critical.
For compliance reasons your system will have to know where your players are accessing it from, where they reside and how old they are. This can be a fully automated implementation or a combined automated/manual process. Creating these systems requires expertise in risk management and access to multiple data sources that provide comprehensive coverage of the target population.
8) Prepare for system audits.
A game system will be subject to third-party audit to ensure that it is secure and the outcomes are fair and random. The auditors will determine go or no-go and could shut you down if your system is deemed vulnerable to internal or external attack. Prepare your code and system layout to make this process as painless as possible. Obtain the auditor’s guidelines beforehand to make sure you are not over-or under-designing you system for compliance.
The credit card companies have formed an alliance that dictates the level of security your platform will have to have to take credit card transactions. These guidelines are detailed and require a PCI-knowledgeable individual or company to help you implement a PCI-compliant platform. If you are caught not complying your credit card transaction-processing could be terminated. Run through your own PCI audit before launching.
9) When it comes to tracking and analytics, Google Analytics will not cut it.
A system should be created that ties Web traffic together with game play and payment-processing activity. This is the only way you will get a complete picture of player behavior, marketing results, traffic and revenue per player.
10) When it comes to hosting and IT, cloud computing may not be an option.
This is because it is difficult to enforce PCI compliance in a cloud environment. This will require the operator to locate a hosting facility in a jurisdiction that allows online gambling operations and has the infrastructure, bandwidth and expertise to support a sophisticated gaming operation. This may be one of the biggest challenges for game operators.
11) How do you defend against Denial-of-Service and intrusion attacks?
In Europe it is common for a gambling site to be hit with a DoS attack accompanied by a ransom demand. Get you hosting, network provider and development team together to craft a strategy to deal with this possibility. Intrusion attacks conducted by robot scans of your URLs will also be common. Their goal is to figure out a way to reverse-engineer the URL to get access to your data. Be careful how you construct your URLs. Do not forget about the URLs you put into e-mails and other promotions. The attackers scan these as well. Engage a security service company to regularly scan you URLs for vulnerability. This will be required for PCI compliance.
12) Think in terms of Web services.
Your architecture and applications should be designed as Web services with the appropriate standard communication protocols (SOAP/XML/Hybrids). Your applications will be accessing data from external systems and supplying data to external systems. Do not back your platform into a proprietary setup.
13) Support for game platforms goes well beyond the needs of standard Web applications.
It must be 24/7, of course. And the financial implications to players, your company and to payment processors can be severe if the game system runs into down time or unexpected failures. Do not skimp on monitoring software or your IT support staff.
ABOUT the AUTHOR:
Kevin Flood is founder and CEO of Gameinlane, a San Francisco-based company focused on advising early stage game companies on technical infrastructure, development processes, fund-raising and organization. He is a former CTO of Pureplay.com and served at one time as chief operating officer and managing director of Harrah’s Interactive UK. Prior to joining Harrah’s he was vice president of engineering for Wagerworks/IGT.
The prospect of federal and state legislation to regulate online gambling in the United States has ignited debate and speculation on how to prepare for and successfully launch and operate online gambling operations in the country.
One of the major challenges for operators and game platform developers will be their ability to provide robust and scalable game content to address the large and sophisticated preferences of the U.S. population. The act of crafting an online game strategy and executing the production, delivery, operation, integration and maintenance of games, game platforms and payment processing together with age, identity and location verification are worthy of some serious planning. Whether you decide to license or build your own, the following points should be taken into consideration:
1) Online gaming is fundamentally different then most Web applications.
Its systems are complex and are held to higher standards than other applications. It is transaction-intensive. The amount of transactions that occur per second in a popular online gaming site far exceeds anything on a standard e-commerce site. Game applications are “state machines” that must be aware of what has happened, at a detailed level, at any instant in time in order to proceed to the next state. They require the capture and storage of every detail of game play. This level of detail is required to support the state machinery, to address the need to audit previous game activity and to support financial transaction processes. Underlying the game play is a banking operation that has to be 100 percent accurate. Platforms have to be secure to avoid internal and external attempts to influence outcomes and/or to steal or extort funds from the system. Multiplayer games are social networks that include interaction in both social and financial terms. And gaming sites are subject to legal scrutiny by state and federal authorities.
2) It is all about the data base.
In almost every online game system I have built, managed or operated the DB has been the primary challenge. In the early stages of development, DB selection, architecture, IT layout, query creation and table design need to be fully vetted. This requires projection of loads, data types and usage patterns. Each DB has its strengths and weaknesses. The way it is constructed has an impact on performance, security, reliability, costs and the talent required to make it operate efficiently. If a system/DB fails to address these fundamental requirements the results could be incorrect outcomes, hesitation in game play and slow response times. The DB is largely responsible for making sure the game platform is in equilibrium, stable and viable.
So obviously data base selection is important. Developers and business owners have their prejudices, but these should not cloud your judgment. Data bases used in high-transaction banking operations come closest to the types of DBs appropriate for gaming systems. However, these can be costly and prohibitive for startup operations. Certain open-source DBs are good alternatives, with the caveat that architecture and design are even more critical when selecting open-source solutions.
Avoid monolithic data bases. Segment. The divide-and-conquer approach provides isolation and will help to avoid an overload of any one server. Design a DB to allow it to be spread over multiple machines. This provides you with the option of adding hardware to address DB performance issues.
Game development organizations should have a DB architect on staff to implement a design, create tables, create queries and interact with business owners, project managers and developers to determine the philosophy, design, table structure, layout and setup of the DB. The responsibilities of a data base architect are different than a data base administrator’s. An architect establishes the DB design, creates tables and queries. An administrator loads the DB on the hardware, does the backups/restorations and sets up the monitoring.
3) Consider the application layer.
The games will need to run on their own hardware separate from Web-serving and data base activity. This will optimize game performance and provide isolation in case there is a problem. Reacting to problems quickly is important because of the financial implications. No single application server should act as a “controlling” or traffic router. This will defeat the purpose of distributing traffic to decrease the risk of impacting the entire system if one server has an issue. All application servers should be created equal.
4) Web Servers have their own role.
Web-server technology, load balancing, logging, etc., have become standardized, allowing operations to handle large transaction volumes. Keep game play responsibility away from Web servers. Web servers will handle registration, log-in, traffic-monitoring and content-serving. The heavy lifting will be done by the application servers and the DB. One exception is graphic content. Place graphics on separate Web servers.
5) When is caching most effective?
Caching is a way of storing information/results on an application or Web server without having to go the DB to fetch them. It is most effective when certain data is consistently being used and retrieved. This will off-load strain on the DB and distribute the load to the application and Web servers.
6) Plan and design for multiple delivery platforms.
Do not design your game platform to deliver content in only one environment. Develop your application to be deployed in social networks, on mobile devices and with multi-language support. And bear in mind, the age of heavy, large and complex game clients is gone or has been marginalized for use in console game environments or MMOG worlds. Keep you client development lightweight, allowing players to quickly engage (download) your games.
7) Age, location and identity verification are critical.
For compliance reasons your system will have to know where your players are accessing it from, where they reside and how old they are. This can be a fully automated implementation or a combined automated/manual process. Creating these systems requires expertise in risk management and access to multiple data sources that provide comprehensive coverage of the target population.
8) Prepare for system audits.
A game system will be subject to third-party audit to ensure that it is secure and the outcomes are fair and random. The auditors will determine go or no-go and could shut you down if your system is deemed vulnerable to internal or external attack. Prepare your code and system layout to make this process as painless as possible. Obtain the auditor’s guidelines beforehand to make sure you are not over-or under-designing you system for compliance.
The credit card companies have formed an alliance that dictates the level of security your platform will have to have to take credit card transactions. These guidelines are detailed and require a PCI-knowledgeable individual or company to help you implement a PCI-compliant platform. If you are caught not complying your credit card transaction-processing could be terminated. Run through your own PCI audit before launching.
9) When it comes to tracking and analytics, Google Analytics will not cut it.
A system should be created that ties Web traffic together with game play and payment-processing activity. This is the only way you will get a complete picture of player behavior, marketing results, traffic and revenue per player.
10) When it comes to hosting and IT, cloud computing may not be an option.
This is because it is difficult to enforce PCI compliance in a cloud environment. This will require the operator to locate a hosting facility in a jurisdiction that allows online gambling operations and has the infrastructure, bandwidth and expertise to support a sophisticated gaming operation. This may be one of the biggest challenges for game operators.
11) How do you defend against Denial-of-Service and intrusion attacks?
In Europe it is common for a gambling site to be hit with a DoS attack accompanied by a ransom demand. Get you hosting, network provider and development team together to craft a strategy to deal with this possibility. Intrusion attacks conducted by robot scans of your URLs will also be common. Their goal is to figure out a way to reverse-engineer the URL to get access to your data. Be careful how you construct your URLs. Do not forget about the URLs you put into e-mails and other promotions. The attackers scan these as well. Engage a security service company to regularly scan you URLs for vulnerability. This will be required for PCI compliance.
12) Think in terms of Web services.
Your architecture and applications should be designed as Web services with the appropriate standard communication protocols (SOAP/XML/Hybrids). Your applications will be accessing data from external systems and supplying data to external systems. Do not back your platform into a proprietary setup.
13) Support for game platforms goes well beyond the needs of standard Web applications.
It must be 24/7, of course. And the financial implications to players, your company and to payment processors can be severe if the game system runs into down time or unexpected failures. Do not skimp on monitoring software or your IT support staff.
ABOUT the AUTHOR:
Kevin Flood is founder and CEO of Gameinlane, a San Francisco-based company focused on advising early stage game companies on technical infrastructure, development processes, fund-raising and organization. He is a former CTO of Pureplay.com and served at one time as chief operating officer and managing director of Harrah’s Interactive UK. Prior to joining Harrah’s he was vice president of engineering for Wagerworks/IGT.
