Backend Architecture - Capi-Metaverse/Template GitHub Wiki
Much of the data in a Unity application is stored internally.
Data such as states, scenes or objects are initialised at the start of the application and are only needed at runtime. However, we need a server to persist data such as user or transaction information.
In the following sections we will describe:
-
Technologies and State of the Art
-
Architecture and Implementation
-
Deployment
To document the state of the art, we have looked at other applications of a similar style, such as video games.
If we focus on multiplayer games we can find that they use all kinds of databases like SQL (MySQL, Oracle), Redis or MongoDB.
For example, Fortnite uses MongoDB for user data and Redis for sessions, meanwhile other games like World of Warcraft or EvE Online uses SQL databases. For our application both systems could be used, perhaps it would be suboptimal to use SQL if we had a large scale of users.
Due to this is a small investigation project, we are going to use MongoDB for Database implementation and Node.js with TypeScript and Express for the communication with Unity. We can use Node.js instead other technologies because we will have a small number of connected users.
Unity will communicate with the server via API Requests that the server will answer with the required information like a correct login, sign-up or errors.
We don’t follow a certain design pattern because there isn’t too much operations right now but it can be extensible with a controller-service-repository pattern in the future.
For the deployment of the server, Render's free basic plan has been used. Once a user has been created, a Git project and a specific branch must be chosen for the server deployment to take place. The necessary keys for the server, such as the MongoDB key, have also been secretly specified.