Jeu navigateur en 2016 : quelles technologies?

[Kaitos]

Bonjour à tous,

Moi aussi je me lance dans la création d'un jeu vidéo. J'ai lu pas mal de sujets sur ce forum mais sans trouver de réponse convaincante à mes questions. La raison pour laquelle je créé ce topic !

En effet, je souhaite créer un jeu sur navigateur dont une partie est en temps réel, j'aimerais donc exploiter les websockets.
Mais je n'ai pas envie de coder une application avec un back-end full Node.js (à cause de sa maintenabilité qui me semble assez difficile, et parce que la partie temps réel correspond à 1/3 des fonctionnalités et que je préfère coder en Java ou PHP si les mécaniques sont synchrones ).

C'est pourquoi j'ai pensé a créer une architecture décomposée en 2 parties:

Partie en temps réel :
BACK-END : Node.js (+express+socket.io+...)
FRONT-END : HTML (+js & canvas)

Partie "web classique" :
BACK-END : PHP (+CodeIgniter) + HTML5
FRONT-END : HTML + js

BDD
Le tout reposant sur une même BDD : postgreSQL

1er questionnement
J'aimerais intégrer un chat dans la partie "web classique", donc pour le coup, le PHP n'est pas très adapté... Serait-il plus adapté de coder un back-end full Node.js?
Le temps de réponse du chat n'est pas un  problème, si il est de 2-3 secondes, donc il m'est possible de le coder en PHP. Mais n'est-ce pas inadapté de coder un chat en PHP alors qu'un serveur en Node.js tourne à côté?

2ème questionnement
J'ai des doutes après avoir pris connaissance de nouvelles technologies comme les frameworks java "Play" et "Grails".
Et je me demande si ce ne sont pas de meilleurs choix, sachant que j'ai à peu près le même niveau dans tous les langages (PHP, Java, Javascript).
Sachant que l'architecture ne serait pas décomposée en 2 si j'utilisai Play par exemple, ce qui serait peut-être plus cohérent.

3ème questionnement
CodeIgniter est-il adapté? Ou dois-je passer sur le framework Laravel? Y-a t-il un framework PHP adapté au jeu video si ce n'est un framework flexible ?

Avez-vous donc des remarques concernant ces questionnements ?

Merci beaucoup.

Edit : Je cherche avant tout : la productivité et la maintenabilité!

[Xenos]

Salut,

J'aimerais intégrer un chat dans la partie "web classique"

Perso, j'irai d'abord voir ce qui existe déjà comme système de chat "prêt à l'emploi", et je creuserai pour l'intégrer au jeu. Par exemple, la simple ouverture d'un chat Discord (ou autre) pourrait suffire (tant qu'il n'y a pas de joueur qui chat, autant ne pas perdre du temps pour en créer un!). A défaut, comme pour le forum, j'irai voir ce qui existe comme "CMS" déjà prêt, je l'installerai et je ferai le lien avec le jeu. Ce n'est pas tant "le coder en JS ou en PHP" le problème, mais bien le fait de le coder. Ce n'est pas le coeur du jeu, inutile donc de perdre du temps dessus. D'ailleurs, pourquoi en as-tu besoin de ce chat? S'il n'y a pas de jeu, il n'y a pas de joueurs et donc pas de besoin de chat. Si cela se trouve, les joueurs n'auront même pas envie/besoin de cette fonctionnalité (et en fait, un Twitter suffit).

Les FW (Frameworks), je ne sais pas, je n'ai pas d'expérience pour te dire lequel colle le mieux. Perso, je ne m'attarderai pas des plombes dessus si le but est surtout d'avoir un jeu qui tourne et qui est joué (ces deux choses bouffent énormément de temps toutes seules). Il te faut le FW qui colle à ce que tu souhaites faire de ton gameplay, donc il faudrait avoir la liste des éléments de base (la plus courte possible donc) pour déterminer lequel collerait le mieux (si l'un colle).

[Kaitos]

Tout d'abord, merci d'avoir répondu aussi rapidement !

Le chat va permettre aux joueurs de la même équipe de communiquer afin d’établir des stratégies.
C'est un élément très important, il faut donc que je trouve un outil de chat externe permettant de créer une room privée par équipe (si je choisis de ne pas coder cette fonctionnalité).
Mon jeu comportera aussi un forum, que je pensais externaliser au départ (pour me concentrer sur le jeu)

Au sujet des deux parties :

L'interface "web classique" est l'interface permettant de gérer les personnages, leurs équipements, et leurs apprendre les compétences. Cette interface permet aussi de  gérer les équipes constituant des joueurs et la distribution des ressources collectées, afficher les news etc... Des fonctionnalités classiques du du web, avec des tableaux, des boutons etc. Tous les framework que je connais me semblent correspondre à cette partie là.

L'interface "temps réel" est une carte composée uniquement de cases que le joueur voit de haut. Les personnages des différents joueurs s'affrontent sur ces grandes cartes. Les joueurs peuvent se déplacer, attaquer, capturer des cases etc... (exemple : advance wars)
Je pensais donc utiliser un simple tableau HTML, pour l'affichage des sprites, détecter les clics etc. Et par dessus, un canvas transparent permettant d'afficher les animations du jeu. Mon jeu étant relativement statique, cela me semble être le choix le plus productif car relativement simple à mettre en oeuvre.
Mais si il existe des framework 2D case par case très simple a utiliser, je serais intéressant de les connaitre (je n'en ai pas trouvé).

Merci !

Edit : Oui, en tout cas ce n'est pas le coeur du jeu, mais ça me semble primordial de mettre en place le chat rapidement. Peut être par sur la première version, mais juste après. Et j'aimerai choisir la bonne technologie en fonction.

[Xenos]

Sur Ogame (oui, je reprends ce vieil exemple, crotte!) on n'avait pas besoin de s'embêter avec un chat intégré au jeu et avec 40 fonctionnalité: les teams se sont juste construites sur MSN (Skype/Discord maintenant), et c'était largement suffisant (idem pour les jeux AAA d'ailleurs, type Medal Of Honor).
A mon avis, tu auras juste besoin d'un forum (installe un existant) pour que les teams s'amorcent. Après, les gens qui veulent pousser le jeu jusqu'à faire des stratégies d'équipes seront assez grands pour échanger un Skype ou un Discord. Ne fais pas ta techno de jeu/stack de jeu en fonction de ce petit élément annexe.

Je pense qu'en effet, un tableau HTML et tu peux go (sans même un canvas d'animation: tu as déjà ces animations de prêtes?). Voit avec Argorate (Matrix), car son jeu ressemble à ce vers quoi tu te diriges. Il saura te donner les problèmes et pièges qu'il a rencontrés. Et le "Framework" case par case 2D le plus simple que je connaisse, c'est le SVG :p

[Kaitos]

Voit avec Argorate (Matrix), car son jeu ressemble à ce vers quoi tu te diriges. Il saura te donner les problèmes et pièges qu'il a rencontrés.

Super merci, je vais le contacter rapidement .

Et le "Framework" case par case 2D le plus simple que je connaisse, c'est le SVG :p

Le SVG, c'est à dire? ^^

tu as déjà ces animations de prêtes?

Non d'un point de vue graphique, rien n'est fait, d'ailleurs du point de vue du développement rien non plus encore...
Je suis toujours en phase de conception, j'attaque d'ailleurs bientôt le prototype... (d'où toutes ces questions qui m’embarrassent !)

Et par hasard tu ne connais pas les frameworks java "Play" ou "Grails"? Ça serait intéressant d'avoir des retours de personnes ayant créé des jeux avec ce genre d'outil =).
La plupart du temps à ce que je vois, les personnes sur ce forum optent pour le PHP côté back-end, mais quelles sont les grandes raisons de leurs choix? La productivité ? Le prix de l’hébergement ? La communauté? La documentation? Depuis PHP7, ça me semble encore plus intéressant d'un côté!
Et pourquoi ne pas non plus se tourner vers du full JS (NodeJS+React par exemple)?

Merci encore.

[Xenos]

Le SVG est le HTML de l'image: c'est un langage d'imagerie vectorielle donc à base de formes géométriques (à l'inverse des images PNG, raster, à base de pixels). Ce sui est très pratique avec le SVG, c'est qu'il s'intègre très bien au HTML. C'est ce que j'utilise maintenant pour Eclerd.

Ca conserve un des l'un des inconvénients de canvas et des images: c'est un bloc, donc ce ne sera pas responsive. Mais cela a l'énorme avantage de manipuler des éléments DOM, et de pouvoir donc rendre des cases, des objets, des bâtiments etc cliquables comme des liens classiques. C'est également sympa pour permettre de l'animation fluide et à temps variable (ie: plus ou moins rapide [ralenti]). Ca a déjà été traité qq part sur le forum, et tu peux gratter un peu mon blog à ce sujet (dont l'exemple du brouillard de guerre, qui ne changera pas le caractère inadapté d'une telle carte isométrique).

Si tu n'es qu'à la phase de prototypage et d'amorce, ne t'encombre pas de trucs inutiles: j'ai tenté plusieurs fois de refaire ma v0 d'eclerd en plus propre, et chaque tentative a foirée parce que j'ai constamment tourné en rond et perdu du temps à chercher "et si je prends ce FW? Et pour plus tard, comment je ferai? Et après? Et si gnagna...?". A l'inverse, sur la v0, j'ai été pragmatique (mais sans expérience de code): c'est en ligne, et c'est (on va dire) jouable. Ce n'est que récemment, au dernier reboot d'Eclerd (cf lien précédent) que j'ai repris ce pragmatisme et que j'ai arrêté de tourner en rond à vouloir faire "le truc parfait pour plus tard". Et c'est le seul reboot qui, jusqu'ici, a démarré et est en ligne.

Et non, je n'ai pas dev ces sites en Java, simplement car l'hébergeur ne le propose pas (et je ne veux pas passer des semaines et des euros à migrer tout mon bordel sur un dédié, à installer un serveur Java, et à m'apercevoir finalement que cela ne sera pas mieux qu'un Apache+PHP). La raison de PHP est souvent la simplicité de démarrage des projets et du dev (c'est très abordable comme langage je trouve, bien qu'il y ait des incohérences avec le recul [genre "on s'appelle PHP alors on va faire array_map(callback, array) mais array_filter(array, callback); rien d'insurmontable]).

Le Full JS est hyper-récent, donc pas encore bien répandu. De mon point de vue, à moins d'avoir vraiment une équipe de dev, c'est un peu "la techno qui brille du moment". C'est sûrement amusant à découvrir et à utiliser, mais je doute de l'efficacité de la chose.

[QuentinC]

Tu peux combiner toutes les technos comme tu veux, mais tu verras à la longue que c'est quand même vachement mieux et vachement plus simple à maintenir si tu as tout qui tourne avec la même chose.

Petite astuce, si vous combinez un apache+php et du node.js, utilisez la proxification proposée par apache (directive ProxyPass), ça vous évitera d'ouvrir l'app node sur un autre port (genre 3000).
Ceux qui ont un réseau capricieux vous remercieront.... les boss peut-être un peu moins si les joueurs jouent au boulot, mais c'est pas votre problème.

La plupart du temps à ce que je vois, les personnes sur ce forum optent pour le PHP côté back-end, mais quelles sont les grandes raisons de leurs choix?

Probablement que c'est effectivement l'abondance d'hébergeurs proposant php à un prix très avantageux, par rapport à un hébergement comparable pour une autre techno.
Malgré la grande popularité du langage, même les hébergeurs python sont largement derrière.

Pour héberger du Node.js il faut se diriger vers du service cloud, et le prix n'est carrément pas le même; ou alors du serveur dédié, et là il faut maîtriser.
Et pour Java on n'en parle même pas.

[Thêta Tau Tau]

Pour moi la première raison c'est qu'il y a plus de monde qui maitrise PHP que d'autres techno.

[Patatruc]

Je n'ai pas bien compris ce qu'il y a de "temps réel" à part le tchat (tu évoques une proportion de 1/3).

Si c'est un aspect important du jeu, il faut effectivement bien réfléchir sur la plateforme avant de te lancer.

Node.js ne soutient pas la comparaison avec PHP pour ce qui est de la fréquence d'utilisation, des exemples de code et de l'aide que tu peux recevoir. En revanche c'est parfaitement adapté au temps réel. Si cet aspect est important dans ton jeu et que tu espères une fluidité minimale, tu risques de beaucoup galérer en PHP avec des solutions de type "Système D". Davantage que la galère de te lancer dans une plateforme moins utilisée / documentée mais quasiment "faite pour ça".

Tu devrais peut-être faire un petit essai avant de te décider. Node.js est très simple à utiliser pour générer des pages dynamiques basées sur des templates (petit exemple avec express + jade).

Un aspect assez pénible est son "asynchronisme", inhérent à javascript. Mais c'est surtout une question d'habitude et des outils existent pour faciliter ce style de programmation (promises ou librairie async).

Si tu fais un petit essai avec quelques pages et un tchat minimaliste, ça te donnera une idée sur la "faisabilité" de la chose. Et c'est une expérience assez ludique en soi.

[Kaitos]

Ca a déjà été traité qq part sur le forum, et tu peux gratter un peu mon blog à ce sujet (dont l'exemple du brouillard de guerre, qui ne changera pas le caractère inadapté d'une telle carte isométrique)

Super, merci je vais jeter un œil.

La raison de PHP est souvent la simplicité de démarrage des projets et du dev

Oui, tout à fait d'accord. C'est la raison pour laquelle je pensais partir sur PHP et non Java au départ.

Le Full JS est hyper-récent, donc pas encore bien répandu. De mon point de vue, à moins d'avoir vraiment une équipe de dev, c'est un peu "la techno qui brille du moment". C'est sûrement amusant à découvrir et à utiliser, mais je doute de l'efficacité de la chose.

Pour des applications de petite envergure ça me semble vraiment pas mal, style des API REST. Après c'est vrai que ça me fait un peu peur niveau maintenabilité... C'est la raison pour laquelle je ne voulais faire qu'une petite partie en Node.js, là ou j'ai besoin du temps réel.

Pour héberger du Node.js il faut se diriger vers du service cloud, et le prix n'est carrément pas le même; ou alors du serveur dédié, et là il faut maîtriser.
Et pour Java on n'en parle même pas.

Et du coup, pour un jeu indépendant qui n'aura peut être aucun succès...  ça semble risqué en terme de coût.
Mais un serveur dédié avec un serveur node.js et un serveur apache, est-ce envisageable à un coup raisonnable?

Je n'ai pas bien compris ce qu'il y a de "temps réel" à part le tchat (tu évoques une proportion de 1/3).

Et bien les divers actions que les joueurs effectuent sur la carte générale en fait!
J'aimerais que ce soit du temps réél, car les personnages peuvent s'attaquer mutuellement au même moment par exemple. Ou bien si l'un des joueurs sent que son personnage est moins puissant que celui de son adversaire, il faut qu'il puisse prendre la fuite en se déplaçant sur d'autre case. Et tout ça en quelques secondes!

Un aspect assez pénible est son "asynchronisme", inhérent à javascript. Mais c'est surtout une question d'habitude et des outils existent pour faciliter ce style de programmation (promises ou librairie async).

Effectivement, j'ai travaillé un peu sur cette technologie durant mon M2, j'ai fait 2 projets avec node.js. Je trouvais cet outil super puissant, (mais couplé à mongoDB et AngularJS). Pour une petite application, ça semble parfait.


En gros, le problème actuel c'est le choix des technologies.
Est-ce que ça vaut le coup d'investir sur du node.js (en plus du PHP) en terme de coût de développement, de coût financier, et de maintenabilité ?
Sachant que j'aimerais vraiment un jeu fluide...
Quelqu'un a t-il essayé de coupler ces deux technologies ? Si oui, comment ça c'est passé?

EDIT : sur du node.js (en plus du PHP)