Pour rendre les choses plus simples, je vais résumer chacun des points majeurs évoqués dans vos posts, et fournir des informations afin que chaqu'un puisse mieux comprendre. Adrian, Tony et moi avons fait notre mieux pour répondre à vos questions, et espérons que tout ceci va aider à mieux comprendre la technique en jeu.
Problème: Les 'Grey Blobs' sont une indication d'un mauvais design de la base de données et d'une mauvaise programmation réseau.
Réponse: Quand vous voyez des personnages gris, le client a déjà reçu toutes les informations du personnage venant du serveur, et est en train de charger les données, telles que les animations, textures, modèles, à partir du disque dur. Pour assurer un rafraîchissement régulier de l'écran et éviter son gel, nous chargeons les modèles sur une période de temps. Pour être sûr que les données sont disponibles rapidement, quand nous instancions un monstre sur le serveur, le monstre charge ses données à partir de la base, puis mets en cache celles-ci. Ce qui garanti que quand le monstre indique au client son apparence, il n'a pas besoin d?interroger la base de données. Les 'Grey blobs' sont le résultat du chargement des données à partir du disque.
Nous n'aimons pas ça non plus et sommes en train de créer un nouveau système de chargement des données plus élégant.
Problème: Mauvais planning, développement et design donnent un client qui est un amalgame de programmes et outils externes mal intégrés du à un manque de temps.
Réponse: Le développement du client d'horizons a été très long, et nous avons certainement fait de profonds changements durant celui-ci. Des composants COTS* (Composants logiciels vendus en module tout prêt, pour simplifier le développement, COTS signifie Commercial Of-The-Shelf) sont utilisés dans beaucoup de domaines, et le client fait bon usage d'Alchemy (moteur d'affichage de scènes), Granny (Moteur d'animations d'objet), Miles(moteur sonore) et dPVS(moteur de modélisation et d'optimisation de scènes et objets). Des logiciels de sociétés externes sont un bon choix quand ils résolvent des problèmes techniques tout en coûtant moins, en temps, argent ou expérience, qu'une solution développée en interne. Biens qu'aucun COTS ne soit parfait, je pense que ce choix nous a dirigé dans une direction positive, tout en réduisant les problèmes de temps argent et expérience. En terme de temps de développement, 3 à 5 ans est la norme dans les MMoRPGs. Horizons a fait des changements importants en milieu de parcours, mais tous les développeurs se sont adaptés à la difficulté. Il y a eu des fonctionnalités insuffisamment testées, des problèmes survolés quand nous essayons de sortir d'autres fonctionalités, ou des fonctionnements différents sur les serveurs 'Lives que sur le serveur de test. Mais tous les développeurs ont une grande fierté dans leurs travaux, et il est exact de dire que personne n'a assemblé quoique ce soit à la va-vite.
Horizons a été développé comme un MMoRPGS de la prochaine génération, et est un des rares produits disponibles qui supporte un environnement totalement dynamique sans zone. Chaque arbre, maison, rocher, effets de temps, terrains, et son régionnal est envoyé du serveur au client.
La plupart des produits ont une description du monde qui réside sur le disque du client, et qui est patché à chaque lancement du jeu, et / ou utilise une taille de région / zone fixe. Les raisons pour une taille fixe, ou une région fixe, et qu'un pré-calcul important est fait, comme les lumières, réflections, etc. Ce qui permet d'atteindre de plus haut rafraîchissement facilement, et réduit notablement la bande passante requise entre client et serveur.
Notre approche permettant des mises à jour en temps réel du terrain, autorise aussi la libre construction des plots, et les changement du monde en temps réel. Certains jeux ont des constructions de joueurs en se contentant de marquer les bâtiments invisibles, et les rendant visibles une fois construits. Nous sentons qu'il est important pour les joueurs de bâtir leur propre endroit du monde, et construit à leur envie. Horizons est le seul jeu actuel où le joueur a le complet contrôle sur le placement de ses structures, et nous pensons que c'est une fonctionnalité important qui vaut largement toutes les heures passées dessus.
La possibilité d'envoyer des mises à jour du monde change significativement le developpement du client, car cela nécessite un système complexe de gestion des ressources, chargeant et libérant dynamiquement les objets, et beaucoup d'autres problèmes qui auraient pu être évités si nous avions refuser un monde libre et des constructions sans contrainte. Je suis heureux que nous ayons fait ce choix, ainsi que d'autres choix de fonctionnalités. Il peut y avoir d'autre défis plus durs, mais Horizons ne seraient pas Horizons sans ses plots.
Problème: Les 'Abilities' basées sur des timers nécessitent des accès lecture et écriture sur la base de données pour chaque action. Tous les 'Gifts' et tout en général ce qui nécessite un timer est géré par le serveur et prend enormément de ressources sur la base de données.
Réponse: La plupart des timers résident sur le server, mais la base n'est pas impliquée. Les raisons pour placer les timers sur le serveur sont les suivantes:
- S'assurer que les problèmes réseaux n'interfèrent pas avec les intervales d'action.
- S'assurer qu'un client 'Hacké' ne peut pas envoyer d'actions très rapidement pour influencer les intervales d'actions.
Cela signifie que si une arme à un delai de 3,2s, alors l'arme sera actionnée toutes les 3,2s, même si le client a des problèmes de réseau ou autres. Pour des raisons de performances, notre implémentation est basée sur un 'Reactor Pattern' non bloquant. (c'est un système de communication entre objets basés sur des événements réguliers et optimisé pour avoir une charge processeur réduite et éviter les blocages des événements proritaires ou non). Nous sauvegardons les timers dans la base quand l'avatar est sauvegardé, ceci est fait pour éviter qu'un joueur ré-initialise les timers en se déconnectant.
Probème: mauvais design de base et de réseau implique que le 'vault' mets parfois plusieurs minutes pour s'afficher, ou pour que la récolte / le partage de matériaux mettent plusieurs secondes à se faire.
Réponse: Ceci est plus compliqué, car de nombreux facteurs entrent en compte, par exemple, pour le 'vault':
- Paquets réseaux perdus
- Nombre dsobjets dans le vault
- Réactivité du serveur
- Temps d'exécution de la requête de la base
- Traitement des données reçues
Je suis désolé de ne pouvoir donner de réponse plus claire, parce que beaucoup de réponsse ne peuvent être données qu'au cas par cas. Quelques fois il n'y a pas de réponse noire ou blanche, et des problèmes peuvent être dus à l'accumulation de beaucoup de petites choses. En dernier recours, j'espère que la liste des implications sur ce sujet permettra de bien voir la complexité de la chose.
Problème: le code réseau est responsable du moon walk, warp, glissement, de la rotation, des déplacements bizarres sur les ponts, tant pour les monstres que pour les joueurs.
Réponse: Ces problèmes sont presque toujours liés à des problèmes de prédictions. Basiquement, le monstre n'est pas affiché là où il est réellement. Pour clarifier les choses, les monstres sur le serveur ne prédisent pas les positions, ils sont comme les joueurs et envoient juste des mises à jour de leur position. Nous sommes au courant du problème, nous détestons que çela ne fonctionne pas correctement, et travaillons sur une correction. (un point: le client connaît la position initiale des monstres / joueurs, et reçoit régulièrement les mises à jour, entre deux mises à jour le client prédit où est potentiellement le joueur / monstre en fonction de son déplacement passé)
Problème: Le code réseau n'utilise pas toute la bande passante disponible, et le transfert des données semble avoir des goulots d'étranglement imposés à une fraction de ce qui pourrait nous être envoyé.
Réponse: Faire un usage optimal et judicieux de la bande passante est actuellement une fonctionalité implémentée, et, comme beaucoup de choses, a pris beaucoup d'efforts.
Du point de vue serveur, nous introduisons des limites pour nous assurer que tous les joueurs aient le minimum de bande passante requis, et que nous ne dépassons pas la bande passante de chaque joueur. Cela assure que les données arrivent le plus régulièrement possible, et de manière plus fiable, et au final, le traitement des paquets est plus prévisible.
Techniquement, notre configuration actuelle est capable d'envoyer environ 400kbps par connection. (environ 8 fois la bande passante d'une ligne téléphonique) en réalité chaque connection demande entre 20 et 30kbps, en fonction de la manière de jouer. Voir la question suivante pour savoir ce qui se passe si vous êtes entourés de 1000 monstres.
Problème: La quantité des informations est limitée, de telle sorte que 10 joueurs changeant de positions n'auront qu'1/10 de la précision en position et temps dont ils auraient besoin.
Réponse: je pense que les informations ci-dessous vont clarifier la situation:
1) il y a assez de bande passante pour envoyer régulièrement des mises à jour positionnelles pour plus de 10 joueurs, même sur une connection par modem.
2) Les informations positionnelles sont limitées par deux choses. Un nombre maximal de positions de joueurs, et une distance maximale autour du joueur. Si il y a 500 joueurs à 30m de celui-ci, nous ne surchargons pas la connection en envoyant les 500 positions à jour. Nous n'envoyons pas non plus les mises à jour des joueurs trop éloignés.
J'espère que cela répond à plusieurs de vos attentes, et nous nous excusons si nous ne répondons pas à tout. J'aimerais prendre part à la discussion qui s'ensuivra autant que possible, mais j'ai énormément d'autres choses à faire. J'aimerais remercier toutes les personnes pour leur intérêt pour ce thread et espère qu'il y ait plus de réponses que de questions.