Technology
Last updated
Last updated
Battlecorp is composed of 6 main technologies, serving the Game Application that is accessible by the user, the Game Server that runs all the game logic, and the Game Data that are the root of all data and in the case of web3, also hosts certain game logic.
This section describes the overall architecture including existing, under development and coming components of the game.
Our application is developed on the . The main reason for this choice is the cross-platform compatibility of what we will develop, including the possibility to publish to web browsers, in order to provide a maximum of access mediums to the game.
The Game Application mainly handles the navigation and display in the game information, in form of a carefully designed User Experience with ambiant immersive graphics. It merges 2D displays for the Management mode and 2D + 3D graphics for the Wargame Mode.
To manage communication, the Game Application relies on REST API exposed by the Game Server, and client side code automatically generated from the server endpoints in order to fasten the development. In one occasion, we also use websocket communication to manage specific real time communication required to synchronize actions and states between the player Application and the Server in Wargame.
Wargame as a 2D an 3D part of the game is designed to manage further evolution of the game in time. The core parts of the Wargame are 3D display of the maps, generated based on 3D game assets, and procedural tools, from the Map layer to the placing of 3D models on it including digital layer strategic display (territories limits, labels, status and actions visuals...).
The Wargame logic is able to manage the addition of different maps organization, environment and ambiance, as well as game modes that involve manual or fixed phase durations (of variable durations), mono and multiplayer, events and tournaments.
For a massive multiplayer oriented game as Battlecorp, Server and Data components of the are essentials as they are managing the complexity of handling big amounts of players simultaneously, and are the warrants of the game logic. Here is an overview of the blocks of the Game Server.
Our architecture choices are also realized in order to limit the development workload enabling us to focus on the game logic development and ensuring the maintenance and evolution. Internal mechanics are automated including the scalability of the game to handle the increase of player count.
The NestJS framework is the backbone of the architecture, and supports the exposition of all the game logic endpoints as a REST API.
Our Object Datastore Model (ODM) abstracts the NoSQL technology (Cassandra in our case) to focus on defining the data structure, read and write actions without writing actual database specific code.
Our API is designed to generate documentation and swagger files allowing us to generate automatically client-side code for our Game Application as the backend keeps evolving.
A web socket synchronizes players Applications connected to wargames allowing time management of phases, including the classical manual passing of phases in some game modes. An event-based communication bus is then used to synchronize server instances between each other for players connected on different servers.
Generic approach of the code is used for maintenability and further evolution of the code for phases, cycles and orders management. It involves a strong modules and service isolation for each service to manage its own data and logic consistency.
The NoSQL database Cassandra has been chosen for a large amount of factors including very high distributed capabilities inducing a very high scalability and resilience. It has no single entry point as all nodes of the database can be accessed for any operations. It is stable, and strongly supported by leading companies and community, as well as easily deployable in many environments including famous clouds.
Recurrent back-ups of the Database are in place and restore procedures can be realized in case of necessity.
Battlecorp administration is separate ReactJS application built on top of React-admin and configured for the game administration. As in any online game, the Battlecorp Management Team will support the in-game logics and will have a referee role in all requests from users. For example, the administration gives the Team the possibilities to manage wargame queues and creation, viewing and intervention/modifications on current wargames as well as configuring new maps and wargame modes.
The game requires multiple monitoring tools including a technical monitoring of the game services health including basic elements like space usage/quota monitoring, server instances states and response times, logging and errors management.
The second monitoring level is functional, focusing on statistics over the player behaviors, to focus on improving the game experience, supporting the decision making on high added value functionalities as well as measuring the balance of the internal game logic to resolve potential exploits, exponential developments and loop holes raising from the player actions.
The third monitoring level is financial, for both off-chain and on-chain game logics, with a strong focus on buying/selling behaviors, market and prices statistics, especially for real-money impacting game logic but also again for a better capability of balancing the game mechanics and profitability for players.
The Battlecorp Game is structured in two instances:
a master game instance accessible to all public users, there is no country or region segregation
a beta instance where the Team deploys and test new versions and features of the game
In some very specific occasions, access to beta version or new instances can given to players for community events or for development specific purposes.
Application security, when publishing any service to the Web is very important, firstly to avoid malevolent actions against the Game directly affecting players, as far as using the Battlecorp platform as attack root potentially leading to financial and penal risk and data leaks. Here is a short brief of the security measures in place in order to tackle the risks.
All Application/Server exchanged are managed in HTTPS with a signed SSL certificate. User's authentification is done through acquiring JWT tokens (access and refresh).
Automated code security rules are implemented, automated security tests are ran and pen-tests tools used to control and minimize any attack layer of our services.