Oui, donc si tu t'es jeté sur un système tout-intégré-tout-en-un, tu fais comment pour maintenant implémenter ces pushs (qui sont du JS plutôt que de l'HTML)?
Si tu veux faire un Agar-like, je pense qu'il vaut mieux dev ton jeu statique d'abord, pour ensuite ajouter une couche de dynamique par dessus, plutôt que d'essayer de se lancer dans du dynamique du premier coup, surtout si tu ne connais pas les technos.
Dis autrement, mieux vaut dev des petites features une à une (qui collent accessoirement aux standards) plutôt que de vouloir faire un jeu "d'un bloc", même si tu "sais déjà" la liste des prochaines petites features: faut pas dev les petites features de maintenant en prévision des petites features à venir.
Je vais prendre l'exemple de la nouvelle v1.0.0 d'eclerd. Dans le jeu, chaque usine possède un stock contenant des ressources. Pour l'instant, ce stock est illimité en capacité. Je sais que, à l'avenir, je veux limiter ce stock (pour ne pas stocker une infinité de ressources dans un seul bâtiment). Pour autant, rien ni dans mes codes ni dans mon archi actuels n'est "prévu" pour accueillir cette feature. C'est cela qui me permet d'avoir un code lisible et compréhensible, tout en étant extensible (parce que si je change d'avis et que je laisse tomber la limite, je n'ai pas de "bout de code mort", prévu pour une feature qui ne sera jamais faite). Quand j'ai codé mes stocks, je me suis restreint à "je veux stocker des ressources dans les usines, c'est tout".
La même approche sur un jeu où, par exemple, on incarne un personnage se déplaçant dans une carte du monde avec d'autres joueurs en temps réel consiste à dire "je fais la carte, et je la visualise {{point}}". Puis "J'ajoute mon personnage". "Je rend le personnage déplaçable". "J'affiche les autres" (on pourrait inverser l'ordre de ces deux features). "J'ajoute un morceau de code dédié à le rendre temps-réel".
Ca me semble bien plus facile de dev ainsi son projet. "Prévoir" que telle techno sera utilisé à tel endroit avant qu'on en ait vraiment besoin n'est pas une solution efficace.
De plus, cela permet de déceler très tôt une erreur d'archi. Si je reprends l'exemple précédent, je fais mon jeu temp-réel en HTML statique via une classe qui génère tout le code HTML de la page. Par la suite, je veux mettre du dynamique. Soit je le met en sur-couche, soit j'édite le code HTML, soit je dois éditer le code HTML. Dans ce second cas, je vais devoir en éditer seulement une partie (en gros, remplacer les <span>Contenu Statique</span> par mes <span>{{Contenu dynamique}}</span>, je ne sais plus quel Framework JS a ce genre d'approche). Du coup, on verra vite le problème "le code HTML est généré par une seule classe", et on devra affiner l'archi pour séparer le pattern HTML et les data (initialement statiques, maintenant dynamiques).
En résumé
La question même de ce sujet ("quelles technos pour vos jeux web?") perd un élément capital de vue: le temps. "Quelle techno avez-vous mis en place à quel moment".
C'est ce qui ressort d'ailleurs dans la question de Max:
Une technologie ne devient une solution qu'une fois le problème rencontré et défini.
Et quand tu dis:
J'en comprends "mes technos sont cascadés et je ne pourrais pas en intégrer de nouvelles plus tard". Ce qui m'a fait déboucher sur "séparer les rôles est peut-être difficile au début, mais on y gagne énormément sur la maintenance". Et également sur le fait qu'un framework (peu importe si c'est une masse de code dans laquelle on englobe son code métier ou des modules autonomes) n'a aucun intérêt tant que n'as pas un problème à résoudre dans ton projet.
Si tu veux faire un Agar-like, je pense qu'il vaut mieux dev ton jeu statique d'abord, pour ensuite ajouter une couche de dynamique par dessus, plutôt que d'essayer de se lancer dans du dynamique du premier coup, surtout si tu ne connais pas les technos.
Dis autrement, mieux vaut dev des petites features une à une (qui collent accessoirement aux standards) plutôt que de vouloir faire un jeu "d'un bloc", même si tu "sais déjà" la liste des prochaines petites features: faut pas dev les petites features de maintenant en prévision des petites features à venir.
Je vais prendre l'exemple de la nouvelle v1.0.0 d'eclerd. Dans le jeu, chaque usine possède un stock contenant des ressources. Pour l'instant, ce stock est illimité en capacité. Je sais que, à l'avenir, je veux limiter ce stock (pour ne pas stocker une infinité de ressources dans un seul bâtiment). Pour autant, rien ni dans mes codes ni dans mon archi actuels n'est "prévu" pour accueillir cette feature. C'est cela qui me permet d'avoir un code lisible et compréhensible, tout en étant extensible (parce que si je change d'avis et que je laisse tomber la limite, je n'ai pas de "bout de code mort", prévu pour une feature qui ne sera jamais faite). Quand j'ai codé mes stocks, je me suis restreint à "je veux stocker des ressources dans les usines, c'est tout".
La même approche sur un jeu où, par exemple, on incarne un personnage se déplaçant dans une carte du monde avec d'autres joueurs en temps réel consiste à dire "je fais la carte, et je la visualise {{point}}". Puis "J'ajoute mon personnage". "Je rend le personnage déplaçable". "J'affiche les autres" (on pourrait inverser l'ordre de ces deux features). "J'ajoute un morceau de code dédié à le rendre temps-réel".
Ca me semble bien plus facile de dev ainsi son projet. "Prévoir" que telle techno sera utilisé à tel endroit avant qu'on en ait vraiment besoin n'est pas une solution efficace.
De plus, cela permet de déceler très tôt une erreur d'archi. Si je reprends l'exemple précédent, je fais mon jeu temp-réel en HTML statique via une classe qui génère tout le code HTML de la page. Par la suite, je veux mettre du dynamique. Soit je le met en sur-couche, soit j'édite le code HTML, soit je dois éditer le code HTML. Dans ce second cas, je vais devoir en éditer seulement une partie (en gros, remplacer les <span>Contenu Statique</span> par mes <span>{{Contenu dynamique}}</span>, je ne sais plus quel Framework JS a ce genre d'approche). Du coup, on verra vite le problème "le code HTML est généré par une seule classe", et on devra affiner l'archi pour séparer le pattern HTML et les data (initialement statiques, maintenant dynamiques).
En résumé
La question même de ce sujet ("quelles technos pour vos jeux web?") perd un élément capital de vue: le temps. "Quelle techno avez-vous mis en place à quel moment".
C'est ce qui ressort d'ailleurs dans la question de Max:
Citation :Angular c'est utile pour un jeu de gestion en PHP ou c'est trop 'Artillerie lourde' pour rien ?
J'ai bien envie d'apprendre mais je me demande si ça vaut le coup :/
Une technologie ne devient une solution qu'une fois le problème rencontré et défini.
Et quand tu dis:
Citation : Mais il faut le coupler à Flux ou autre système pour avoir un truc complet bien sûr.
J'en comprends "mes technos sont cascadés et je ne pourrais pas en intégrer de nouvelles plus tard". Ce qui m'a fait déboucher sur "séparer les rôles est peut-être difficile au début, mais on y gagne énormément sur la maintenance". Et également sur le fait qu'un framework (peu importe si c'est une masse de code dans laquelle on englobe son code métier ou des modules autonomes) n'a aucun intérêt tant que n'as pas un problème à résoudre dans ton projet.