Green logic game integration

In order to start game on dev02 env with the custom script, use url: https://ngp.dev02-gs-stakelogic.com/play

Example: https://ngp.dev02-gs-stakelogic.com/play?playerId=yu217&gameId=11780096&platform=desktop&gameJs=[gameScriptUrl]

playerId = player with this id must be created on stakelogic test platfrom before this

gameId is provided by StakeLogic

platform - desktop, mobile

Client-server protocol

GC - game client.

GS - game server.

1. Basic information

• Communication is based on HTTP. Request is sent as JSON in request body in POST request. Response is sent as JSON in response body.

• Casino platform provides to GC an URL that must be used as endpoint for all communication with GS. This URL is later in this document referenced as $GAME_SESSION_URL.

• Protocol is using 1 universal request-response structure that contains multiple independent channels (Game, Operational, Configuration, Jackpot, Social). Operation channel may influence other channels while other channels are independent each with other.

• If any of attributes is null or empty it doesn’t have to be in JSON at all.

2. Request – response protocol

Idea behind having single request-response method for all calls is to spare unnecessary requests between GC and GS. Request and response consist of several channels:

• Game channel is used to send input events from client and receive game events from server as they are defined in game-event protocol. Also wallet data are transferred in game channel as this data are required during game-play. Jackpot wins are part of game channel as this wins are results of playing game.

• Operational channel is used to initialization and termination of whole game client.

• Jackpot channel is used to update current jackpot values.

• Configuration channel is used to save and load configuration parameters (key-value).

There are some general rules how this protocol should be used:

• Requests from GC may have its number (id attribute) that is increased by 1 with each new request.

  • Requests that have id set are used to transfer important information that must be confirmed before game client can continue (order is important). Therefore GC must not send next request before it receives valid response from previous request. With this rule GC and GS can rely that their important data has been received by opposite site what makes algorithms much easier and deterministic. If communication between GC and GS fails, GC must retry by sending exactly same request. If GS receives request that has been already processed, responds with same response as when was request processed or with special status that particular request is just being processed.
  • For some requests order of delivering them to GS is not important. Those requests can be sent without id. Original idea is use such as request for heartbeat requests or confirm request or request jackpot value so GC remains free to send input request as soon as player presses spin button.

• Game client starts communication with request with operation.init attribute set to true. We recommend to combine same request with game.init and configuration.init and jackpot.init attributes set to true. In response GC gets:

  • list of game events needed to setup GC to state ready for play

  • current player’s wallet + wallet after last bet

  • player’s locale

  • game-specific JS library

  • configuration parameters saved during previous game session

• After initializing GC interacts with player. When player triggers input event (button pressed), GC sends request using game channel (input set).

• When GC animates all events (or reasonable long block of events) to player, it is supposed to send confirm request via game channel. It is recommended to send this request without using request id.

• If player wasn’t active for certain period of time, GC sends heartbeat request to let GS know that it’s still active. Heartbeat request is request with game channel with all attributes null. GS responds with actual wallet status.

• All other channels may be used at will. We recommend to ask with each input and heartbeat (channel in request must not be null to be responded). Jackpot channel can be used in order to get current jackpot value with each request.

Game client full request structure

JSON
Copy

Game client full response structure

JSON
Copy

Server response status codes

JSON
Copy

2.1 Init a game

Game client sample request

JSON
Copy

Game client sample response

JSON
Copy

2.2 Game play

Game client sample request

JSON
Copy

Game client sample response

JSON
Copy

Game wrapper

Events from game wrapper:

in - event from gcw to game client

out - event from game client to gcw

JSON
Copy

Gamble flow

Gamble data is included to initialize response.

In response server will provide following values:

active - if gamble feature is available for this game/casino;

maxRoundCount - maximum number of rounds of gamble feature, that can be played after win;

maxStake - maximum value that user can set as stake for gamble feature in coins.

gambleMode - mode, that defines if player can bet on color only (2), or color and suits (1).

Example of response
Copy

After players has got a win if a gamble feature is enabled for the game - client will receive event "evt__gmbl__enter".

gamble event example
Copy

After that player has to choose: he can send collect event and get the win or gamble. Client should send an option from user - button push event with one of the following:

'btn_black' - red

'btn_red' - black

'btn_num0' - hearts

'btn_num1' - diamonds

'btn_num2' - spades

'btn_num3' - clubs

'btn_collect' - collect

Collect event example
Copy
Type to search, ESC to discard
Type to search, ESC to discard
Type to search, ESC to discard