Discussion :

[Ezelia]

Bonjour à tous,

Je suis nouveau ici, et je viens vous présenter un projet sur lequel je bosse en ce moment, j'ai évité de poster des info à propos du projet tant que je n'avais pas du concret à présenter, aujourd'hui je viens donc vous inviter à tester une version pre-alpha du jeu.

Lien pour tester : http://demo.ezelia.com

Cette démo est juste un prototype dont le but est de démontrer les possibilités du moteur de rendu isométrique (ça marche sur un navigateur sans aucun plugin), ainsi que la partie serveur, puisque la démo est multijoueurs.

Pour le moment c'est juste un PoC, pour donner de la crédibilité au projet et montrer son potentiel, vos remarques et/ou suggestions sont les bienvenues .

Comme je l'ai dit, le moteur est de type isométrique avec du scrolling continu,
les fonctionnalités implémentés sont :
l'interaction multijoueurs.
le tchat
les téléportation (passage d'un carte à l'autre / d'un monde à l'autre)
les interactions avec les PNJ.
Sons / Musique


d'autres fonctionnalités sont implémentés mais pas encore mises en ligne (en cours de validation) :
Effets de particules : feu, fumé ...etc
Effets spéciaux : eau, vagues

en cours de développement :
Inventaire 20% d'avancement
Système des quêtes 40% d'avancement
Système de combats 20% d'avancement


Coté graphique ça ressemble à ça :



L'histoire l'univers ...etc
Nous n'avons pas encore décidé des détails de l'histoire, mais l'univers sera inspiré de la culture Arabo-Berbère. bien qu'ayant sa propre mythologie, ses propre personnages et lieux ...etc le joueur ne sera pas dérouté car au final on y retrouvera les mêmes ingrédients d'un univers fantastique classique (des créatures imaginaires, une mythologie, de la magie, maitrise/manipulation des éléments, combats...etc)
Nous ne nous aventurons pour le moment pas dans le terrain de la rédaction de l'histoire, des personnages, des races ...etc, car avant cela on doit savoir ce que notre moteur de jeu pourra gérer, et quelle niveau de jouabilité permettra-t-il ?

Le projet
L'ambition du projet n'est pas d'inventer le MMORPG qui va révolutionner le monde, mais de concevoir dans un premier temps, un prototype jouable avec fonctionnalités de base attendues dans un MMORPG : interactions multijours, PNJs, quêtes, commerce, combats ...etc
Une fois ce prototype réalisé, il nous permettra de confirmer (ou non), à créer un vrai MMORPG en HTML5 car c'est là le vrai défit , puisqu'HTML5 est une techno très récente et pas encore finalisée. si le projet est confirmé, on passera alors à l'étape suivante : développement à plus grande échelle, recrutement ...etc

pour le moment nous uniquement deux personnes, un développeur et une graphiste, mais nous sommes conscient qu'a un moment donné il faut avoir plus de monde, ce n'est pas encore à l'ordre du jour (je vous explique plus bas comment on optimise notre travail ...)

Coté technique : client
le jeu utilise un moteur codé en JavaScript from scratch, car pour pouvoir optimiser au max les performances en HTML5 on ne peut pas se permettre des surcouches et des librairies intermédiaire.
seul exception, pour l'interface utilisateur et les interactions (boites de dialogues ...etc) j'utilise jquery-ui ...

Coté technique : serveur
Pour les besoins de la démo j'ai mis en place un serveur avec plusieurs VM pour simuler la répartition de charge, et tester les modules développés dans ce sens.
Le serveur tourne derrière un loadbalancer et un proxy de cache HTTP.
la conception du serveur du jeu a été pensée de manière à simplifier la répartition de la charge sur plusieurs serveurs physiques ou virtuels si besoins, par exemple je peux avoir un serveur qui gère tout mes PNJ, ou alors répartir la gestion des PNJ sur plusieurs serveurs...


Les moyens qu'on se donne pour avancer même à effectif très réduit

1 - Nous sommes conscients qu'un tel projet nécessite beaucoup de moyen, c'est pour cela qu'on se fixe des objectifs atteignable par étape (des palliers) ... par exemple l'un des objectifs était de lancer une première pre-alpha avec uniquement des fonctionnalités de base et les interactions avec les PNJ, cette pre-alpha nous permettra de corriger les bugs graphiques mais aussi de surveiller le fonctionnement du serveur avec plusieurs vrais joueurs en ligne...

2 - Le Moteur a été conçu afin de pouvoir utiliser et s'adapter à des outils existant pour la conception du jeu, ceci permet d'économiser énormément de temps, exemple, les cartes sont créés avec l'éditeur Open Source "Tiled Map Editor".

3 - L'une des plus grandes contraintes qu'on sous-estime et qu'on peut rencontrer lorsqu'on développe un jeu isométrique, c'est la création des personnages ! il est très difficile de trouver des bons graphistes-animateurs pour l'isométrique, et quand on les trouve ils sont trop cher et la réalisation de toutes les frame d'un perso prend énormément de temps, imaginez alors la création de plusieurs perso pour une carte ?
Nous avons surmonté cette difficulté on automatisant un maximum de chose, les perso sont modélisés dans un outil 3D en quelques heures, et un script s'occupe de faire le rendu style toon avec les différentes frames de mouvement de chaque perso.

4 - Coté serveur nous utilisons nodejs, toutes les fonctionnalités de bases pour monter un serveur sont disponibles grâce à la communauté très active via des modules, de plus, puisque nodejs exécute du javascript, cela permet d'économiser du temps en partageant certains développement entre le client et le serveur.


Je vous invite donc à tester et me remonter vos remarques, je vous rappel qu'il s'agit d'un prototype dont le but est de tester le fonctionnement et non le gameplay.

Rappel du Lien pour tester, pour ceux qui ont eu le courage de tout lire

http://demo.ezelia.com

[saturn1]

Coté technique : client
le jeu utilise un moteur codé en JavaScript from scratch, car pour pouvoir optimiser au max les performances en HTML5 on ne peut pas se permettre des surcouches et des librairies intermédiaire.
seul exception, pour l'interface utilisateur et les interactions (boites de dialogues ...etc) j'utilise jquery-ui ...

Coté technique : serveur
Pour les besoins de la démo j'ai mis en place un serveur avec plusieurs VM pour simuler la répartition de charge, et tester les modules développés dans ce sens.
Le serveur tourne derrière un loadbalancer et un proxy de cache HTTP.
la conception du serveur du jeu a été pensée de manière à simplifier la répartition de la charge sur plusieurs serveurs physiques ou virtuels si besoins, par exemple je peux avoir un serveur qui gère tout mes PNJ, ou alors répartir la gestion des PNJ sur plusieurs serveurs...

Impressionant la compétence gestion de la charge et aussi le codage du moteur client en JS, BRAVO!

J'ai teste , c'est un peu vide comme tu le dis.
Graphiquement "ca a son charme^^"

Je n'ai pas bien compris le but je me suis promener mais comme tu sembles le dire c'est plus pour tester les serveurs.

Quelle est la charge réelle supportée par tes serveurs, et le hardware derrière?
Ensuite ca ne lag pas c'est bien...

Tu as fait des tests avec TC (sur linux) par exemple pour controller le traffic?
Si tu pouvais détailler un tout petit peu ta couche réseau, avec les problèmes courant et ta proposition de résolution ça pourrait être intéressant pour pleins de développeurs!

A+

[nouknouk]

Excellent boulot, félicitations !!!

Comme le dit saturn1, ça donne d'en savoir plus, notamment en terme de choix techniques, de difficultés rencontrés, des solutions trouvées, de temps passé, etc...

Et bien sur n'hésitez pas à exposer vos problèmes actuels ; on sait jamais, il se pourrait que d'autres aient des solutions à vous proposer.

J'ai teste , c'est un peu vide comme tu le dis.
Graphiquement "ca a son charme^^"

il s'agit d'un prototype dont le but est de tester le fonctionnement et non le gameplay.

[Ezelia]

Merci pour vos retours

tout d'abord je tiens à préciser qu'aujourd'hui j'utilise un seul serveur physique que j'ai coupé en plusieurs VMs pour simuler un fonctionnement réparti... je n'ai pas les moyen pour m'offrir plusieurs dédiés pour un projet encore à ses débuts

Concernant la partie serveur, je compte écrire une série d'articles là dessus dès que j'ai du temps ... mais puisque ça va pas être pour demain voici un peu de détails.



Coté Software
Le serveur du jeu tourne sous nodejs, et il écoute sur deux ports, un pour les clients externes et un acceptant uniquement des connexions internes ou IP whitelistées.

Le coeur du serveur ne sait gérer que les déplacements, déclencher une action quelconque, et échanger des messages de tchat.
ensuite des serveurs tiers viendront se greffer sur celui-ci pour offrir d'autre fonctionnalitées : exemple, un serveur PNJ viendra se connecter via le port interne pour ajouter des PNJs au jeu, après tout un PNJ n'est autre qu'un joueur virtuel.
un autre serveur pourra venir se gréffer pour gérer les transaction de type commerce par ...etc

quand un serveur tiers se connecte, il peut déclarer qu'il sait gérer une action d'un certain type, par exemple, le serveur de PNJ dira qu'il sait gérer l'action "dialogue", à chaque fois qu'un client envois l'action "dialogue" au serveur, celui-ci va la déléguer à tous les serveurs tiers qui savent la gérer, à chacun de voir s'il a quelque chose à en faire ou non....

les serveurs tiers sont des process nodejs, il peuvent tourner sur la même machine que le serveur central, ou être répartis sur plusieurs machines ...
de même, je peux répartir la charge d'un serveur tiers dédié à une tâche en le scindant, exemple : au lieu d'avoir un seul serveur PNJ j'aurais un serveur PNJ qui gère les bots, un autre qui gère les animaux, un autre qui gère les spawn ...etc et pareil je les mets sur une même machine ou les réparti.

Reste le serveur central, qui peut à son tour être surchargé et qu'il faille le soulager .... j'avais pensé au début à une sorte d'archi P2P ou round-robin ... mais c'était trop compliqué à mettre en place donc j'ai abandonné cette piste.
la meilleur solution rapport simplicité/efficacité que j'ai trouvé pour ça consiste à séparer les serveurs physiquement s'ils deviennent trop chargés

Coté "Hardware"
Le serveur central tourne sur nodejs comme je l'ai dis, et sert de serveur de jeu, mais aussi de serveur web, puisque c'est un jeu sur navigateur ... pour éviter qu'il passe trop de temps à servir les contenus statiques, un serveur de cache est utilisé. avec chaque machine nodejs il y a un proxy varnish dédié aux contenus statiques : images, sons, data ...etc ainsi le serveur nodejs ne s'occupe que des websockets.
(aussi, s'il y a besoin, le proxy varnish peut être installé sur un serveur à part)

au dessus de tout cela il y a un loadbalancer (j'utilise HAProxy) et ce pour deux raisons :
1 - Répartir la charge
2 - Permettre de faire du SSL sans toucher aux couche en dessous (la dernière version de HAProxy fait du SSL offloading)

en dessous de tout cela il y a bien sur une base de données , et j'ai choisi mongoDB (pour plusieurs raisons), pour le moment j'ai un seul serveur de BD et il est largement suffisant, mais en cas de nécessité un cluster peut être monté.

au final la répartition de charge se fait à trois niveaux : le load-balancer, la couche logicielle et la BDD.

en schéma théorique ça donne à peut prêt ça :




je n'ai pas encore fais de tests poussés de montée en charge, mais j'ai fais un test dans une config restreinte (512Mo de RAM et un seul CPU) avec serveur central et serveur PNJ qui tourne sur la même machine, le serveur PNJ génère 1000 PNJ et les fais bouger aléatoirement dans le jeu.
le serveur a tenu sans problème, la RAM en dessous de 320Mo utilisé et le CPU à 50%.
Ceci n'est pas un test de charge en terme de nombre de connexion mais plutot en nombre de requêtes ... je suis en train de préparer un autre test mais cette fois-ci avec des connexions

[nouknouk]

Merci pour tous ces détails, c'est toujours très intéressant de confronter ce qu'on a pu expérimenter par soi même avec l'approche qu'ont pu avoir d'autres personnes sur les même sujets.

Juste une remarque/question à propos de la séparation des responsabilités entre les 'serveurs tiers' ; la séparation pour chacune des tâches ne pose-t-elle pas un souci (de concurrence notamment) quand plusieurs serveurs tiers devront collaborer entre eux.

Par exemple un 'serveur tiers' pourrai avoir à s'occuper de ce qui concerne la gestion des caractéristiques des comptes des joueurs, pendant qu'un autre serait dédié à gérer des fonctionnalités permettant par exemple de pouvoir s'échanger des messages de chat entre joueurs déclarés 'amis'. Ces deux 'serveurs tiers' vont être amenés à devoir collaborer. Leur séparation franche ne risque-t-elle pas de poser un problème ?

[Ezelia]

oui on peut tomber sur ce problème si on réparti les rôles n'importe comment et si on fixe pas des règles.

c'est aussi fortement dépendant de la conception du serveur.
une règle que je me fixe par exemple c'est : en cas de conflit c'est la BDD qui a raison, à chaque unstant T du jeu, la BDD doit toujours avoir un état valide du jeu. si tout crash, et que le serveur doit relancer, c'est à partir de la BDD qu'il retrouvera un état de fonctionnement normal (il y aura des pertes de donnée certainement, mais ça n'empêchera pas au jeu de reprendre)

on est en mode réparti donc il y aura forcément des erreurs, le système ne doit pas être conçu pour les éliminer ou planter s'il n'y arrive pas, mais doit au contraire être tolérant aux erreurs et savoir reprendre un état consistant en cas d'erreurs/conflicts.


si deux serveurs tiers doivent collaborer, on peut les implémenter de manière à avoir leur propre pipe pub/sub, ou de manière a communiquer via le serveur central, et s'arranger à ce qu'ils discutent bien entre eux.

ça permet aussi de répartir le travail si le projet devait être développé par plusieurs personnes. et si un serveur tiers plante, il doit planter tout seul tempi pour sa geule ... l'essentiel c'est qu'il ne fasse pas planter le reste.

[micka132]

Salut,

un petit commentaire juste pour dire que lors du click sur "play" la premiere fois le jeu ne s'est pas chargé. J'ai juste eu les boutons du tchat et de la barre des fps.
J'ai dû fermer et réouvrir en cliquant sur play pour que le jeu se charge. Le bug n'est pas reproductible donc je peux pas t'aider d'avantage (Firefox 17.0.1).

Sinon je trouve ça plutôt sympas et fluide, d'autant que ça n'utilise pas de plugin. Maintenant, même si tu sembles avoir faire quelques test cotés serveurs, sur le client avec tout un tas de joueur, plus d'élements sur la carte et notamment des moteurs dynamiques ( feu, fontaine...) est-ce toujours la même chose?

Une remarque que j'ai eu en ecrivant ce message concerne la musique et les bruits: ils continuent après le changement d'onglet mais par contre les mouvements sont arrétés. Par exemple j'ai choisi de me déplacer assez loin, puis je change d'onglet. J'entends le déplacement mais en réalité le personnage ne bouge pas.

Bref bravo pour le travail déjà réalisé

[Ezelia]

Concernant les problèmes d'affichage qui bloque quand tu change d'onglet et du son qui continue, c'est en fait due à une implémentation un peu spéciale du requestAnimationFrame() dans les navigateurs, cette méthode permet de donner la main au moteur de rendu au bon moment, et est optimisée de la sorte, mais les mecs qui ont défini la spec se sont dit que quand l'onglet n'est pas actif le navigateur n'a pas besoin de faire du rendu ... et puisque mon moteur est synchronisé sur cette methode il bloque ... (je travail sur un correctif propre en ce moment ), le son lui n'a pas cette contrainte et est traité séparément donc il continue de tourner.


Pour la fluidité du rendu avec des effets spéciaux ...etc je vais mettre en place des maps spéciales pour démontrer ce que le moteur peut faire, normalement avec une bonne carte graphique ça ne devrait pas avoir d'impact sur la fluidité, mais je vais quand même mettre en place un algo qui bloque les effet de particules quand le FPS devient trop bas.

pour le moment j'ai juste des vidéos pour les montrer :

effet de particules type flame :
http://youtu.be/weCmD_e7grE?t=17s


effets spéciaux basé sur des spritesets (utilisables pour les combats) :
http://youtu.be/NnQaatyH_kw

autres animations pour le combat (du perso cette fois), avec un effet généré de manière procédurale (l'éclair à la fin de la vidéo)
http://youtu.be/hwSe_jFdefM

[Mickael23]

Niveau serveur, c'est très sérieux et très pro, bien joué mais bon vous avez pas beaucoup de joueurs donc c'est plutôt sous utilisé toute votre techno ?

[Ezelia]

Comme expliqué plus haut, l'archi serveur expliquée consiste actuellement en des machines virtuelles sur un même serveur physique, et les redondances (base en cluster, deux noeuds pour HAProxy ) ne sont pas mis en place pour la démo, mais peuvent être ajouté à terme.

j'ai expliqué en gros ce qui est préparé et planifié pour supporter la charge coté serveur si le projet réussi et qu'on a un grand nombre de joueurs.