Purpose
- This document serves as a guide for developing games that are to be deployed on the William Hill Vegas platform. This document will describe how William Hill expects games suppliers to develop their games. William Hill has an API and architecture that all games must adhere to. This document will describe the API, how it should be used and what technologies can be used.
- Any document could not be expected to list every technology that can not be listed, therefore if a technology is not mentioned, it must be assumed that it can not be used.
- Any deviancy from these guidelines is unacceptable without the express permission of William Hill business and technical staff.
Scope
- The document will list the operations required to allow a game to communicate with the Vegas Platform. The Vegas Platform is a server application that provides the services required for a game, such as getting the account balance, session balance, random numbers or storing session history data.
Overview
- The document will describe the Vegas Platform interface and how to use it. It should be used in conjunction with the Vegas Platform SDK that is supplied to help game developers test their games. Also included is an existing game from our portfolio that can be used as an example of how to write games. This is useful as most of the scripts a game calls are the same for any game, only a few of these scripts need to be changed for each game.
- The Vegas Platform uses Microsoft IIS to host the games and their scripts. The Vegas Platform uses Flash for its games and ASP scripts to talk to the server side.
- ALL SCRIPTS MUST BE WRITTEN USING ASP V3. NO OTHER VERSIONS, INCLUDING ANY VERSION OF ASP.NET, ARE ALLOWED.
- ALL GAMES MUST ONLY USE THE FUNCTIONS AVAILABLE FROM THE API. NO NEW METHODS ON THE API WILL BE DEVELOPED UNLESS EXPLICITLY AGREED BY WILLIAM HILL, AND ONLY WILLIAM HILL.
- THE GAME WILL BE DEPLOYED BY COPYING THE FLASH FILE AND ITS ASP SCRIPTS DIRECTLY TO THE IIS SERVER. NO DEPLOY-MENTS, DATABASES, REMOTE CALLS ETC. ARE ALLOWED. THE GAME SHOULD BE ENTIRELY SELF CONTAINED AND USE ONLY THE VEGAS PLATFORM FOR ACCESS TO SERVICES.
Deliverables From William Hill
- William Hill, in addition to this document, will supply an SDK to allow testing of a game to occur without requiring a full deploy-ment of our Vegas Platform. A full deployment includes a cluster of Java application servers, clustered caches and multiple data-bases. It is for these reasons the SDK has been developed as it is unrealistic to expect a games developer to deploy all this soft-ware.
- We also deliver an example game to use as a template. The template can be installed and examined to see what scripts are called etc. We recommend using an HTTP capture program (such as Fiddler) to see what scripts are called, what data is passed etc. This will allow games developers to see how to structure their games.
The Vegas Platform API
- ASP scripts access the Game Server as the service object that handles all requests to the Vegas Services. In a full production environment, this is .Net object that performs Web Service calls to a clustered Java Application Server. For the SDK, the objects are stub objects although they are stored in memory and provide a more realistic experience than simply returning dummy values. The SDK uses an initial account balance but it is accurately maintained during game play. The SDK also allows game play history to be retrieved during a game session. It also stores persistent game state objects and progressive jackpots can be set up and held in the SDK's memory.
- Please use the menu on the left hand side to explore the API methods and their documentation.
Mobile Specific Functionality
- For information about mobile specific functionality offered by the Vegas platform please see the information in the mobile section
SDK Specific Methods
- The SDK has more methods than the normal Game Server. This is to allow developers to configure the SDK with Jackpot information. This is easier to explain with an example. When using the SDK, the jackpots should be set up using simple ASP scripts, one script per game.
Example
<% @LANGUAGE = VBScript %>
<html>
<head>
<title>Jackpot Creation for Captain Cannon</title>
</head>
<body>
<%
dim objGameCon, objGamesvr, online
on error resume next
set objGameCon = createobject("GameServer.Gamecon") <- Create GameCon Object
if err <> 0 then
Response.write "<p>Error occured creating GameServer.GameCon object: " & err.number & ": " & err.description & "</p>"
else
Response.Write "<p>Jackpot Created for Captain Cannon</p>"
end if
set objGamesvr = objGameCon.GameSvr <- Create GameSvr object
objGamesvr.ClearJackpot "CI" <- Clear any jackpot settings for the Jackpot for game code CI
objGameSvr.SetJackpotType "CI", "NORMAL" <- Set the Jackpot Type to Normal Jackpot
objGamesvr.SetJackpotAllocationPercentage "OS", 0.05 <- Set the % of stake allocated to jackpot
objGamesvr.SetJackpotTierAmount "CI", 1, 1000000 <- Create a jackpot tier with an initial amount
objGamesvr.SetJackpotTierReseedAmount "CI", 1, 250000 <- Set the reseed amount for the tier
objGamesvr.SetJackpotTierAllocationPercentage "CI", 1, 1.00 <- Set the 100% of the jackpot allocation to go to this tier
set objGamesvr = nothing
set objgameCon = nothing
%>
</body>