Citation :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! ).
Citation :la présenter comme la seule manière correcte d'organiser son codePerso, je pense que le problème vient de l'enseignement de la POO: elle ne sert en pratique qu'à éviter de mélanger des données et des comportements, et à permettre d'interchanger des comportements (ainsi que d'encapsuler les choses dans des classes et d'attribuer une visibilité aux composantes [propriétés, méthodes etc] mais ça, ce n'est pas ce que j'entends par "POO": c'est juste un namespacing des choses, et on peut faire de même en procédural en évitant juste les variables globales). Quand le but d'un jeu web n'est que de manipuler des data (ou quand un site a juste des data à manipuler), le surcoût amené par cette architecture POO n'est pas toujours compensé par l'atout de l'encapsulation. D'autant plus quand chaque entité (chaque classe) n'a qu'un seul comportement. Bref, c'est souvent présenté comme un saint graal, mal amené en cours sous la forme de "1 Interface => 1 Classe => 1 instance", ce qui enlève toute l'intérêt de la chose.
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