What Happened With My Data?

--Originally published at Debugging My Mind

Integrity. The property of data not being altered or destroyed by an unauthorized entity; such a property isn’t so easily assured to a client, and that’s why we needed a plan as to how we were gonna do it.

Our application consists of 2 separate main modules, the school management part of the app, consisting purely on the web implementation, keeping track and being able to register teachers, students and checking on their information, while on the other side we have the game itself, responsible of handling all the logic to provide the levels, with their defined difficulty, as well as keeping track itself of temporal progress data from each student.

Our main concern related to data integrity surged from the communication between these modules, more specifically, between the game and the database, since there has to be a stable connection to be storing each separate level, as well as obtainning the new predicted difficulty for the game, there is a chance of data being corrupted or lost in the process should a connection error occur.

Because of the glaring problem that the lack of connection of the game with the server creates, we decided to design the game itself in such a way that it can work independently whether there is a connection to the database or not. To do this, the game will do several checks before starting: first, it will try to connect to the server to obtain the user’s required information, such as their profile, predicted new difficulty and money for the store, should this connection fail there will be 2 options. One of them is executed if there are no locally stored information, where the game will begin in a “default” mode, where the player plays through the game as if they started back from 0, allowing the game to be played even if there are technical difficulties with the server. The second option is to load locally stored data, this means that the game will not only save data to the server itself, but also store data in the computer that is played in order to be used offline, this would disable the automatic difficulty prediction of the game, but would allow a player to continue playing where they left off.

Once connection is re-established with the server, the game would utilize the offline data to continue the gradual difficulty it had stored and send it all together back to the server, in order to create an accurate new prediction of difficulty for the next session. This is done so the progress that a student has made offline isn’t just discarded, and that the old difficulty prediction isn’t used as the local one might be way different at this point.

Going deeper into the database, we have a set difficulty for each player’s profile, generated from the average results from the previous levels played, this means that in the case that level specific data is lost when saving, the difficulty where the player is at itself is kept intact, allowing such risks to take place without causing damage should they happen.

Another mechanism we had thought of as some kind of backup for the player’s difficulty, was some kind of seed that would save the difficulty setting in a small and simple string, although, this wasn’t possible to implement due to time restrictions, and remains as an idea for future implementation.

The idea of backup is a safe way of keeping data integrity even in extreme scenarios of technical and hardware failure, but this kind of solution requires resources like money and time, as there is the need of separate drives where the backups need to continuously be written, as well as taking the time to make sure that they actually work.