mobileFX RGS Server
With the RGS Server, you're not just launching games; you're guaranteeing a smooth, engaging, and reliable player experience that builds loyalty and drives revenue.
With the RGS Server, you're not just launching games; you're guaranteeing a smooth, engaging, and reliable player experience that builds loyalty and drives revenue.
The backbone of your gaming operations, the RGS (Remote Games Server) ensures your creations perform flawlessly across platforms and jurisdictions. This robust server architecture is engineered to handle the demands of real-time gaming, offering seamless integration, secure transaction processing, and scalable deployment solutions. With the RGS Server, you're not just launching games; you're guaranteeing a smooth, engaging, and reliable player experience that builds loyalty and drives revenue.
The player selects their desired bet amount and initiates a bet in the game client. This action triggers the client to construct a bet request, including the player's PlayerToken, bet details (such as BetLines, BetLevel, and CoinValue), and any other relevant game state information.
The game client sends the bet request to the RGS Server. This request is typically transmitted over a secure HTTP connection to ensure data integrity and privacy. Bet format can be either JSON or encrypted DataStream.
Upon receiving the bet request, the RGS Server validates the provided PlayerToken and bet details. Validation includes checking the player's eligibility, the bet's compliance with game rules, and any other preconditions for accepting the bet.
Once the bet is validated, the RGS Server invokes the Wallet Proxy to debit the bet amount from the player's account. The Wallet Proxy forwards this request to the external wallet's API, which processes the debit transaction and returns.
RGS Server proceeds to generate the Ticket. This involves running the game logic to determine the outcome based on the bet details and RNG. The game logic calculates wins by triggering game features and generates Ticket data.
If the ticket indicates a win, the RGS Server again communicates with the Wallet Proxy to credit the winning amount to the player's account. Similar to the debit process, the Wallet Proxy handles the interaction with the external Wallet's API.
Ticker is timestamped and hashed and persisted to RDBMS before it is serialized to the appropriate format (JSON or DataStream) and returned to the Game Client as HTTP response payload.
The game client receives the ticket data and begins the presentation process. This usually involves playing animations, updating the game interface to reflect the outcome, and displaying any winnings.
Explore Our Premium Casino Games and Experience the Future of Thrilling Entertainment. Dive into Demos Today
Contains the implementation of the mathematical models for a generic Instant Win Game Engine and a generic Game of Chance Game Engine. Game Engines support the following features: Wild Symbols, Stacked Wilds, Expanding Wilds, Scatter Symbol, Free Rounds, Bonus Symbol, Bonus Games (pick k of n).
The RNG Layer contains the implementation of various PRNGs functors used by Game Engines. The default built-in RNG implementation is 64-bit Mersenne Twister. However the system enables RNG over HTTP/S allowing the use of external RNG devices.
The Simulation Layer implements Monte Carlo Simulation for Game of Chance game engines. There are several simulation presets depending on the dataset we need to derive, such as Volatility Simulation, Variance and Standard Deviation Simulation and RTP distribution simulation. Many user-defined simulation profiles can be defined with arbitrary Bet Lines, Bet Levels, Coin Values, number of Players and number of Plays. Simulator engine utilizes multi-CPU cores and several simulator engine instances can run in parallel over the same simulation job. Simulation dataset detail level can be adjusted from recording Histograms of winnings to full raw winnings.
Logger is the lowest layer of the server and its purpose is to record structured information in logging systems. The default logger transport is Graylog and server transmits log records over UDP in GELF format. Logger inter-operates with Exception Handling Layer which records detailed run-time exceptions and forwards them to the logger. The detail consists of: timestamp, host, game engine, filename, class name, function name, line number. In addition we record data such as HTTP request / response pairs, SQL statements, JSON structures, etc. The design concept behind this layer is to provide as much information as possible for debugging and reconciliation purposes.
ORM layer is responsible for capturing objects in an RDBMS and persisting or reading them from it. It is a specialized framework created specifically for the server's code base. Mapping between C++ classes and RDBMS tables is one-to-one so that the Database Schema can also be used as a Class Diagram. The server supports loading game configurations directly from RDBMS.
Localization Layer is responsible currency management and rendering depending on the locale of the game. In addition it manages translations of games which consist of tokens. A token contains an identifier-like phrase that translates into one or more languages at run-time. Locales are defined by ISO639-1 language code, ISO3166-1-alpha-2 country code and ISO-4217 currency code. Locales bare information about currency formatting, currency symbol, currency symbol position and currency fractional units (cents, pens, etc.).
Statistics Layer contains algorithms that reveal the Volatility, Variance and Standard Deviation of a Game Engine configuration and implements various types of Histograms that are used to calculate Hit Frequencies, RTP and other essential game metrics. Statistics Layer can export datasets for visualizing into charts the Volatility of a Game, Confidence Levels, House Edge, RTP distribution, Money Path, and more.
Wallet Layer manages Debit, Credit, Balance and Refund transactions per Player Session. There are 3 different Wallet implementations available: a Free Play Wallet, a Block Chain Wallet and a No Wallet used when the server topologically is behind a Wallet instead of in front (eg. EveryMatrix RGS Matrix topology).
Reports Layer is used to prepare and execute any report supported by each game engine. Reports are exported by using a Data Writer, a simple reporting engine interface that exports data in a typical HTML table structure (THEAD, TR, TH, TD). The server implements several Data Writers: Excel Data Writer, Text Data Writer, Console Data Writer, JSON Data Writer, Datastream Data Writer (for JAVA environments), SafeArray Data Writer (for COM environments), PDF Data Writer, and more.
The JSON layer is shared among many layers and contains data conversion routines in JSON format. It is used mostly by the API layer.
Server Layer implements asynchronous HTTP/S over TCP/IP Socket Server and an HTTP API Router system similar to Node.JS Express, only native. The Server Layer has a special interface with the Exception Handling and Logger layers so that any network error (or malicious call) can be recorded in logs.
Docker Layer allows the system to be installed in standalone Docker containers to maximize Portability. Windows and Linux versions are supported.
Unleash unparalleled creativity and speed, transforming your unique casino game ideas into reality swiftly. Experience the game-changing advantage of our end-to-end toolchain today.
mobileFX is founding member of gi-ClusterPrivacy Policy | Terms of Service
© Copyright 2013 - 2024 mobileFX - All Rights Reserved
Share this page
Some options of sharing are available only if your page is online.