[Projet en cours] Exile -reborn- jeu en ligne

[Golgotha]

Bonsoir,

je viens donner quelques nouvelles de ce projet, la première version à tenue 1 mois en production puis à été fermé pour deux raison : la première c'est que certaine partie du code n'était pas bien pensé, certaines page du site avait un temps de réponse de 10 secondes, ce qui donnait un jeu injouable. La deuxième raison c'est un mélange de mauvaise communication avec la communauté et une trop grande implication de ma part dans la communauté, en fait la communauté du jeu est aussi difficile à gérer que le jeu en lui même.

Après quelques semaine de réflexion, le projet à été pratiquement re-codé de zéro avec la prise en compte de notre expérience sur la première version, le code est de bien meilleur qualité, mais ce passage par la première version était nécessaire, on ne peux pas (enfin à moins d'être un génie, ce que je ne suis pas) faire une structure parfaite d'un projet qui compte des dizaines de millier de ligne de code du premier coup.

La version 1.1 du projet est en ligne maintenant

Bonne soirée.

[vermine]

Parfait, c'est courageux.

[kolodz]

J'aurai dû suivre ce projet !

Pour le problème de performance, je suis curieux de savoir ce qui était long. Je suppose que c'était le moteur du jeu qui était trop long sur certaines opération. Et je suis aussi curieux de savoir comment tu l'as résolu.

Il y a moyen d'en savoir plus ?

Cordialement,
Patrick Kolodziejczyk.

[Golgotha]

Kolodz,

Merci pour l'intérêt que tu porte à ce projet.

Nous somme maintenant dans la 3ème ré-écriture du projet, je peux vous dire que le code à bien changé depuis mes débuts ^^ le truc c'est que dans le domaine de la programmation MMO, il n'y à pas vraiment de manuel, de livre ou de tutoriel, le sujet et les secrets de fabrication sont bien gardé et je comprend mieux pourquoi maintenant.

Cependant, voici comment nous avons évolué :

Les problèmes de performance, viennent principalement d'une chose, le rafraichissement des données, nous avions opté pour un principe simple, c'est l'utilisateur qui déclenche le rafraichissement de ces données quand il fait une action sur sont compte.

Exemple : 1 utilisateurs a 2 planètes. On stock la dernière date de mise à jour de son compte, dans T par exemple.

Quand l'utilisateur fait une action, ont prends la date actuel D, on calcul l'intervalle de temps entre T et D (c'est en quelques sorte la monnaie du jeu, le temps) D-T = Delta

Avec ce Delta on va calculer tout un tas de chose, les ressources qu'il a gagné, les constructions à mettre à jours ..etc

Cette méthode marche, pour un nombre limité de joueur et de planète. En fin de test de la V2, les joueurs avec 20 Planètes ne pouvaient plus jouer convenablement, et nous nous sommes aperçu d'un nouveau bug.

Quand le joueur fait une action sur la page, cela déclenche donc la mise à jour de ces objets (planètes, bâtiments, vaisseaux etc...), quand ce calcul deviens long (par exemple avec 20 planètes) la page met un certains temps à répondre, l'utilisateur a alors le temps de changer de page, ou de faire un rafraichissement, ce qui peux conduire le serveur à stopper sont traitement initial et à invalider les données du joueur (Bâtiment construit mais qui prends 0 place sur la planètes.).

Nous avons donc décidé de re-penser complètement cela. Nous avons créer des processus externe, qui se chargerons de faire évoluer le monde, indépendamment du site web. Pour l'instant c'est encore dans une phase d'expérimentation mais nous devons écrire ces processus avec beaucoup de soin, ils doivent être intelligent, pour mettre à jour en premier lieu les planètes des joueurs qui sont le plus présent, extrêmement rapide pour que le jeux soit en temps réel, et surtout très fiable, ils doivent tourner 24/24 sans prendre plus de temps ou de mémoire.

La programmation en temps réel couplé avec des centaines de joueur, c'est un vrai défi... surtout quand on entre dans ce monde avec pour seul connaissance la programmation traditionnel, ça vous donne une sacré baffe. C'est aussi le projet le plus enrichissant et celui qui m'apporte le plus dans ce domaine.

[kolodz]

Ah !
Cela reprend, justement ce que j'ai testé cette semaine ! Peut-être sous un autre aspect :
Comment prendre en compte les évènements programmées quand on ne peux pas les réaliser à la date prévue ?
Plus dans l'optique, comment on gère les altérations d'une planète/village entre deux refresh. Mais, on en revient au même problème de cohérence des données et de temps de calcule.

J'ai fait des tests de performance en prenant différentes approches. Je reste persuadé qu'il est possible d'avoir une monté en charge sans processus externe. Mais je n'ai être pas un modèle suffisamment proche de la réalité pour m'en assurer.

Je suis d'ailleurs en cours de rédaction d'un article à ce propos sur mon blog developpez. Je serai très honoré de pouvoir avoir ton avis sur la question ou même voir l'implémentation que tu avais avant d'avoir un processus externe. Cela serai très instructif !

Cordialement,
Patrick Kolodziejczyk.

[Golgotha]

Oui, c'est vraiment LE gros problème : On ne peux pas simplifier, les tests sur un programme assez simple ne sont pas concluante à mon avis.

Le choix de processus séparé vient d'une multitude de problèmes :

- La sécurité des données : Si les actions de mise à jour importantes sont déclenchées coté client, cela induit une possibilité de "bidouille" par l'utilisateur, exemple avec un rafraichissement automatique de la page par un robot, avec des temps très court. Non seulement l'utilisateur peut corrompre ses propres données, mais cela peut aussi faire tomber le serveur entier...

- Les interactions multiples et les files d'attentes : Dans notre jeu il y a des files d'attentes sur les planètes, c'est-à-dire que le joueur peut demander la construction de 100 vaisseaux, alors qu'il ne peut pas encore les acheter, si c'est le joueur qui déclenche l'action de mise à jour, il faut alors prendre en compte le possible changement de taux de ressource (par exemple une mine construite) pour faire une prédiction correcte du moment ou la construction du prochain vaisseau va être possible. Viens ensuite le problème suivant : Deux joueurs envoient des vaisseaux sur une planète puis se déconnecte, un troisième joueur envoi un vaisseau sur cette même planète, le problème c'est qu'il faut que quelque chose déclenche l'événement de la rencontre des deux premiers joueur, alors qu'ils ne sont pas connectés, se pose donc la question de qui ou quoi va déclencher cette mise à jour, si aucun processus ne tourne : Le troisième joueur ? Et là c'est l'effet boule de neige, finalement, comment être sûr que tous les évènements ont bien lieu quand certains joueurs ne se connectent que tous les six heures ou tous les deux jours...

- l'évolution des joueurs déconnecté.

C'est vraiment le tout qui fait que ça deviens complexe, et on à une espèce de contradiction : Il faut que ça soit rapide, séquentiel et parallèle.

• Rapide : le jeu doit être en temps réel.
• séquentiel : les calcules doivent être réalisées dans un ordre précis.
• parallèle : le jeu est multijoueur.

Et c'est trois paramètres s'entre-choc si je puis dire, et on cherche un équilibre, Le point d'équilibre.. plus on va vers un point, plus on perd dans les deux autres.

Nous avons choisi (pour le moment, ça ne fait que la troisième fois qu'on recommence ^^) de partir sur des processus à part, les test nous donneront raison ou tord. Je ne pense pas qu'il y ai une bonne façon de faire dans ce domaine, ça dépends de beaucoup trop de paramètre, par exemple si le jeu ne comporte pas de fil d'attente, ça simplifie déjà pas mal les choses.

[kolodz]

Je n'avais pas dû tout penser aux files d'attentes !

Bon courage pour la suite.

Cordialement,
Patrick Kolodziejczyk.

PS : Je vais t'envoyer un MP pour te poser des questions du coup.

[lepotager]

Envoyé par Golgotha

...

Nous avons donc décidé de re-penser complètement cela. Nous avons créer des processus externe, qui se chargerons de faire évoluer le monde, indépendamment du site web.

...

C'est très exactement ce qu'il faut faire

[Golgotha]

Bonjour,

Après 1 ans et 2 mois, nous allons ouvrir la 2ème Béta, le 13.05.13

Le code du projet à beaucoup changé depuis les débuts, nous sommes toujours deux développeurs, le gros changement c'est le passage sur un serveur dédié, et sur un mode en deux parties, où le moteur du jeu est indépendant du site web. On est à 60K ligne de code maintenant environs.

Voilà, en espérant que l'ouverture de cette Béta débouchera sur une première version finie du jeu.

http://exile-reborn.com

[Golgotha]

Le serveur est de nouveau ouvert

[divxdede]

je vais tester pour voir ce que ça donne.

[kolodz]

Je pense avoir vu un bug au niveau de la réaffectation lor de la destitution d'un bâtiment :
J'avais juste assez pour construire une cité et j'ai voulu upgrader mes centrales.

1. Lancement de la construction d'une cité
2. Lancement de la création d'une centrale Geo
3. Destruction d'une centrale Solaire.

Après ces 3 manipulations, je me suis retrouver avec mes stocks de ressources au max comme avant le début de la construction de la cité. (Qui prend en gros tut mon stock de ressource à construire)

Tu me dira où je dois report les autres autres bug du genre. =)

Cordialement,
Patrick Kolodziejczyk.