Nous devions passer par là...

‍

Présentation de notre nouvelle source de problèmes !

LE SQL. Evidemment, pour enregistrer les scores en limitant la triche, pour stocker les données des joueurs en toute sécurité, pour garder les mises à jour et pouvoir directement télécharger la dernière, nous devions passer par les bases de données. Il existait bien d'autre moyens mais nous voulions nous confronter car les bases de données sont un moyen "simple", efficace, et universel de stocker des informations.

Alors il était tant pour nous d'utiliser ces bases de données pour déjà effectuer et tester différente tâches :

‍

Les tentatives

La plupart sont réussies mais une nous a fait nous arracher les cheveux !

Les tâches à faire :

• Récupérer la liste, le nom, la description, ... des jeux
• Uniquement les jeux disponibles
• Récupérer leur .exe pour les exécuter
• Les exécuter tout en faisant en sorte qu'à la fin, les points gagnés soient sauvegardés
• Pouvoir les mettre à jour automatiquement
• Récupérer la liste des versions de l'interface
• Récupérer leur .exe
• Télécharger celui avec la version la plus récente et le remplacer par l'ancien si nécessaire

Mais toutes ces tâche en impliquent d'autre, du type :

• Créer une base de données "Jeux" avec comme paramètres : "nom", "version", "description", "estDisponible" et enfin "executable"
• Créer une base de données "Utilisateurs" avec comme paramètres : "identifiantUnique", "nom", "motDePasse", "dateDeCreation" et "scores"
• Créer une base de données "MisesAJours" avec comme paramètres : "version", "description", "date" et "executable"

Sauf qu'après de longues réflexions, pour le tableau de données "Utilisateurs", la colonne "scores" devrait être une HashMap (ou un "dict"), sauf que c'est impossible pour une base MySQL de faire ça. On a donc décider, après plusieurs jours, de créer un énième tableau de données "Scores" où toutes les parties seraient enregistrées (avec donc, comme paramètres : "identifiantUniqueDuJoueur", "identifiantUniqueDuJeu", "aGagné", "score" et "date").

Mais un autre problème persistait : Comment, par requête, envoyer et récupérer les exécutables
Alors là, la question nous a pris la totalité de la semaine. Après moultes et moultes tests, une conversion en binaire, en octal, ou en hexadécimal, rien à faire (*c'est la maaf qu'il préfère.*) aucune requête ne fonctionnait.
On a donc mis le problème en stand by et on a poursuivit.

Et le dernier problème de la semaine a été de définir comment trouver cet identifiant unique.
Ainsi, la culture de la programmation a pris le dessus : on s'est dirigé vers un mécanisme très connu du monde informatique : le UUID (une syntaxe particulière de Hash, ici en version MD5 sur 32 octets), un moyen d'avoir un identifiant unique à chacun !

‍

Pour résumer

Du côté SQL, on a :

• Table Games(uuid, name, isAccessible, bin, version, desc, date)
• Table Updates(uuid, bin, version, notes, date)
• Table Users(uuid, username, isFrozen, password, displayName, mail, note, creationDate)
• Table Scores(userUuid, gameUuid, won, score, date)

Tandis que du coté Python :

• class UUID -> @static randomUUID(...), @static fromString(...), @static MD5(...), @static parseUUID(...), setUUID(...), setString(...), toString()
• class User -> @static getUser(username / uuid[, password]), exists(), getUserName(), getDisplayName(), getMail(), getCreation(), getBestScore(gameUuid), getExp()
• class Version -> ... Un peu complexe à résumer simplement mais breff ça permet de comparer plusieurs versions avec plusieurs niveaux différents. ...
• class Game -> @static getGame(uuid), exists(), getName(), getCreation(), getLastestVersion(), downloadLastestVersion(), execute()
• + toutes les classes et superclasses héritées d'une ou de l'autre pour compléter l'interface...