+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Tout sérializer avant de mettre dans la base de données (/showthread.php?tid=6646)
RE: Tout sérializer avant de mettre dans la base de données - php_addict - 23-02-2013
(23-02-2013, 07:38 PM)Kroc a écrit : Lors d'un refactoring j'ai dû créer un script capable de désérialiser/resérialiser toutes mes données. Mais attention, les pb de migration de base existent aussi lorsque les données sont en clair.
voilà typiquement un problème. à priori un refactoring comme celui ci aurait été plus simple avec des champs SQL au lieu de données sérialisées, isn'it?
RE: Tout sérializer avant de mettre dans la base de données - Kroc - 23-02-2013
Oui peut-être... voyons cela:
Si les données sont en clair, on a donc une couche logicielle qui recrée la structure des classes à partir de la base (elle peut se réduire à une série d'annotations). Si on modifie les classes, on adapte cette couche logicielle, et une fois en prod, ça marche directement.
Dans mon cas, cette couche logicielle n'existe pas (plus précisément, elle est générée). J'ai donc créer un script qui charge les données avec l'ancienne structure de classe (une ligne), créer la nouvelle structure (dificulté variable selon le refactoring), puis sauve le tout (une ligne).
Le serveur est down, le temps d'exécution du script (je sais c'est mal... mais je ne suis qu'un amateur ! )
Ce compromis m'a fait gagné un temp énorme sur la gestion de la base de donnée... en fait mon schéma ce résume à 4 tables, je n'y pense jamais: c'est autant de gagner à penser au jeu.
Si je me fais l'avocat du diable, c'est pour montrer qu'il y a une différence entre le truc (conception, game play, design, ...) parfait et ce que l'on va pouvoir sortir avant de se décourager. Il n'est donc pas stupide de choisir la solution la plus simple.
RE: Tout sérializer avant de mettre dans la base de données - Xenos - 23-02-2013
C'est une solution que je trouve similaire à "n'optimisez pas! acheter un nouveau processeur i9" (oui je sais, ca existe pas encore mais c'est pour ne pas faire de pub).
Cela revient à tout stocker en chaine de caractères... Si jamais on est en utf-8 ou utf-16, on va quand même aller multiplier la taille de la BDD par un facteur probablement proche de 10 (donc, des coûts 10x plus élevés). De plus, je ne comprends pas comment on fait des recherches dans une telle BDD... Si, par exemple, je sérialize mes objets "batiments" de ma carte de jeu, comment je fais pour dire à la BDD "combien de puit de pétrole y-t-il dans le pays du joueur truc?"? Il faudrait désérializer chaque batiment, récupérer l'instance de la classe associée, injecter les données désérialiser, puis compter les batiments? :o Je sens venir les temps de latence de ouf...
Après, dans des jeux plus légers, peut-être que la rapidité de codage primera sur la lourdeur du code, mais dans des jeux un peu plus tordus niveau gameplay, je ne pense pas que la sérialization soit la bienvenue, même si elle permet de lancer rapidement son jeu (le but n'est pas de lancer le plus vite un jeu sale, mais de lancer le jeu le plus vite possible, quitte à faire tomber une fonctionnalité non-nécessaire, on ne parle pas de savater la conception pour faire de l'obfuscation maximale)
RE: Tout sérializer avant de mettre dans la base de données - Kroc - 23-02-2013
Il faut être conscient des limitations des techniques utilisé, mais aussi du bonhomme... microsoft c'est lancé en achetant un certain "Quick and Dirty OS". Avec 30 ans de recul, on ne peut pas dire que c'était une mauvaise idée.
Sur tes remarques en particulier:
Citation :je ne comprends pas comment on fait des recherches dans une telle BDDOn ne fait pas ! Dans mon cas (qui est peut être particulier), l'intégralité des données d'une partie sont injecté dans la page (100-500ko) et les recherches sont faite en local (js et oui l'équivalent des index est aussi envoyé au client), il n'y a même pas la latence réseau.
Citation :je trouve similaire à "n'optimisez pas! acheter un nouveau processeur i9"Eh bien oui ! Un logiciel à 3 coûts à vase communicant : le développement, l'exécution et la maintenance. L'important est bien la somme des trois. Dans le cas d'un serveur, on peut facilement acheter quelques machines supplémentaires à moindre coût. Dans d'autres cas, chaque optimisation mineure peut faire gagner beaucoup une fois répercutée sur des millions de téléphones.
Ce n'est pas parsqu'une solution est moche pour le développeur qu'elle n'est pas la plus efficace
RE: Tout sérializer avant de mettre dans la base de données - Xenos - 23-02-2013
J'ai jamais dit ca
C'est effectivement totalement inadapté à certains cas (le mien par exemple), mais sur des "jeux plus légers, peut-être que la rapidité de codage primera sur la lourdeur du code".
mais si on veut un jeu dans lequel les joueurs interagissent, on est forcé de faire des recherches dans la BDD, non? Pour savoir au moins quel objet est à qui. Et du coup... on ne peut plus faire de sérializé?
Un jeu réseau dans lequel "l'intégralité des données d'une partie est injectée dans la page", ca me surprend... C'est peut-être pas un jeu "réseau" au sens classique (c'est un genre de jeu solo en fait, non?)
RE: Tout sérializer avant de mettre dans la base de données - Kroc - 23-02-2013
Non c'est multi-joueur, mais les parties ne comptent que 2 à 12 joueurs.
Je ne suis pas certain qu'un nombre plus élevé de joueur me contredirais.
il me faudra mieux étudier la base, certe, mais le principe de sérialisation ne sera pas forcement remis en cause.
Les recherchent doivent être connu a l'avance et sortie des blobs. oui forcément.
Toutefois, une remarque qui ira dans ton sens:
Dans le cas particulier d'un jeu amateur, le développement et la maintenance se paient en motivation (si on tombe a zéro, le projet meurt). Le dev coûte peu alors que la maintenance est très chère
RE: Tout sérializer avant de mettre dans la base de données - Xenos - 23-02-2013
Eyuup, c'est pour ca que j'optimise :p Je réduis drastiquement mes couts, et comme la motivation suit, ca roule :p
RE: Tout sérializer avant de mettre dans la base de données - php_addict - 23-02-2013
oui effectivement je ne me rend pas bien compte parfois que les gens ont un vrai métier à 30h00 par semaines ou encore étudiant, perso j'ai enormement de temps, donc oui effectivement je n'avais pas vu la contrainte du temps passé à coder un jeu, vu comme ca effectivement je comprends qu'on puisse utiliser ce genre de solution, mais pour l'avoir fait parfois, je regrette et j'ai vite compris qu'un truc propre mais plus long à faire est plus viable qu'un truc un peu border-line et vite fait et qui marche...après, moi je suis également pris à mon propre piège car ayant beaucoup de temps j'ai jamais eu l'envie, l'utilité de me prendre un bon framework à vrai dire...
RE: Tout sérializer avant de mettre dans la base de données - Kroc - 23-02-2013
Citation :je ne me rend pas bien compte parfois que les gens ont un vrai métier à 30h00 par semainesAssurément
, un boulot à temps plein c'est plutôt 40h/sem.Pour recentrer le débat, je suis sincèrement intéressé par des exemples concrets de perte de temps (ou autre pb) lié à la sérialisation de donnée.
RE: Tout sérializer avant de mettre dans la base de données - Xenos - 24-02-2013
Exemple:
Sur eclerd, j'ai la liste des batiments que le joueur peut construire. Pour chaque batiment, il existe 1 à 4 générations (la génération 1 est celle de base, la 2eme est un batiment un peu meilleur, etc).
Ces bâtiments consomment et produisent des ressources. Il y a 26 ressources. J'aurai donc du faire au moins 53 colonnes (26 colonnes pour les consommations, 26 colonnes pour les productions, 1 colonne pour l'id du bâtiment), ou, au pire, 27 colonnes (1 colonne d'id, 26 colonnes de ressources, si >0, c'est une production, si <0, c'est une consommation). En pratique, j'ai tout rassemblé, car les consommations/productions ne sont pas les seules données.
Je me suis donc retrouvé avec 3 colonnes: l'id, la consommation, la production. Chaque ligne était alors sous la forme suivante:
Citation :Id: 1
Groupe: 1
Generation : 1
Nom :Extraction Pétrole
PrerequisRecherche : 0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0
Multiplicatifs_Terrain: 1/1/1/1/1/0.7/0/1/0.8
Salaries: 218254/72166/12150/0/0/0
Production: 8348486/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/0/12000/17045
Consommation: 0/0/0/0/0/0/0/0/0/0/0/0/0/0/26030/0/0/0/0/0/0/0/0/0/0/0
PointsVie: 27800
TypeSousSol: 1
Maintenant, j'attaque la version 2 de ce jeu... j'ai besoin d'enlever des ressources: j'suis bien mal barré avec ces sérialisations, ca va être pas pratique...
De plus, si je veux ajouter une ressource sur uniquement l'une des planètes de jeu, ca va coincer...
Pareil pour les salariés ou les niveaux de recherche requis avant de pouvoir utiliser ce bâtiment.
Mais au fait, elles sont dans quel ordre ces ressources?!
Finalement, ca a été rapide à faire, j'ai pas eu besoin de créer les 26 colonnes, mais maintenant, je dois tout reprendre, et c'est bien moins drôle.
Quand à l'option "il suffisant, au lieu de faire 8348486/0/0/0..., d'utiliser Pétrole=8348486/Charbon=0/Minerai=0/...", cela implique qu'il m'aurait fallu répérer plusieurs fois les noms des ressources, et la quantité de données aurait explosée (à l'époque, c'était une BDD limitée à... 20Mo!"
Quand à l'idée "alors utilise l'id de la ressource au lieu du nom: ca prendra moins de place", on se heurte au même soucis de clarté ("1=8348486/2=0/3=0/..." ouais, c'est pas toujours évident à lire ce 2=0..)
Donc, ca gagne du temps de sérialiser ainsi, mais sur des jeux un peu velus ou dont la maintenance se fait sur du long terme (on a le temps d'oublier comment on avait pensé son jeu), c'est souvent malvenu.