Moteur de jeu 2D

[L'Omniscient]

Hello,
J'ai cherché dans les sujets du forum mais je n'ai pas vraiment trouvé de réponses à mes questions.

Alors voilà, j'ai essayé un jeu web : http://www.omtorn.com/
J'ai été impressionné par la fluidité du jeu, du déplacement sur la carte (bon, je n'ai joué qu'en solo, je ne sais pas ce que ça donne avec d'autres joueurs).
J'ai cru comprendre que, pour travailler un déplacement en temps réel sur une carte (imaginons un quadrillage de 10 par 10 avec un personnage de 1 par 1 qui peut se déplacer à sa guise dessus), il fallait créer un moteur de jeu (ou moteur graphique ?) Bien sûr je parle de 2D.

Comment crée-t-on un moteur de jeu (ou graphique ?) 2D ? Par où commence-t-on ?
(Oui je sais qu'on peut en utiliser des déjà fait, mais pour bien comprendre le fonctionnement je trouve ça toujours mieux de savoir faire.)

Là, intuitivement, si je devais créer un déplacement sur une carte, je ferais un truc du genre tu clique sur le quadrillage, le personnage se téléporte, je ne saurais pas dessiner un mouvement continu entre les 2 points. Un déplacement avec les touches directionnelles me semble plus simple à gérer. Est-ce que créer un moteur permet de simplifier ces déplacements ?

D'autre part, en terme d'échange massif en temps réels entre plusieurs joueurs, quel langage serveur est le plus approprié ? Node.js ? Est-ce que PHP peut gérer ça avec une certaine fluidité ?

Ce petit jeu m'a donné quelques idées, c'est tellement beau de voir des créatures dessinées se déplacer dans un espace virtuel u_u

J'ai encore beaucoup de choses à apprendre, éclairez-moi chers maîtres codeurs

[Xenos]

Salut,

ces moteurs RPG basiques et classiques existent déjà, aussi bien en Web qu'en non web (et perso, j'irai vers du non web pour un RPG lourd, classique, et de qualité; bref foutre un RPG comme ça dans le web en indé sans équipe, je trouve que cela entraine un gros risque de manque de contenu :/ mais passons, c'est peut-être juste que les RPG que j'ai vus étaient assez vides). En créer un me semble donc totalement inutile et une pure perte de temps. Le seul intérêt à en créer un serait d'avoir besoin d'un truc bien plus basique que ces moteurs.

En gros, il faut trouver le minimum entre [Temps d'apprentissage + installation + mise à jour du moteur existant] et [Temps d'apprentissage + installation + mise à jour du moteur custom]. Le 1er est plus rentable si le moteur est lourd et gros (ie: Wordpress, car cette équation s'applique à tout) et le 2nd est plus rentable si le besoin est très limité voire simpliste (ie: tous les minis-jeux de https://reinom.com sont sans moteur spécifique, juste le navigateur natif).


Je mettrai en article le détail de création de ces jeux, cela pourra aider des gens. N'hésite pas à remonter des propositions d'articles du style sur https://bugs.reinom.com le bugtracker, section "Blog", "Rapporter un Bogue" (à gauche), "Feature". Cela m'évitera de les oublier.

Le but du moteur est de gérer les actions de base, comme le déplacement. Suivant le moteur choisi (et son paramètrage), tu auras des déplacements "numériques" (par à-coups de case) ou fluides, ou analogiques, etc.

PHP n'est pas adapté à du temps réel ou à du bicanal. Il est top pour du web classique, car géré par les hébergeurs ce qui t'épargne de la maintenance. Pour du temps réel vrai, prend un SDK classique AAA (Neoaxis, Unity, etc): tu n'auras *aucune* question à te poser, et juste du contenu à mettre. Bon, en revanche, cela oblige à faire plus de graphisme, scénario, modélisation, sound design etc que de code brut, donc tout dépend ton but.

[L'Omniscient]

Boooouh, ça me fait peur le PHP pas adapté au temps réel pour mon jeu :'( J'ai peur que ça fasse tout foirer. J'aurais ptet dû me tourner vers du NodeJS :'( (Bon après c'est pas de l'animation temps réel mon jeu, c'est de l'échange de données temps réel, peut-être que du coup le PHP c'est bon ?)

Mais j'aimerais bien savoir comment on fait pour coder un moteur de jeu, ça m'intéresse, ça doit être fascinant ! J'aimerais bien essayer d'en développer un plus tard, mais j'ai aucune idée de comment on peut se lancer là dedans.

Question : pourquoi PHP n'est pas adapté pour du temps réel ? Qu'est ce qui fait qu'il est plus mauvais qu'un autre pour le temps réel ?

(Ton appli bugs tracker est GENIAL :O )

[Xenos]

Heu, non, justement, l'échange de données en temps réel entre plusieurs joueurs, c'est assez chiant en PHP. Après, tout dépend de la quantité de données et de l'aspect véritablement "temps réel" que tu recherches.

Regarde les ressources concernant Quake III et son moteur, ou Ogre 3D. Je pense qu'il doit y avoir tout ce qu'il faut au sujet de comment ces moteurs ont démarré et se sont développés.

PHP n'est pas étudié pour du temps réel car il s'agit, de base, d'un langage de template. Couplé à Apache, c'est d'autant plus flagrant (et d'autant d'autant plus sur les mutualisés où tu n'auras pas la main sur la configuration): c'est une stack construite sur le fait qu'une page web est demandée, puis servie, et terminé, la connexion s'arrête, le taff est fait.
Pour faire tu véritable temps réel, il faudrait que la connexion au serveur puisse persister, que le serveur puisse ainsi envoyer des données côté client, et que le serveur ait une notion d'évènement (ou d'attente passive) qui lui permette d'envoyer les données nécessaires au client connecté lorsque ces données sont disponibles sur le serveur. Et je ne compte pas le fait que le client puisse remonter des données par moment au serveur si nécessaire.
Ces opérations sont totalement transparentes sur un moteur de jeu classique (AAA), c'est pour cela que pour des jeux de ce genre, c'est la solution la plus adaptée. Sans compter que je doute de la scalabilité d'un tel mécanisme (à 3-4 joueurs, soit e qu'un jeu AAA encaisse sans aucun problème, cela peut passer mais quand on fleurte avec la centaine de connecté en même temps, je commence à douter des performances d'un machin web "temps réel"... pour un vrai jeu j'entends hein, pas juste un truc bidon envoyant 3 données toutes les 2H pour juste montrer qu'on peut avoir 100 connectés en même temps)

PS: C'est un Mantis, ça tournes sur PHP, tu peux l'installer sur ton propre serveur si tu veux

[incodewetrust]

Le temps réel nécessite une boucle de rendu (js peut le faire). PHP nécessite un rechargement de la page pour communiquer sur l'état au temps T. De ce fait php reste tout à fait adapté à un jeu à points d'actions, ou chaque action déclenche le rechargement de la page (il n'y a donc pas de flots de requête constant) mais pas à du rpg 2d classique ou tu déplaces ton personnage de manière constante et/ou tu dois récupérer la position des autres éléments dans la boucle de rendu.

Après je rejoins Xenos que même un rpg optimisé avec node.js risque de montrer très vite ses limites en cas de charge élevée.

Mais certaines choses peuvent évoluer rapidement et il faut garder à l'esprit que ce qui est vrai aujourd'hui ne le sera pas forcément demain (je pense que le web permettra de plus en plus à l'avenir ce genre de projets).

[Xenos]

Apache & PHP peuvent tout à fait envoyer des données au client, maintenir la connexion pendant un certain temps, puis renvoyer d'autres données. Le problème, c'est que PHP n'a pas d'attente passive, donc tu risques vite de te retrouver avec un "while true" contenant un sleep, qui pingera la BDD en boucle pour voir s'il y a du changement. Là, niveau perf, plouf. (à moins que d'autres méthodes existent... mais les ratchet ou autre truc du genre requièrent plus qu'un simple accès de mutu). Et si le client doit remonter des données, cela devient là aussi compliqué... y'a bien des strems PHP (il doit donc y avoir l'input dedans) mais bon, c'est franchement chiant à traiter.

Le web a 20 ans de retard sur les SDK AAA existants (c'est une image), ce retard ne sera pas rattrapé d'un coup pouf... C'est pour cela qu'un RPG de ce style, s'il n'est pas juste une excuse pour aller faire de la techno web "toute neuve qui brille", devrait plutôt se faire via les outils connus et éprouvés. Après, cela oblige à faire le contenu de jeu et non plus passer son temps sur de la stack (souvent, là, ça coince chez les dev amateurs )

[niahoo]

mais les ratchet ou autre truc du genre requièrent plus qu'un simple accès de mutu

Ouais mais si tu veux faire du temps réel (soft) de toutes façons il te faut un environnement de dev confortable et des perfs sympa, donc oublions le mutu.

D'ailleurs les mutu c'est mignon mais c'est fait pour faire des petites pages web. Si tu fais tourner un jeu, il y a beaucoup plus de choses à faire que simplement du rendu de template. Oublie le mutu.

Tu peux aussi regarder Phoenix qui a tout ce qu'il faut pour faire du temps réel via le web, et qui tient une charge de malade (beaucoup plus qu'Apache). Mais c'est pas du PHP.

[Xenos]

Si tu fais tourner un jeu, il y a beaucoup plus de choses à faire que simplement du rendu de template. Oublie le mutu.

Clairement pas d'accord: les 3/4 des projets ici (peut être plus?) sont amplement fonctionnels sur un mutu. Un mutu ne veut pas dire "des perfs de merde" (les hébergements "Performance" de chez OVH sont des mutus, avec des perfs). Un mutu veut plutôt dire "un hébergement où le sysadmin, c'est pas moi qui me le tappe: c'est l'hébergeur, qui fait ça pour 1000 mecs en même temps": tu peux mutualiser l'administration sans mutualiser les performances

Après, faut pas oublier un truc: pourquoi on fait son jeu? Si c'est pour tester les technos, pas de soucis, pas de soucis, recodez un moteur, et plongez dans les trucs qui sont sortis y'a 2 mois (c'est sûrement amusant et instructif, et vous n'aurez pas l'occasion de faire ça au taff, ou alors, votre boite est totalement insouciante!). En revanche, pour faire (seul ou presque) un truc qui tourne, je pense qu'il vaut mieux rester sur ce qu'on connait et tendre à le maîtriser. Bref, avant de s'emballer dans les tours et de partir sur l'exotisme, la question à se poser (après "pourquoi on fait son jeu") c'est "est-ce [telle techno] vraiment adapté?". Je ne crois pas me tromper en disant que tous les projets qu'on voit passer ici seraient parfaitement faisable sur un PHP bricolé (et verraient donc peut-être le jour). Mais bon, c'est un "argument des moutons": ça n'empêche pas de se lancer dans ces technos, faut juste comprendre pourquoi se lancer là dedans et ce qu'on en fait

[niahoo]

Autant pour moi, je suis également sur un mutu. Ce que je voulais dire c'est que si tu veux faire un jeu avec des fonctionalités un peu avancées, notamment en termes de multi, il te faut un serveur avec un accès shell et la possibilité d'installer ce que tu veux.

Rester sur du PHP/Apache/Mysql de base parce que c'est tout ce que ton hébergement cheap te permet c'est pas la bonne démarche. Commence par établir tes besoins, choisis les technos qui vont bien, réalise ton produit et ensuite regarde comment faire pour l'héberger.

Considérer que de base il faut utiliser PHP / Apache et que le reste est exotique est une vision archaïque. Regarde l'industrie du web, le nombre de boites qui ont fait fonctionner un truc viable sur Rails, Node, Phoenix. On est plus en 2000. Faire un channel multi avec push en PHP aujourd'hui c'est se compliquer la vie alors que c'est buil-in dans Phoenix ou, je parie, au moins la moitié des frameworks Node.

Edit: j'avais mal lu. Tu crois vraiment que Node et Phoenix sont des joujours sortis il y a deux mois ? Après, ok, si quelqu'un veut faire uniquement du PHP parce-que <insérez une bonne raison, j'ai pas trouvé> alors il y pusher et pubnub.

[Xenos]

Ouep, c'est sûr que si tu as besoin/veux la main entière sur la config et le serveur, le mutu, c'est pas fait pour

A mon sens, il ne faut justement pas prendre en exemple les boites qui se lancent dans ces technos car ce n'est juste pas du tout le profil des créateurs qui viennent ici. Ces entreprises sont des groupes d'au moins 10 personnes (à la louche), travaillant à plein temps sur un projet, avec un objectif de rentabilité, un budget, une structure, etc. On est très loin des profils de créateurs indépendants, seuls ou par petits groupe de 3, qui se lancent là dedans en voulant simplement s'amuser (et qui risquent souvent de se bercer d'illusions en croyant qu'il suffit de passer 3h de ci-de-là pour sortir un jeu révolutionnaire en temps réel sur le web).

Pour ce genre de profil, je maintiens qu'il n'y a qu'une seule solution qui me semble véritablement viable, au sens où un jeu finira par sortir *et par vivre* (parce que derrière, il faudra la maintenir la communauté de joueurs): laisser tomber les features "kikoo avancées" du multi temps réel/la 3D/du user-generated-value pour utiliser ce que les créateurs connaissent et ont accès.

Si tu connais à fond les technos Node, Phoenix, etc, et que tu y as accès en deux gestes, pas de soucis, sers-t'en. A l'inverse, si tu as accès facilement à la vieille techno Apache/PHP/Sql et que tu la connais, prends celle-là. Car je doute sérieusement qu'un créateur indé ait le temps d'apprendre une nouvelle techno, de la rendre disponible (install & maintenance) tout en créant le contenu du jeu et en assurant la vie de sa communauté et la diffusion de sa création. Tout ça bouffe énormément de temps, et il me semble que le plus simple est de tailler dans la techno plutôt que dans la diffusion ou dans le contenu pour avoir un jeu qui finit par sortir et tenir.

Après, je me gourre peut-être, mais bon, sur mon exemple personnel, ça m'a l'air d'assez bien marcher. Après, le tiens diffère peut-être (si ta techno au boulot est NodeJS, t'auras peut-être plus facilement accès aux moyens techniques et aux connaissances pour le faire). Mais bon, pour avoir jeté un oeil de curiosité aux SDK AAA et à NodeJS, je peux te garantir à 100% que le 1er est 100x plus simple à mettre en place et à utiliser que le second. D'où mon poussage pour que les récurrents MMO/RPG révolutionnaires en temps réel 3D/VR où on peut tout faire et tout devenir s'orientent plutôt vers des SDK classiques que vers du Web.

Bref, toujours est-il que la techno PHP et les habituels hébergeurs ne sont pas adaptés au temps réel, et que pour ce genre de problématique, un SDK me semble être la solution la plus simple et rapide (mais comme toute solution qui réduit les soucis techniques à presque-zéro, elle impose de s'attaquer au contenu réel du jeu).