Database and user data saving + loading

This describes how data is being manipulated, how it is saved / loaded to / from database in the game.


Following ER diagram displays the structure of major part of the database. Fields displayed in blue color have on delete cascade constraint.
That means, that if row is deleted from table, to which is the foreign key, then the value with the blue field will also be deleted (if there is valid / any FK).

Following ER diagram displays the structure of translations table:

1 Introduction

There are 3 main entities. nodeJS game, SQL database, Game Webpage.

1.1 nodeJS game

That is a project written using NodeJS and EJS templating system.
The project itself is hosted on Heroku.
It allows a user to play the game (using javascript, sockets), but also allows a user to log in or join lobbies.
To create the GUI and buttons, lists, game hud, HTML is used (using EJS templating system)

The game, however, requires resources and data, such as weapon names, database table names and column names, medals for the game, textures, css styles....
Some of the resources are required by the Game Webpage as well.

1.2 Game Webpage

That is a project written using Nette.
Allows users to log in, see game statistics, forums and so on.

The page requires resources as well, and some of them are common for the nodeJS game as well.
These are for example:

The following common resources are placed in the Game Webpage, and the nodeJS game downloads it from the page if needed.

The following common resources are placed in the nodeJS game, and the Game Webpage downloads it from the page if needed.

1.3 SQL database

Functions as classic data storage for both Game Webpage, and the nodeJS game
Contains abilities, medals, users, forums (posts, replies, threads), game dialogues and so on.

2 NodeJS game

This describes how database data is being manipulated within the nodeJS game

2.1 Data loading from database (diagram)

Data is loaded from the SQL database only once, and upon starting the server.
Following diagram shows the action of loading various data. When it is loaded, and in what order.

In the game, DatabaseModels (for example WeaponsDatabaseModel , UserWeaponStatsDatabaseModel ) and DAOs ( AbilitiesAllDAO ) are being used.

2.3.1 MonsterDatabaseModel

This describes the idea behind the MonsterDatabaseModel in the game code.

User data

There is user data that is being loaded from database, and saved to database. However, some data does not need to be loaded from the database at all.
For example, considering weapon statistics, all that is needed is to gather the numbers (kills, shots...), and then only insert / update the table data, incrementing the values.


Medals are NOT being loaded from database.
Only saved into database, incrementing the values in the table.

Ability statistics

Ability data are also NOT being loaded from database.
There is even not needed for the rows to exist in the table, as they are created if they do not exist.
if row with ability stats does not exist, it is created
if row with ability stats does exist, it is updated (incremented) by a value

Ability stats contain statistics for all abilities, (that can be used by player), for each player.
Further details are not here to avoid being forced to rewrite documentation at any game / database system change.


Abilities are being loaded only once from the database at the start of the game server.
Then, all game ability class instances are created according to data from database and saved in memory for later use.
All the ability data is being sent to the client, regardless if the ability is for monster only, or not (as client needs to be able to recreate monster attack on the client side).
The data is sent to the client when the client connects.
The data transportation is being explained in networking

2.4 Optimalization

Data retrieval from database can be optimalized in same way, as explained in localization optimalization