Structure d'un jeu web

[Kurapika0]

Salut à tous,
je poste ce message afin de recueillir des information qui pourraient m'aider pour la création de mon jeu.

Alors voila il y a de nombreux tutoriels que j'ai lu sur la conception de jeu comme par exemple l'incontournable blog de DA, mais malgré tous les tutoriels que l'on peut trouver sur internet, je trouve qu'il y a un gros manque de tutoriel sur la création d'une structure viable pour son jeu, je veux dire par la, lorsque l'on a l'idée de son jeu, que l'on sait comment on veut qu'il soit, ce que l'on veut en faire, il faut bien savoir par ou commencer, et surtout comment relier tous les modules en quelque chose de parfaitement fonctionnel.

Ça rentre bien sur d'avantage dans les questions techniques (d'un point de vue méthodologique) je l'accorde, mais je dois avouer que je me perds dans mon développement, je commence un truc, puis je dois toujours y revenir car je vois que j'ai oublié un truc par rapport à un autre module, et si je continue comme ça je sens que comme beaucoup de projet, le mien risque de tomber à l'eau et je ne veux pas, alors je serais prêt à tout recommencer en repartant d'une bonne base, c'est pour cela que je viens vous demander si vous n'auriez pas des conseils, ou encore des tutos à proposer afin que lors de la conception du jeu, je puisse réaliser le tout de manière fluide, en sachant par ou commencer etc...

Merci d'avance

[Sephi-Chan]

Je pense (n'ayant lancé aucun jeu, ça reste ma théorie) que pour créer un jeu viable, il faut — comme pour n'importe quel système informatique — essayer de découpler au plus les modules en composants indépendants.

Le soucis, c'est que ce concept de module est très abstrait et peu avoir différentes formes selon les technologies utilisées.

En prenant l'exemple de mon projet Seelies : une jeu de stratégie asynchrone joué en parties indépendantes (avec environ 5 à 10 équipes de 10 joueurs par partie), j'ai isolé un certain nombre de modules "métiers" :

• Un module de match making, qui se charge de garder une trace des invitations des joueurs entre eux pour former des équipes. A invite B et C pour joueur une partie en 2 équipes de 3, ils acceptent tous et forment donc l'équipe 1. D a invité E et F mais F a refusé, puis G a invité H et I qui ont accepté, formant donc l'équipe 2. Le système lance donc une partie qui oppose les équpes 1 et 2).
  
• Un module de scoring/ranking, qui se charge de faire des stats sur les équipes pour maintenir un tableau de scores ;
  
• Un module d'achievements, qui se charge de suivre les "succès/médailles/hauts faits" effectués par les joueurs ;
  
• Un module de gestion des parties, qui se charge de la résolution des tours de jeux, des déplacements des unités, etc ;
  

Techniquement, voici la stack que j'ai prévu d'utiliser :

• Une application Web (Nginx + Ruby on Rails + Backbone) qui sert les pages Web et qui dispatch les requêtes aux autres modules ;
  
• Un serveur de base de données (MongoDB) ;
  
• Un serveur de messaging (RabbitMQ), qui permet aux différents modules de parler entre eux ;
  
• Un serveur de communication (Faye + Sengrind), qui se charge d'envoyer les messages aux joueurs (en push ou par mail, selon les messages et selon que le joueur est connecté ou non) ;
  

Pour implémenter tout ça, j'ai choisir d'utiliser pour chaque module métier une application dédiée qui tourne sous la forme d'un daemon.

Pas mal de jeux Web (surtout dans le milieu amateur) sont juste des applications Web, mais c'est souvent un très mauvais choix technique car il pousse à tout faire dans les requêtes requêtes HTTP, ce qui pose plein de problèmes (notamment sur les performances et les accès concurrents à la base). Moi, j'ai choisi d'utiliser l'application Web comme une simple interface avec le joueur.

Pour se parler, les applications utilisent un outil de messaging, RabbitMQ : chaque composant écoute sur une ou plusieurs queues et effectue un traitement à chaque fois qu'un message arrive.


Voici par exemple ce qui se passe dans le scénario que j'ai décrit plus haut :

• Le joueur A se connecte sur le site de Seelies (l'application Web riche en Javascript, propulsée par Ruby on Rails), il se connecte à son compte (stocké dans la base MongoDB), il arrive sur la page qui liste les parties dans lesquelles il joue (toujours en requêtant la base MongoDB) ;
  
• Il veut jouer avec ses amis B et C dans une petite partie (au format 2 équipes de 3 joueurs), il leur envoie donc une invitation. L'application Web envoie un message dans RabbitMQ sur la queue match_maker.new_invitation avec un peu de données encodées en JSON, disons { sender: 'A', other_players: [ 'B', 'C' ], format: { teams: 2, players_per_team: 3 } } ;
  
• Le module de match making reçoit ces messages : il va chercher les informations sur les joueurs dans la base MongoDB pour savoir s'ils ont bien le droit d'être invités par ce joueur (par exemple si un joueur en a "bloqué" un autre, c'est là qu'on coupe l'interaction). Il enregistre dans MongoDB la demande d'invitation et envoie des messages dans RabbitMQ pour notifier au joueur A que ses invitations ont bien été traitées et aux joueurs B et C qu'ils sont invités à jouer ;
  
• Le serveur de communication reçoit ces messages : il sait que A doit être notifié que ses invitations ont bien été envoyées, on lui envoie un push (en push Websocket via Faye) pour lui répondre. Il doit aussi notifier à B et C qu'ils sont invités par A ; comme B est en ligne, il lui envoie aussi sous forme de push pour que le navigateur affiche une popup pour qu'il accepte ou décline l'invitation (ce qui engendrera l'envoi et le traitement de nouveaux messages). C est hors ligne, donc on lui notifie l'invitation via un mail : il y répondra en répondant au mail ou en se connectant au site.
  
• etc.
  

Voilà, j'espère que cet exemple permettra aux gens à comprendre comment on peut créer une application complexe en la séparant en modules faciles à gérer indépendemment.

L'autre avantage est que chaque module a son propre code et qu'on peut donc les tester facilement et rapidement, et les mettre à jour sans avoir à relancer tout (si on coupe un module, les messages RabbitMQ lui seront envoyés quand il sera relancé).

Bien sûr, on peut partager certains bouts de code (les classes, par exemple), notamment grâce aux systèmes de sous-modules des outils de versionnement comme Git.


PS : on parle plus d'architecture que de structure.

[Kurapika0]

Merci beaucoup pour cet exemple concret, diviser le jeu en le plus de petits "modules" me semble en effet assez judicieux, avec une interface au milieu permettant d'interagir avec le joueur, cela semble plus simple avec un serveur de messaging, mais je comptais m'en tenir à la simple application web car n'étant pas très expérimenté, l'utilisation de technologies diverses et variés me mettrait mal à l'aise dans le développement.

Ton exemple va me permettre de repenser les liens entre les différents modules et c'est bien ce que je cherchais à faire, merci beaucoup

Mais pour bien séparer ses modules, comment doit on s'y prendre, tu cites par exemple un module de scoring/ranking, puis un autre d'achievements, dans un jeu ou les deux seraient liés, le score ne dépend que des achievements du joueur, doit on créer un seul et unique module, qui ferait tout le travail ou un qui suivrait les succès, puis un autre qui s'occuperait de faire les stats du joueurs (points, classement etc...)?

[Sephi-Chan]

Rien n'empêche au module de scoring/ranking d'utiliser des informations crées par le module d'achievements : rien ne l'empêche d'accéder à la base de données MongoDB.

Note aussi que l'on n'est pas limité à l'utilisation d'une base unique : un module peut tout à fait utiliser plusieurs base de données. On pourrait par exemple imaginer que le module de communication utilise une base de données Redis (stockage en RAM, extrêmement rapide) pour associer à l'ID d'un joueur son état online/offline.

Bien sûr, le découpage que j'expose ne convient pas forcément pour tout (et il n'est probablement pas parfait). On peut tout à fait séparer un module en plusieurs dans le futur, ou au contraire en rassembler plusieurs.


Enfin, il ne faut pas hésiter à se frotter à des choses nouvelles : on progresse en sortant de notre zone de confort.

[Maks]

d'où le choix de Mongo j'imagine

[Kurapika0]

Rien n'empêche au module de scoring/ranking d'utiliser des informations crées par le module d'achievements : rien ne l'empêche d'accéder à la base de données MongoDB.

Oui, c'est pas faux, je dois avouer que cette question était assez bête ^^

Bien sûr, le découpage que j'expose ne convient pas forcément pour tout (et il n'est probablement pas parfait). On peut tout à fait séparer un module en plusieurs dans le futur, ou au contraire en rassembler plusieurs.

Bien sur, je comprends parfaitement qu'un découpage précis ne conviendra pas à tout type de situation, je pense que je vais étaler mon jeu sur papier, y noter toutes les actions possibles, et les ranger dans des modules, puis ensuite lisser le tout en en fusionnant, en découpant etc... pour voir ce qui conviendrait le mieux pour ce que je veux.

Enfin, il ne faut pas hésiter à se frotter à des choses nouvelles : on progresse en sortant de notre zone de confort.

Je suis bien d'accord, mais la création de jeu n'est pas non plus vraiment ma "zone de confort", je n'en ai jamais fait, je progresse déjà beaucoup rien qu'en imaginant un jeu, et en me rendant compte de tout ce que la création d'un jeu implique. Je préfère m'en tenir à ça actuellement (j'ai déjà beaucoup progressé en programmation depuis le début de mon projet), puis quand je serais plus à l'aise dans le domaine du jeu, alors la je tenterai de nouvelles choses


En tout cas je le redis, merci beaucoup pour ces précisions sur la manière dont tu abordes la structure d'un jeu web, il manque de ce genre de conseils dans les différents tutos que l'on trouve sur internet.

[Kassak]

Pour y rajouter mon grain de sel, ne surtout pas avoir les yeux plus gros le ventre !

Comme dit plus haut, découper ton jeu en module est j'ai envie de dire presque vital et te permettra de voir réellement ton avancé, de savoir plus ou moins combien de temps il te reste avant la fin de ton dev.

Maintenant, pour moi, le but c'est de faire le plus rapidement possible un jeu jouable et un minimum intéressant. Plus tu mettras de temps à faire quelque chose de potable, plus les chances que ça te saoul, que ton équipe te lache et j'en passe seront grandes !

Il faut donc définir quels modules seront présents pour ta V1 (le minimum, gestion de membre, inventaire, forum etc.... par exemple).

Une fois tes modules terminé, ton jeu est en V1, bravo, maintenant tu y ajoutes les modules que tu avais mis de coté, etc.... et HOP, V2 !

Tu auras ainsi vraiment le sentiment d'avancer et de ne pas te lancer dans un truc de fou que tu mettras 20 ans à faire ou qui ne sera jamais terminé

Mais pour cela, il faut imaginer ton jeu à fond avant d'écrire la moindre ligne de code, ça t'évitera de retourner sur des modules 50 fois parceque tu avais oublié un truc.

[Kurapika0]

Je vois que cela m'a bien fait défaut de mal séparer mon jeu en modules, de ne pas l'avoir imaginé a fond, et de ne pas l'avoir noté (en détail tout du moins) sur papier, plutôt que de faire les modules au fur et à mesure qu'ils me viennent, je vais tout reprendre depuis le début à la phase de réflexion, et je vais m'y prendre, comme conseillé par module.

Ça me paraît extrêmement moins prise de tête, et surtout je ne me découragerais pas, du moins je l'espère

Et je vais aussi faire mon maximum pour épurer mon jeu au début, c'est vrai que je voulais qu'il soit assez complet dès le début, mais je me rends compte que c'est inutile, autant avoir un jeu avec peu de contenu (modules etc...) mais qui fonctionne bien qu'un jeu avec beaucoup de contenu, mais qui n'est pas terminé, et qui risque de ne jamais l'être.

Merci d'avoir ajouté ton grain de sel, il va aussi m'être très utile.

[Etienne]

Si je ne m'abuse, dans une production vidéoludique, ces étapes préliminaires s'inscrivent dans ce qu'on appelle la bible du Game Design.

Je penses que c'est le genre de document indispensable et même au seins d'un jeu amateur, peu importe la forme que cela prend l'important est que ce soit présent. Le fait de passer par la rédaction t'imposera de mieux penser ton contenu et surtout de le hiérarchiser. Et je penses, comme dit plus haut que cela t'évitera aussi pas mal de code inutile suite à des éléments que tu n'aurais pas assez réfléchis.

Mais déjà te placer dans cette optique d'organisation est une démarche très positive, je penses que beaucoup de projet irait plus loin si il y'avait eut plus de temps passer sur ces étapes de pré-productions.

Comme quoi les aptitudes techniques ne se suffisent pas en elle même, il faut aussi savoir où l'on va :p

Bonne chance pour ton projet en tout cas =)

[Kurapika0]

Oui, je m'en rends de plus en plus compte, et c'est bien parce que je sentais que j'allais droit dans le mur que j'ai créé ce topic, et je suis bien content de l'avoir fait, cela va me permettre de repartir sur de bonnes bases.

Merci, j'espère que j'arriverais à terme de ce projet car à la base c'est une des raison pour laquelle j'ai eu envie de m'initier à la programmation il y à quelques années