Avec quoi vous développez votre jeu ?

[niahoo]

explique aux gens qui ont pondu agar.io qu'il aurait mieux valu faire une version ou tu spam F5, ça paraît complètement insensé non

Oui, parce que ce que j'essaie d'expliquer, c'est qu'il n'est pas utile de se tourner vers Agar.io tant qu'on n'a pas rencontré le problème "mes utilisateurs doivent spam F5", d'autant plus si on ne maitrise pas déjà la techno en question.

J'ai pas compris. Mettons que j'ai une idée de jeu qui aie de fortes similitudes avec agar.io (et c'est le cas). Qu'est que je suis censé comprendre à la lecture du topic, moi qui vient de découvrir jeuweb sur google ?

edit: hum, après relecture, j'ai l'impression que tu ne connais pas agar.io et que tu penses que c'est un outil de messaging. C'est un jeu : http://agar.io/

[Xenos]

Ok, j'avais cru que c'était un framework JS ou assimilé, je ne savais pas que c'était un jeu.

Non, je ne dis pas que le jeu Agar devrait être un spam F5, en revanche, je dis que Agar devrait être développé façon:
• On fait le jeu en HTML classique
• Les joueurs doivent spam F5, c'est nul niveau expérience utilisateur
• On ajoute une couche supplémentaire par-dessus le HTML pour éviter ce spam F5

Avec ce genre d'approche, si HTML a un push intégré, il suffira de virer la "sur"-couche (qu'est pas forcément "sur") et de la remplacer par la couche HTML6.

[niahoo]

Avec ce genre d'approche, si HTML a un push intégré, il suffira de virer la "sur"-couche (qu'est pas forcément "sur") et de la remplacer par la couche HTML6.

Ben ... EventSource et WebSockets ... HTML5 a un push intégré. Je pige pas, désolé.

[Xenos]

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:

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:

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.

[Max72]

[HS encore un coup...]
Ton post m'a fait un déclic Xenos, vraiment.
Pour le moment, je code exactement comme tu le décris : Je pense 'à plus tard' :
Si je créé une classe (Router ou Batiments ou User .......), je cherche absolument à l'implémenter d'un coup et à y intégrer le code qui me sera SURÊMENT utile plus tard. Et bien je n'avance pas, car plus de la moitié du code m'est inutile en l'état, et le fait de ne voir rien avancer me démotive énormément..
Merci
[/HS]

[Xenos]

Ravi d'avoir aidé

J'ai viandé la reprise d'eclerd 3x de suite avec cette méthode "prévisionnelle". La 4e reprise, celle actuellement en cours, est en bien meilleure forme et avance bien mieux que ces 3 ratages! Ca rejoint l'article Anticipation et adaptation que j'avais sorti il y a quelques temps (hop, auto-promo).

---

Et je n'avais pas fait gaffe, mais la question étant "Avec quoi..." et non "En quels langages/technos...", j'ajouterai que j'utilise quelques logiciels dont j'aurai effectivement du mal à me passer maintenant:
• IDE pour l'appli (NetBeans)
• IDE SQL (HeidiSQL) pour les brouillons de queries de BDD
• WAMP pour la stack web
• SonarQube pour le suivi qualité
• Magallanes pour le déploiement (pas encore utilisé à fond, juste essayé), mais je passerait peut-être sur Jenkins
• Doxygen pour la génération de documentation PHP (XSLDocumentator, pour la doc des XSL, ne m'est pas encore nécessaire)
• Mercurial pour le versioning (et tortoiseHg parce que la ligne de commande, c'est pas toujours le plus pratique)
• Mantis bugtracker pour le suivi des bugs et features

(p***, on m'aurai dit y'a 3 ans que j'utiliserai tout ça pour Eclerd, je ne l'aurai pas cru)

[niahoo]

Le problème quand on ne sait pas de quoi on parle, c'est qu'on a vite fait de dire des bêtises. Je vais essayer de répondre point par point, mais avant je voudrais faire quelques mises au point :


1. Comme déjà dit, agar.io est un jeu multijoueurs en temps réel dans le navigateur, et non pas une librairie javascript.

2. React est une librairie qui permet de définir des vues en javascript. Il n'y a pas de notion de modèle, de controlleur ou autre ; seulement des données reçues rendues sous forme de HTML.

3. Flux est un pattern architectural définissant les échanges d'informations au sein d'une application javascript s'exécutant dans le navigateur ; et non pas une librairie.

Ceci étant dit …

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)?

Comme déjà dit, avec Phoenix (et tout bon framework qui se respecte) tu peux à tout moment changer de système de push pour un autre de ton choix, même une solution maison. Comme avec symfony tu peux virer twig pour mettre blade, smarty, ou une solution personnelle. Si la norme HTML propose un système de push à base de balises HTML dans le futur (ça serait bizarre mais bon), c'est pareil, je ne vois pas ce qu'il m'empêcherait de m'en servir.

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.

Mais bien sûr. Donc déjà quand on se lance dans un projet c'est toujours utile de connaître les technos. Pour ma part ça va, et pour les gens qui ne seraient pas à l'aise avec push : lancez-vous. C'est vraiment pas compliqué. Sauf si vous voulez implémenter Expert Comptable Simulator 2016. Ensuite, je ne comprends pas l'intérêt de perdre mon temps à afficher l'état courant du jeu sous forme statique. OK, je peux le faire, ça me prend 5 minutes. Si vraiment ça te fait plaisir je peux l'implémenter, le commiter, puis foutre ça à la corbeille. Mais à quoi bon ?

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.

Désolé mais tes arguments ne sont pas cohérents. Tu peux développer un jeu de façon très modulaire, en n'implémentant que ce dont tu te sers déjà, en utilisant un framework comme Angular ou React. Tu peux très bien implémenter une première version de Déclaration D'Impôts Championship 2 avec un stock illimité pour tes notes de frais, et ajouter un stock limité dans une version suivante. Et pour faire ça, tu peux choisir d'afficher tout ça avec Twig, React, XSL ou ce que tu veux. Je ne vois pas le rapport.

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).

J'ai pas compris. Tu as du code qui génère à la fois les données et du HTML ? Non, tu dis qu tu utilises des vues XSL et que ton serveur renvoie des données XML. Mon serveur envoie des données JSON et React génère du HTML avec ces données. À chaque fois qu'il reçoit des données, il régénère le HTML qui va bien. L'archi est assez fine, chaque composant de l'interface reçoit ses propres données et s'occupe de son bout de HTML.

Et quand tu dis:

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".

Quand je dis qu'il faut le coupler à Flux c'est que justement React est une librairie qui ne s'occupe que des vues. Donc en terme de séparation des rôles on tient quelque chose de bien. Et je peux les remplacer par Ractive, Handlebars ou autre si j'en ai envie parce que justement ce ne sont que des vues et il existe pleins de choix pour faire ça. Flux propose de choisir des composants pour les vues, les input du joueur et les objets chargés de garder l'état du jeu en mémoire. C'est justement une architecture qui propose de découpler tout ça et que chaque composant s'occupe tranquilement de sa partie en définissant une API pour communiquer avec les autres composants.

Du coup je ne sais pas ce que tu entends par "cascadés" mais s'il y a bien un défaut qu'on peut reprocher à l'écosystème javascript c'est bien le trop plein de solutions et non pas le couplage trop important de celles-ci.

Voilà, désolé de mon ton pas super gentil, mais à la lecture de ton post cet aprèm où je ne pouvais pas répondre, puis à la lecture de ton article qui dit qu'en gros il ne faut pas penser le code à l'avance mais l'adapter (et au passage que les test unitaires sont inutiles tant qu'il n'y a pas de bugs …) je trouve que ça promeut trop les jeux-formulaires par dessus lesquels on va rajouter une couche de JS après coup parce qu'on a envie que ça soit dynamique. C'est ce qu'on faisait il y a dix ans et c'est pas terrible. Les jeux-formulaires aussi d'ailleurs, c'est pas terrible et c'est daté.

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.

« Surtout n'utilise pas de framework. C'est sale. Code tout toi même. »

Le meilleur code qui soit, c'est "pas de code". Si tu dois écrire du code, c'est que tu dois résoudre un problème. Si du code existe déjà pour résoudre ce problème, et qu'il te semble de qualité, utilises-le, et code ce pourquoi il n'y à pas encore de solution (le moteur de ton jeu).

[Xenos]

J'ai effectivement eu le tort de mélanger deux points différents: le couplage et l'utilité. Le couplage n'étant pas la question du topic (et comme je ne connais effectivement pas assez ces FW pour en juger), je la laisserai de coté (mais ok, apparemment, les FW JS cités sont assez centrés sur une seule tâche).

« Surtout n'utilise pas de framework. C'est sale. Code tout toi même. »

Tu déformes, puisque je dis "Surtout ne te lance pas dans des framework/technos juste parce que c'est la mode ou en prévision de ce dont éventuellement tu auras besoin, mais lance-toi dans la techno qui répond au problème que tu rencontres en ce moment".
C'est équivalent à ton "pas de code c'est le mieux", et coller au plus près des standards web fera 0 code supplémentaire. Après, tu peux ajouter du framework si t'as un problème qui n'est pas réglé par le standard: ça t'ajouteras du code, mais sans sa maintenance. Et coder à la main si t'en n'a pas trouvé (généralement, le code métier).

Il me semble qu'on est donc tous deux d'accord pour dire "On ne doit avoir que le code qui solutionne les problèmes rencontrés" (que ce soit celui du navigateur, d'un framework, ou le notre)? Donc pour en revenir au point de départ, ça ne sert à rien de conseiller des technos à quelqu'un sans savoir quel est le problème exact à résoudre. Dire à quelqu'un "installe React/jQuery/mesGenouxJS puis dev ton jeu", ou même "ça te facilitera le dev", ça me semble anormal voire faux (ça peut être sympa de les tester ces technos, mais ça n'avancera pas le jeu). Dire "Si tu veux intégrer une réponse JSON dans ta page HTML, prend React, c'est étudié pour ça", pourquoi pas.

Quant aux jeu-formulaires, ils ont l'avantage d'être vite développé et de n'avir que le coeur de métier. Après, tu peux regretter que leur Progressive Enhancement n'ait pas suivit. Tiens, ça ressemble bien à "n'ajoute du code qu'après avoir rencontré le problème"

[Kassak]

Ma question de départ n'était pas de me dire avec quoi je dois développer mon jeu, mais d'avoir une vue d'ensemble sur ce que vous utilisez.

@Xenos, tu n'as, je pense, pas la bonne vision de ce qu'est un Framework. Tu ne vas pas utiliser Symfony2 par exemple après 2 mois de développement parce que tu as rencontré un problème que seul SF2 peut résoudre. C'est juste un choix de départ, et faut voir ça comme une énorme boite à outils qui te fera gagner un temps considérable quand tu le maitrises.

Il faut pour ça avoir une vue d'ensemble de son projet, et pas commencer par développer la couche html, puis y ajouter la couche js, puis y ajouter la couche serveur puis.... Chacun sa méthode mais ce n'est pas la mienne.

Le meilleur code qui soit, c'est "pas de code"

C'est tout le principe d'un FW ou autre. Coder un espace membre ? Tu ne rencontra aucun problème, c'est bête et chiant. SF2 te génères tout en 2s, avec du code sûrement mieux que le tient, pourquoi perdre du temps ?
Ça te permet de travailler uniquement sur ton jeu, le reste, c'est déjà fait.

Pour en revenir au sujet, il y a donc Angular et React qui m'interessent, à tester et voir si j'en trouve l'utilité. Angular est assez énorme, je pense qu'on peut faire tout et n'importe quoi avec, mais React, vous avez un exemple concret à me donner ?

[niahoo]

Un exemple avec React

D'autres exemples sur cette page, à la rubrique « Open-Source Demos ».

(Sinon concernant les frameworks, d'accord avec Kassak. Non ça ne me paraît pas erroné de conseiller d'emblée un framework spécifique parce-que contrairement à ce que tu as dit, un peu d'anticipation ne fait pas de mal quand t'en est à ton nième projet web.)