The first and only platform created by and for the lovers of cooperative session games

OUR NUMBERS

Closed community tests

Some parts of the platform are already developed. Strategically, we decided some time ago to open a closed alpha version of Rollinder to the virtual community. The platform was open for a week in the month of February 2018 in two relatively populated cities in Argentina. The only thing allowed in this instance was the setting of preferences per user and the search and matching system for game tables (the Table Reports, the System of Medals and The Council are still in the production/design stage). We tried to make this test phase as discreet as possible, so we limited ourselves to inviting a handful of players personally from the database we managed, and without making any publicity about it. Here some charts showing the way in which the platform was developed between February 2 and February 11, 2018. Specifically, we focus on 1) the number of users, 2) the types of games preferred by users, 3) the number of tables created successfully, 4) hypothetical average of the miles that each user had to travel 5) the stability of the platform.

Argentina Case
1.- Registered Users
In Argentina we got 305 registered users.
2.- Prefered user Game Type:
In 80% of the time, users chose more than one game

3.- Created Game Tables:
- 32 Game Table were created:
- 16 RPG pen and paper Tables (3-6 players)
- 4 Boardgame Tables (2-4 players)
- 3 Miniature War Game Tables (2-4 players)
- 3 TCG Tables
- 6 tables didn’t define a Table System (2-6 players)

4.- Average mile trip per user:
- The highest concentration of users occurred in the City of Buenos Aires. On average, users had to travel 3.52 miles (5.66 km) at the start of the test, and that distance was reduced by 23% to 2.72 miles (4.37 km) as the number of active users increased during the test.

- In simulated scenarios we could reduce the user's average trip below 2 miles, making the possibility of playing something totally accessible even for the creation of improvised game sessions.

5.- Platforn Stability
The system maintained the desired uptime of >99.9% and was only affected during the routine maintenance and updates, which were programmed for the lower demand times of the system, and did not affect more than a few minutes the functionality of the platform. The system architecture provides for scalability through the use of a load balancing server and multiple servers in the cloud, allowing the system to be updated in a staggered manner without affecting its operation for the end user. In addition to these technical tests, we tried to fatigue the system through an integral stress test, and in addition individual benchmarks were performed on each of the REST components of the backend, these being the results:

- Database, MariaDB 10.1: 50k requests/minute.
- Web Server, nginx: 50k requests/minute.
- Application Server, Wildfly 10.0.0-Final: 10k requests/minute.
- Load Balancer: 50k requests/minute.

We believe that we have sufficient hardware components to provide an exceptional service to 3000 active users, who connect between 1 to 5 times a week, even the most demanding ones that connect hundreds of times per day. The service can scale in a simple way, increasing the necessary infrastructure as bottlenecks appear, with new dedicated database servers in master / slave configuration, and new web application servers.