Choix dans la conception jeu en ligne par navigateur

[fortz]

Bonjour à tous,

Je cherche depuis quelques années à créer un jeu en ligne par navigateur, je m'y suis repris à plusieurs fois pour le programmer car je n'avais pas réellement de méthode ni de phase d'analyse et de conception. Faisant actuellement mes études dans le domaine de l'informatique (IUT Informatique), j'apprends de nouvelles choses, de nouvelles méthodes qui m'amènent à reprendre mon jeu de zéro afin de tout concevoir sur papier (travail bientot fini), mettre en place des diagrammes UML, etc... Je suis maintenant confronté à un choix de taille : utiliser le PHP procédural ou le PHP orienté objets. Je suis actuellement plus à l'aise dans le procédural car je le pratique depuis longtemps cependant en touchant au OO, je vois une autre façon de penser, de développer et d'organiser ma programmation. J'en viens alors aux questions qui me tournent dans la tête et que je ne veux absolument pas négliger de peur de devoir reprendre mon projet à zéro par démotivation suite à un projet mal programmé.

Est-il possible et conseillé de programmer un jeu par navigateur plutot complexe (un ensemble de beaucoup de fonctionnalités innovantes ou non) avec du PHP OO ? Bien-sûr je sais très bien que je n'utiliserai pas que ce langage pour mon jeu.

Quel arborescence des pages me conseilleriez-vous ? Du MVC ? Ou alors une autre que je conçois moi-même selon mes besoins, sur laquelle je me sens plus à l'aise mais peut-être moins bien pensé que les modèles classiques ?

La structure MVC permet-elle de concevoir tout et n'importe quoi ou dispose-t-elle de certaines limites ?

Je vais m'arrêter à ces questions pour le moment, certaines me viendront certainement un peu plus tard, après les réponses que j'espère obtenir. N'hésitez pas à partager vos expériences dans le domaine, je suis intéressé par toute information utile. Merci pour votre aide.

Cordialement,

Fortz

[Xenos]

Salut,
Pour chaque partie, la phrase de conclusion répond à la question, mais j'aime la justifier, alors...

POO ou Procédural?

Pour ma part, cette question requiert de répondre à une autre question: Est-ce que le jeu est focalisé sur des états ou sur des transitions? Car pour ma part, c'est là toute la différence entre l'objet et le procédural. Le premier se concentre sur la description de l'état dans lequel le jeu se trouve. En quelque sort, le jeu est "suspendu dans le temps", et on peut décrire ce qui le compose à tout instant. Le second se concentre sur les transitions: on ne sait pas dans quel état se trouve le jeu, mais ce qu'on sait, c'est qu'on peut passer de telle situation à telle autre.

Ca peut paraitre assez obscur, mais alors je vais essayer de prendre un exemple pratique, et comme un gros égoïste, je vais prendre le mien. J'ai des codes permettant de déployer mes projets et sites pour mettre à jour leur version en ligne. Pour moi, c'est un cas typique de développement procédural, car ce qui m'intéresse ce n'est pas l'état des codes du site à tout instant, mais c'est de pouvoir passer de la v1.0.0 à la v1.0.1.

Autre cas peut-être plus pertinent vu la question (centrée sur les jeux web): Eclerd. La première version (celle actuellement en ligne [lien supprimé depuis]) est codée en full procédural, car je connaissais ce PHP-là (1ere année d'école d'ingé, juste après la prépa).
Résultat? Impossible de savoir dans quel état se trouve véritablement le jeu. Je n'ai qu'un patchwork de fonctions qui essaient de passer d'un état à un autre, par exemple en simulant l'avancement du temps. Au bout du compte, c'est buggé et c'est surtout immaintenable: je ne peux plus mettre à jour mes codes car c'est tout simplement un vrac de trucs.

Pour la nouvelle version, je pars sur de l'OO. Et là, c'est bien plus agréable. J'ai un jeu stable, dans lequel les composantes sont bien délimitées et avec des objets que je peux manipuler. C'est nettement plus pratique de coder quand une usine de production est une classe que quand il s'agit d'un ramassis de variables éparses.

Du coup, je pense que tout jeu destiné à vivre un moment devrait être OO, et que le procédural peut rester dans le domaine des prototypes.


Structure: MVC ou pas?

Là, c'est peut-être une question d'expérience professionnelle, mais MVC, je peux pas le sentir.

D'une part, ce pattern est déjà implicitement inclus dans un langage OO (ben, oui, le Modèle d'une classe sont ses attributs, le Controleur est le contenu des méthodes et la View est l'API publique c'est à dire les signatures des méthodes).

Ensuite, mais c'est peut-être juste dû à la façon dont se pattern est utilisé au taff, la structure devient vite immonde. L'implémentation au boulot se résume à avoir une énorme classe "Controleur" pour chaque module. Ce controleur est alors absolument ir-réutilisable; or pourvoir réutiliser les codes est la composante essentielle d'un projet. Le Modèle se contente souvent d'être une sous-exploitation du SGBD (le Modèle est composé d'une ou plusieurs classes qui vont, pour certaines, aller chercher des données dans le SGBD via des "SELECT" et les autres essaient de manipuler ces données) et la View est un benêt template PHP qui est donc là aussi assez mal réutilisable.

Pour ma part, je n'ai donc pas appliqué ce pattern à Eclerd.

Je préfère laisse la notion de "Modèle" au SQL: la logique de jeu se trouve finalement dans le SGBD, et non dans PHP, ce qui permet d'éviter les requêtes SQL perdues tout partout dans PHP (elles sont centralisés dans des procédures SQL), d'accélérer les choses (en évitant de transférer des données vers le PHP pour les manipuler et les réinjecter dans le SQL), de mieux séparer les rôles (PHP sert à afficher le jeu, le SGBD sert à sa logique métier) et ça me parait tout simplement logique de considérer que le SGBD est un serveur "REST" comme un autre (son API publique consiste en la liste des procédures stockées).

Certes, j'ai des classes PHP qui peuvent s'assimiler au "Modèle", puisque j'ai 1 classe par appel de procédure SQL (en pratique, 1 classe par "truc logique que je veux faire", et souvent, 1 truc logique = 1 procédure SQL, mais rien ne m'interdit d'avoir 2 classes appelant la même procédure si besoin). Mais ce "modèle" ne fait pas de logique de traitement.

J'ai aussi un "simili-controleur", puisque j'ai 1 classe PHP par "truc maccroscopique à faire" ("par page" in lemon words), mais ce contrôleur sert simplement à trigger les classes de "Modèle". Ces classes ne sont d'ailleurs pas instanciées dans le contrôleur, mais dans une factory (méthode statique ou classe à part suivant le niveau de réutilisation requis).

Pour la vue et le contrôleur, le "Controleur" PHP renvoie un Bean décrivant les données de la page. Ce Bean est récupéré par un autre controleur qui le convertit en un document XML. Ce document est récupéré par un autre contrôleur qui lui applique une transformation XSL et renvoie un contenu quelconque (chaine string, le XSL pouvant avoir généré du JSON, du HTML, du XML, du PDF ou autre). Ce contenu est récupéré par un autre contrôleur qui se charge de l'envoyer au client.
Les contrôleurs sont donc imbriquées par composition façon new GZipOutput(new XSLTServerSide(new XMLizer(new MyRealControler(...))));. Cela permet d'avoir une sacrée maîtrise sur l'imbrication des contrôleurs et de réutiliser énormément de choses (le "MyRealControleur" pourrait, par exemple, servir à démolir une usine, et je pourrait le réutiliser dans un autre contrôleur, dont le rôle serait par exemple de démolir l'usine actuellement construite pour la remplacer par une autre).

Au final, le Controleur est constitué de toutes les classes PHP. La vue se trouve dans des codes XSL (mais un autre moteur de template pourrait marcher aussi). Le Modèle se trouve dans le SGBD. On retrouve plus ou moins ce MVC, mais pas celui que j'avais pu trouver sur le web (genre OpenClassRoom).

Alors, MVC oui, mais sous la forme M=MySQL, V=Moteur de template (XSL, PHP, etc) et C=Classes PHP.



UML et conception papier

La nouvelle version d'Eclerd a nécessité... 4 tentatives de redémarrage! Là, c'est ma 5e (elle me semble bien meilleure d'ailleurs). Lors des 4 premières, j'ai voulu tout planifier sur papier en amont du code, genre "pour pas me laisser piéger par une mauvaise conception". C'est une intention louable. Niveau pratique, c'est à chier.

En fait, voici ce qu'il s'est alors passé:
• Je conçois mon jeu génial pendant quelques mois, avec plein de papier
• J'étoffe le tout avec des diagrammes UML, des cas d'exemple, des analyses etc
• Je me lance dans le code...
• ...je change les plans parce que j'avais zappé un truc
• Je reprends le code
• Je recorrige la conception
• etc
• La conception ne correspond plus à rien
• Le code s'est fermé de lui-même et ne permet plus d'accueillir de nouvelles idées, ou tout simplement de suivre la conception de départ
• Le projet fait "plouf"

Pour cette 5e reprise, j'ai fait différemment:
• Je définis une fonctionnalités suffisante
• Je mets cette fonctionnalité dans un bug tracker en lui créant 1 ricket; si d'autres idées me viennent, je crée d'autres tickets
• Je code cette fonctionnalité
• Je cloture cette fonctionnalité (en commitant le code dans un logiciel de versionning, Mercurial, puis en déployant le résultat en ligne dans une zone beta et en fermant le ticket associé)

Jusqu'à présent, c'est plutôt efficace. Le concept clef est que je ne sais pas dans quelle direction ira le jeu, mais que le jeu accepte les mises à jour en étant codé de la façon la plus "élémentaire" possible: chaque classe est responsable d'une et une seule chose. Si certaines classes font plusieurs trucs, alors je considère que, de l'extérieur, elles n'en font qu'un seul. Si je veux réutiliser l'un de ces trucs par la suite, je crée de nouvelles classes, je récupère le code de la classe "qui fait trop de trucs", je l'insère dans les nouvelles classes, et la classe "qui faisait trop de trucs" se sert de ces nouvelles classes. Chaque classe est donc utile (je n'ai pas des brouettes de classes juste parce que c'est mieux de découper toujours plus son code), mais chaque classe peut évoluer si un nouveau besoin apparait.

Donc, passer des semaines/mois sur ses plans de conception, pourquoi pas, mais le jeu ne ressemblera de toute façon pas au plan. S'il y ressemble, le risque est alors qu'il ne puisse pas évoluer par la suite (et il finira par devenir désuet).

Pfiouh, ça en fait du texte
Je crois que je vais redécouper ce message plus tard pour m'en resservir dans mes articles

[Akira777]

Bonjour Fortz !

Je vais essayer de faire court. Bien que mon expérience te dirais de faire de l'OO, si tu n'es pas à l'aise avec, fais du procédural. Quitte à apprendre de tes erreurs.

Si tu as un peu de temps devant toi, il sera toujours temps d'écrire certain composant en OO : messagerie, forum, module de combat (tout dépend de ton jeu).

Oui, l'OO t'apportera beaucoup, mais le plus important à mes yeux est la séparation de ton code.
Le MVC c'est très bien ! Si tu n'en as jamais fait, essai de l'appliquer et ne te lance pas dans de l'exotisme.

Pour ma part, j'ai pris l'habitude d'écrire mon code "Jeu" (métier) séparément de ma couche "Application" (mon site, mon app, ...).

Mon jeu devient une immense librairie qui est indépendante de toute couche web, c'est du code autonome qui est facilement réutilisable et facilement testable (Tests unitaires, composant par composant). Mon site utilise ma librairie de Jeu (le moteur en somme) est y applique les règles, à ce niveau j'y applique des tests d'intégration (combinaison de règle et de composants répondant à mon cahier des charges).

J'espère t'avoir éclairé

Edit après le message de Xenos : Excellent !

[fortz]

Merci beaucoup pour vos réponses, ça m'a fait de la lecture que j'AIME !

Tout d'abord, mon jeu serait très grossièrement un mélange d'un peu tout les jeux style Ogame, Travian, Grepolis, etc... donc logiquement procédural si j'ai bien compris ? J'en suis moi à ma quatrième tentative, et je suis maintenant prêt pour créer un jeu de cet ampleur je pense, en tout cas j'en ai largement la motivation.
Le fait de poser tout sur papier permet à moi et mon frère (qui fait le papier et moi plutot le web), de poser toutes nos idées (qui arrivent par millier :p) et de savoir jusqu'où va notre jeu et éventuellement les possibilités d'évolution et MAJ future. Par conséquent, on crée notre jeu dans un esprit qui accepte le changement et les nouveautés, et qui même les encourages, donc je tenterai de programmer le tout avec beaucoup d'application et en pensant constamment à la maintenabilité du jeu et à la possibilité de modification. L'avantage majeur est que pendant que mon frère conçoit une partie du jeu, je peux éventuellement programmer une autre partie indépendante, donc on ne passerait pas des mois et des mois sur feuille, je te rassure Xenos .
Je suis plutot à l'aise avec l'OO (mais plus en Java), donc il me suffit de lire un tuto sur l'OO PHP que j'ai très peu touché pour me mettre au point car les idées sont les mêmes. Je dispose du temps que je souhaite pour développer mon projet, j'ai donc le temps d'apprendre, et je ne cherche que ça, apprendre. Je pense aussi que l'OO me permet de coder plus proprement et me force à subdiviser mon travail en plusieurs petits morceaux qui représenteront surement des fonctionnalités ou groupes de fonctionnalités.
J'ai lu un article sur le versionning, où il conseillait de diviser son projet : d'un côté les pages en ligne et de l'autre les pages actuellement en modification et de tenir un bloc-notes où mettre l'ensemble des modifications depuis la dernière version. Je pense adopter ce système qui me paraît plutot intelligent.

J'avoue avoir l'impression d'être limité par le MVC, je sens que certaines des choses que je veux faire me sont plus difficiles avec le MVC, donc je me demande si je ne devrais pas partir sur le même principe en modifiant à ma sauce quelques trucs comme le disais Xenos. Pour ce qui est des procédure stockées du SGBD, j'ai vu ça en cours (avec le PLSQL) et j'avoue adorer ça cependant je n'ai jamais utilisé ça pour un site web et je ne saurais même pas comment faire. Y a-t-il un site où je peux créer mes procédures, fonctions, index, vues et qu'elles soient accessibles par mon code, ou alors carrément depuis mon code les créer ? Je serais pas contre une petite explication là-dessus (ou un lien vers un tuto conseillé).
Ton idée de librairie me plaît bien Akira, si je comprends bien tu sépare le code de ton jeu (combat, batiments, ressources, ...), de ton site (les pages d'affichages de contenu) ?

Xenos par contre j'avoue ne pas trop comprendre la fin de ta partie "Structure: MVC ou pas?", désolé

En tout cas, merci pour vos réponses complètes et rapides.

Cordialement

[Xenos]

Pour moi, tu te lances là dans un projet évolutif et à long terme. C'est donc à l'opposée du prototype. Du coup, je te conseillerai de partir sur de l'OO, pas du procédural.

Okay, pour fixer les idées, c'est une bonne chose que d'avoir un support (les garder juste "en tête", ça ne marche jamais ^^ ).

Huh... Je ne sais pas où t'as pioché cet article sur le versionning, mais si tu procèdes ainsi, tu vas te creuver pour rien Les "notes des modifications depuis la dernière version", c'est ce qu'on appelle les "messages de commit" (1 commit = 1 changement de code versionné, validé). Quant à diviser son projet, je pense que ce sera une bien plus grosse source d'emm*des que de bienfaits (quand tu auras besoin de ce genre de chose, cad dans 6 mois ou plus, tu pourras te tourner du coté des "branches" des logiciels de versionning).
Regarde du coté de ces logiciels de versionning d'ailleurs, plutôt que des méthodes manuelles. Pour ma part, j'utilise Mercurial (ou "hg", je te laisse chercher, ça se trouve facilement) couplé à Tortoise: Mercurial est le coeur du versionning (c'est le soft de versionning) et TortoseHg fournit une interface avec Windows et l'explorateur (très pratique et intuitif, cela évite de devoir manipuler de la ligne de commande tout le temps; et cette ligne de commande est quand même accessible si besoin).

La partie "Structure MVC" revient en gros au principe d'Akira (séparer la partie Web et le coeur de jeu, qui chez moi se trouve dans le SQL car je n'aime pas l'idée de faire des traitements de données dans le PHP).

Je n'ai pas de site explicatif sur les procédures (à part la doc MySQL, mais c'est pas très "tuto"). N'oublie pas qu'au final, MySQL (ou tout autre *SQL) n'est qu'un serveur (comme Apache en fait) que tu peux requêter avec un logiciel (genre MySQLWorkbench, mais je ne l'aime pas celui-là...) ou avec un module/librarie (façon PHP et sa librairie PDO ou MySQLi; c'est aussi ce que fait phpMyAdmin puisqu'il s'agit de code PHP). Donc la création de procédure fonctionne comme l'exécution de n'importe quelle requête SQL, la requête demande simplement au serveur de créer la procédure (au lieu de lui demander des données). Ensuite, une fois cette procédure créée, le jeu n'a plus qu'à l'utiliser pour dire "faire produire toutes les usines" (par exemple). Donc, inutile de vouloir créer des procédures "à la volée" ou "en temps réel": mieux vaut les créer hors du code du site (perso, j'ai un dossier "sql/*" à coté de mon "php/*") et s'en servir ensuite dans le site. C'est là où se trouve la similarité avec la notion de "librairy" d'Akira, ma bibliothèque étant l'ensemble des fichiers .sql qui déclarent les procédures avec la logique métier.

D'ailleurs, pour la gestion MySQL, j'utilise HeidiSQL (=phpMyAdmin mais en mieux fichu et hors du navigateur): on peut y créer les procédures SQL facilement via l'interface graphique (le contenu de la procédure est à rédiger soi-même, c'est du SQL classique, mais ce qui est "autour" est géré par HeidiSQL).

[fortz]

Ok pour l'OO
J'irai jeter un oeil sur Mercurial et TortoseHg dans la semaine, merci pour la piste. Donc si j'exécute mes procédures une fois puis après elles seront stockées et utilisables ou alors il faudra que je les execute à chaque fois ? (le principe d'une procédure stockée étant qu'elle n'a pas à être ré-exécuté j'en doute mais bon on sait jamais). Et si je met mon site sur un hébergeur, il n'y aura aucun problème tant qu'il y a un serveur type PhpMyAdmin ? Donc en gros si j'ai bien compris, vous créez vos procédures ce qui vous évite quelques lignes de code dans le PHP pur ?
J'irai aussi jeter un oeil à HeidiSQL, merci.

Cordialement, merci beaucoup pour votre réponse, cela m'aide beaucoup.

[Akira777]

Pour ma part, je ne pourrais que te conseiller de jeter un oeil à Git pour le versioning (majoritairement, les paquets PHP via composer sont hébergés sur cet environnement) et à Doctrine (ORM DataMapper) ou Eloquent (ORM Active Record) pour la gestion de ta SGBD (Une classe PHP == Une table en BDD).

Je n'ai jamais travaillé avec la méthodologie que te propose Xenos donc je ne me permettrai pas de comparer =)
Mais je ne préfère pas être dépendant d'une SGBD. Tout ce que je peux te proposer c'est de jeter un oeil aux solutions proposées ! Tu ne pourras qu'être gagnant ;p

PS: Xenos, comment tu fais pour Mocker et lancer tes tests avec ta méthodologie ? Je suis très curieux !

[fortz]

Très bien j'y jetterai un oeil également, le choix va être dur ! Merci pour toute vos réponses, je reviens vers vous dès que je me serai renseigné là-dessus

Cordialement

[Xenos]

Une procédure stockée, comme son nom l'indiquée, est stockée sur le serveur MySQL: on la crée une fois, et on peut l'exécuter autant de fois que nécessaire, même après s'être déconnecté puis reconnecté du serveur MySQL (donc, d'une page PHP à l'autre).

Et tu fais mouche pour l'objectif: j'allège mes codes PHP de toutes les boucles et autres traitements de données.

Typiquement, Une classe PHP == Une table en BDD, je trouve que c'est très peu pratique car le code PHP devient un pur reflet du code SQL. En cela, je trouve que cela rend au contraire très dépendant du SGBD, et surtout de sa structure interne. Avec les colonnes virtuelles, et les vues, ça se passe comment?

Être obligé de lire les données du SQL, d'en faire des objets PHP, de traiter ces objets PHP, parfois de les compléter, puis de les renvoyer au SQL pour qu'il les sauve... Même s'il y a plein de frameworks qui font ça, je préfère éviter un tel trafic réseau et dire au SQL "vas-y, je veux ça" (ça rappellera peut-être l'approche "East" débattue il y a un moment ^^).
C'est d'ailleurs un soucis qu'on a au taff: on se retrouve avec des cas où on demande une liste d'objets au SQL, qui nous en retourne par exemple un bon millier, puis on fait des traitements PHP, et enfin, on demande au SQL de compléter ces 1.000 objets avec d'autres infos... Et là, c'est le drame: le serveur SQL ne sait pas répondre à des requêtes type "SELECT ... FROM ... WHERE id IN (...1000 ids...)".

Niveau implémentation, j'ai 1 fichier SQL par procédure, exécuté automatiquement à sa sauvegarde (AutoHotkey) en local, et exécuté automatiquement également lors du déploiement en ligne (Mage ou Magallanes).

Je peux te donner les exemples de code si tu veux? Je n'ai pas trop cherché de doc sur le net relative à mon approche, donc bon, c'est un peu expérimental et si cela se trouve je me plante (l'autre approche d'Akira est probablement plus documentée que la mienne). Si je me plante pas et que j'arrive à tenir un jeu viable comme ça, j'essayerai de présenter cette approche de façon plus formelle.

---

[Edit]

Pour les mocks, j'allais oublier, même si je n'en ai pas encore fait, je procèderai ainsi:
• Coté PHP, le serveur MySQL est un "serveur-API", donc je peut le mocker soit en créant un faux serveur MySQL (un peu tendu quand même), soit avec un serveur MySQL dont les procédures renvoient toujours les mêmes résultats.
• Coté MySQL (vu que j'y ai de la logique je serai censé pouvoir le tester), je créerai un jeu de données bidon, puis j'exécuterai la procédure SQL et je vérifierai l'impact sur les données de la BDD (le tout dans une base dédiée aux tests). Mais là, je reconnais ne pas connaitre de Framework dédié à ce genre de test. Après, ça se résume à "1 fichier SQL de la procédure + 1 fichier SQL de test qui initialise les données puis appelle la procédure puis vérifie son résultat et renvoie TRUE ou FALSE". Mais il n'y aura pas de code coverage (en tous cas, je ne connais pas d'équivalent "SQLunit" à PHPunit).

[fortz]

Donc en gros une procédure SQL correspondrait à une fonction PHP si j'ai bien compris ? Je veux bien un exemple oui stp.
Je me suis renseigné sur les logiciels de versioning et j'avoue avoir assez apprécié le système de Tortoise qui est assez facile et intuitif en effet. Je me suis servi de SVN en cours donc je ne suis pas totalement de le vague concernant les lignes de commandes pour le versioning donc à voir pour plus tard, si je m'en sens le besoin de l'utiliser.
Pour Tortoise, si j'ai bien compris, tu as le versionning sur ton ordi et puis à tout moment tu peux le mettre sur internet dans le dépot ? donc si je travaille seul en local ca peut être utile aussi pour le moment ?
Pour ce qui est des lociciels d'aide pour la gestion SGBD, je pense pouvoir m'en sortir sans ça pour le moment, mais bien-sûr j'ai tout noté pour ne rien perdre

Cordialement