Maui

[incodewetrust]

En fait en php, avec les session tu as l'instanciation, ce qui fait qu'avec le sessions, tu as tout ce qu'il te faut pour faire un jeu.

Ca, cela mérite du détail car je ne vois pas le lien entre les sessions PHP, et l'instanciation de classes... Ni avec le fait que les sessions sont "requises" pour faire un jeu?! J'ai blinde de minis-jeux sans aucune notion de session, et les jeux où j'ai recours aux sessions, je n'y ai recours que pour ce à quoi elle servent: l'Authentication (traduire le terme risque de me faire dire une connerie, donc, vous m'excuserez de l'anglicisme! ).

Tu as raison cela mérite des explications. A chaque fois que je discute avec un adepte de la POO autour de la création de jeu multijoueurs au tour par tour, il pense sincèrement qu'il est impossible de faire autrement qu'en instanciant un objet "personnage" de la classe personnage lors de la connexion. Mais au final tu obtiens les mêmes données entre un objet sortant du moule de sa classe avec des attribut définie par le constructeur de classe et une récupération de données structurée tout à fait classique que tu stocke dans des variables de sessions. Au final la structure des données devant être récupérés sera la même et produira, dans un cas comme dans l'autre, ce qui définit l'instanciation c'est à dire qu'un "objet" (classe) ou en l'occurence "tableau multidimensionnel" pour la session, qui pourra partager des attributs similaires avec un autre objet sans être le même. Du coup pour moi les variables de sessions peuvent parfaitement se substituer à l'instanciation des classes pour définir les attributs/états du personnages ou tout autre type de données.

Par contre je n'ai jamais prétendu que les sessions étaient requises pour faire un jeu, j'ai dit qu'avec on avait tout ce qu'il fallait pour en faire un (avec la persistance des données tant que la session reste ouverte). Pour des jeux multis je m'en sert pour éviter un grand nombre de requêtes READ d'affichage (pour READ de contrôle je m'abstiens) et dans tout les cas je les utilise pour stocker des options de jeu/ d'affichage/ des messages de confirmation/ erreur ou stocker n'importe quelle donnée devant survivre à un changement/rechargement de page. Je les trouve du coup extrêmement pratique et elles sont même devenues pour moi indispensables.

Mais on peut tout à fait obtenir le même résultat en stockant systématiquement tout via des requêtes (bof en terme de perf), en utilisant des Cookie (mais cocorico il y'a toujours les petits messages gênants), et même en stockant ces états dans des attributs de classes (si on aime utiliser des procédés complexes pour faire des choses simples).

Attention après à ne pas sur-pousser le "DRY" (cf le copier/coller n'est pas malsain): les choses se répètent parfois, et les factorer pour les centraliser n'est pas toujours une bonne idée. Deux choses de même sémantiques (même sens; même signification) doivent être centralisées, mais parfois, des choses identiques n'ont pas forcément le même but, ni la même évolution, et là, DRY va pousser à les centraliser ce qui va abstraire le code et le rendre chiant à faire évoluer. Faut pas oublier que, parfois, un bête Ctrl+F/Ctrl+H dans le projet est plus efficace qu'une énorme abstraction pour tout centraliser

Pour ma part, je te conseillerai plutôt le pragmatisme absolu: tout le temps passé dans de l'archi et dans de l'écriture de code n'est pas du temps passé dans la vie du jeu (gamedesign, management de la communauté, brainstorming pour trouver les idées d'amélioration, etc). Il faut donc passer le moins de temps possible dans son code. Cela ne veut pas dire de ne rien abstraire du tout et de copier/coller tout n'importe comment, ni de faire une sur-abstraction en centralisant tous les mots du dictionnaire dans une liste de constantes à réutiliser ensuite. L'essentiel pour bien tenir sur le long terme est surtout d'avoir un périmètre bien délimité pour chaque composant du projet. Cela permet de faire sauter une feature sans exploser tout le projet. En PRAWD, je peux virer un points d'entrée (une page) sans défoncer les autres. Je peux virer un composant du gameplay de la BDD, et savoir partout où il est utilisé (je regarde dans quelles procédures les tables apparaissent, et je sais quels points d'entrée s'en servent).

PS: et le pragmatisme absolu passe aussi souvent par le simple fait de virer 80% des features inutiles du projet

Pour moi tu pose clairement les enjeux, mais je ne suis pas d'accord avec ta conclusion, j'y reviendrais.

Il y'a certes une "perte de temps" immédiate et sèche, le refactoring prends beaucoup de temps (que ce soit lié à du DRY ou non). Si le gain en terme de maintenabilité  est réel, il est parfois difficile à estimer surtout sur le long terme. Il ne faut pas le négliger car le pur copier-coller ne marche pas toujours, selon les circonstance, tu dois souvent tu dois adapter une partie plus ou moins importante ce qui fait qu'un processus unique issue du DRY sera de plus en plus intéressant sur des projets menés à long terme.

J'en ai fait l’expérience en refaisant mon système de combat. J'avais un processus d'attaque pour les joueurs, un autre pour l'IA arachnide car les données et les processus entre un joueur/arachnide étaient radicalement différents et même un troisième pour des construction de type tourelles, géré par un crontask, qui possédait la encore une structure complètement différente (puisqu'une tourelle n'a que peu de points communs avec un joueur).

J'ai passé une dizaine d'heure sur le seul formatage des données préliminaire à mon processus unique. Mais au final en maintenant 3 versions différentes, je devais, à chaque modification du moteur de combat adapter les nouvelles règles sur ces trois processus qui différaient sur 50% des étapes environ et devait être adaptés sur les 50% du tronc commun. Du coup dans le nouveau processus unique les fonctions traitent les exceptions et permettent surtout d'intégrer automatiquement tout les effets du tronc commun à tout ces acteurs grâce au formatage des données.

J'aurais pu continuer à copier-coller en adaptant, mais au final cela aurait été une petite perte de temps à chaque modification et une source potentielle d'erreur multipliée par 3 (lors de chaque adaptation).

En faisant des efforts pour rester DRY sur ces derniers 6-8 mois, mon fichier de fonction est passé de 300 à plus de 3000 lignes. Il n'est évidemment pas sur et même fortement improbable que je récupère un jour le temps investis dans ce refactoring total du processus. Mais au final et c'est la ou je ne suis pas d'accord avec toi, ce refactoring, pour moi doit être fait même s'il n'est pas rentabilisé en terme de temps ou autre, pour deux raisons :

- Cela oblige à repenser sa manière d'organiser le code, à automatiser tout ce qui peut l'être, bref le refactoring en terme de compétence et d'évolution de sa manière de programmer ne peut amener à mes yeux que du positif. Il amène à produire du code de qualité.

- La maintenabilité ne doit pas être négligée. Je parle du refacto en général pas seulement celui lié au DRY. Combien de développeur, pas forcément mauvais au demeurant, vont, par paresse ou par contrainte, face à une "pyramide of doom", encapsuler le tout dans un if supplémentaire. Au final en procédant ainsi ils ont parfaitement conscience de rajouter une couche de caca supplémentaire sur le monticule, et de déléguer le problème au suivant.... c'est sans doute efficace d'un point "make it run" mais adieux le "make it right". Le client ne sera généralement pas apte à juger et s'en moquera probablement. Mais le dév a généralement conscience d'avoir fait de la merde et même si c'est très pragmatique ce n'est pas forcément très gratifiant .

Et un jour ou l'autre tout cela se paye lorsqu'il faudra relire et modifier le code, bref en terme de maintenabilité. Effectivement il est impossible de prédire dire à l'avance que tout le temps passé sera récupéré, mais le principe reste valable et autant le mettre en pratique sur un code susceptible d'être modifié.

Bref de mon point de vue, au contraire, sur son propre projet, son propre jeu, je pense qu'il est important d'essayer de bien faire, car dans le monde pro avec les contraintes clients/temps on ne peut pas forcément mettre en application ces deux points du fait c'est un travail "invisible" qui ne produit pas de fonctionnalité supplémentaire (et donc n'a aucune chance d'intéresser le client, sauf si le client est dév évidemment).