Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con.

Cela veut pas dire que je crois pas au Serveur Meshing de Star Citizen, mais en faisant des recherches y'a des problématiques que personne sur ce forum n'a posé, et qui rend ce truc obligatoire un peu trop idéaliste...

Je précise, ici on va parler du Static Server Meshing promis dans les 12 mois, on va pas rentrer encore dans les délires d'instances qui se créent, parce que vous allez voir même en statique, on aura des soucis.

J'ai déjà fouiller le forum, et j'ai maté ces vidéos du directeur technique de CIG, il a l'air vraiment passionné et il a l'air de pas vouloir nous la mettre :
https://youtu.be/piJHV9WEQ_o
Et pour ceux qui ont le temps :
https://youtu.be/CrUUwolcZEw?t=4993

Regardez au moins la première vidéo avant de continuer.

Bon bah jusque là tout est calme, tout est beau, viens ensuite des questions que personnes n'a posés et qui reste importante :
- Le Serveur Meshing a besoin de synchronisé les différents nodes entre eux.
Sur leurs schéma d'escroc à https://youtu.be/CrUUwolcZEw?t=5753
il ne montre pas comment c'est censé se faire. (y'a pas deux flèches entre chaque nodes).

Certains vont dire qu'ils ont simplifier, mais que tout les nodes communiques entre eux,
NON NON NON,
ça marchera pas comme ça, parce que déjà ta pas besoin de faire communiquer tout les nodes entre eux, juste ceux qui sont cotes à cotes, et surtout pour sync deux serveur ensemble, faut qu'il communique

Donc tu envois un message supplémentaire. Par rapport à une architecture client / serveur classique, tu n'es plus efficace.

Bah oui, dans un serveur / clients classique, les clients envois leurs données, le serveur les sync.

Mais dans le cadre du serveur meshing, les client envoi leurs données, à plusieurs serveurs qui doivent communiquer ensemble PUIS renvoyer leurs données.
Y'a une étape supplémentaires, et en informatique, une étape supplémentaire = moins efficaces, parce que si tu fais ça avec deux serveurs, c'est OK, mais si tu as 4 nodes côtes à côtes dans une grande bataille spatial MON CUL SUR LA COMMODE qu'ils vont se sync, ils vont se ralentir les un les autres surtout si y'a beaucoup de joueur dans chaque instance.

Imaginez qu'un de ces 4 serveurs soit overload, il ne pourra plus se sync correctement avec les autres et les autres serveur vont avoir les mêmes que vous avez quand vous laguer sur minecraft, ils vont pas avoir les données à temps, et bah là tu te retrouves avec des serveurs qui lag entre eux...

Bon en vrai ça remet pas en cause le Serveur Meshing, ce que je viens de vous expliquer ne va pas arriver avec SC (normalement),
je pense que CIG à déjà prévu ça et c'est l'une des raisons pour laquelle vous n'avez que 3 instances dans leurs preuves de concept Serveur Meshing :
https://www.youtube.com/watch?v=UClkcRuGNF8

En gros vous avez un serveur Rouge, un Bleu et un Vert, mais vous n'avez pas de serveur entre le Rouge et le Bleu. Je pense qu'ils n'ont pas mis de 4 ème node car ils savaient que si tout les serveurs sur chaque node se voyait, il serait surcharger les un les autres et ça reviendrais à mettre un seul serveur pour tout le monde...

Pire, je pense aussi que ceux dans le serveur Rouge ne se Sync pas avec le serveur Bleu, quand vous regardez la démo, ils ne se voient pas y'a un mur entre les deux... Les serveur disparaissent sur les 4 l'écrans

En gros, le serveur Vert est le chef de la bande, il reçoit les données des deux serveurs et les renvoient au deux, c'est lui qui sera toujours le plus chargés des trois, vous me suivez jusque là ?

Cette surcharge du serveur Vert est exponentiel en fonction des joueurs que tu auras sur LES TROIS SERVEURS

Donc, pour l'instant sur du serveur Meshing, on ne montera pas à plus de 2 serveurs (je dis pas 3 car le Rouge et le Bleu ne sont pas sync entre eux)

Maintenant imaginons deux serveurs (une station et son intérieur) et l'espace avec des vaisseaux qui attaque la station :
Serveur A : Station
Serveur B : Space

On a 50 joueurs sur chaque serveur qui se combattent

Les serveurs pour chaque joueurs doit :
- Envoyés données au client
- Envoyés données au serveur adverse
- Envoyés données à la BDD
+ Si un joueur change de serveur, reprendre toutes les entités à l'autre serveur, ce qui va nécessité plusieurs échanges

Sur une architecture avec un seul serveur ça serait seulement :
- Envoyés données au client
- Envoyés données à la BDD

En gros y'a des cas d'utilisateurs, pas si spécifique que ça, ou il n'est pas intéressant de faire appel à du serveur Meshing
SURTOUT dans les cas des vaisseaux avec leurs propres serveur

Tout ça pour dire, ce que vous appelez du Serveur Meshing, ce sera juste du multi instance, la plupart du temps ce sera pas opti de l'utiliser, ils vont juste se contenter de foutre un serveur pour chaque lune / planète / système stellaire et vous n'aurez pas de bataille à 2500 joueurs dans plusieurs planètes parce que le jeu sera en PLS à cause de leur moteur qui stream tout.
Pour l'instant c'est ça l'avancement du Serveur Meshing de SC.

Après ça ne veut pas dire qu'ils vont pas réussir à le mettre en place avec plusieurs autres serveurs, ce défaut peut être corrigé en mettant un serveur "Chef d'orchestre" par exemple qui va s'occuper de dire à tout les nodes ce qu'ils doivent sync en priorité

Mais bon, c'est comme en automobile, plus tu ajoutes des pièces, moins c'est fiables et ce sera plus dur à maintenir.

Franchement j'aimerai bien en discuter avec des gens calé pour avoir leurs avis...

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

La surenchère de smileys tous plus ridicules les uns que les autres nuit à ta credibilité. Et surtout... Comme d'hab', j'ai pas lu tant c'est indigeste.

Mais rien que le début "dev touche à tout", bon en rien

Le 07 janvier 2024 à 09:52:07 :

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Le 07 janvier 2024 à 10:06:12 :

Le 07 janvier 2024 à 09:52:07 :

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Bonne lecture !

Streaming de conteneurs d’objets
Pour que le Server Meshing fonctionne, nous avions d’abord besoin d’une technologie qui nous permette de lier/délier dynamiquement des entités via le système de streaming, car ce n’est pas quelque chose que le moteur prenait en charge lorsque nous avons commencé. Ainsi, lorsque nous avons lancé le “Client Side Object Container Streaming” (OCS) en 2018, nous avons également lancé la toute première étape vers le maillage de serveur !

Une fois ce premier pas franchi, la technologie qui nous permet de lier/délier dynamiquement des entités sur le client devait être activée sur le serveur également (car, en fin de compte, les nœuds de serveur dans le maillage devront diffuser des entités en entrée/sortie de manière dynamique). Cette technologie est appelée “Server Side Object Container Streaming” (S-OCS), et la première version de S-OCS a été publiée à la fin de 2019. Il s’agissait de la prochaine grande étape vers le maillage de serveur.

Autorité des entités et transfert d’autorité
Alors que nous disposions de la technologie nous permettant de diffuser dynamiquement des entités sur le serveur, il n’y a toujours qu’un seul serveur qui “possède” toutes les entités simulées. Dans un maillage où plusieurs nœuds de serveur partagent la simulation, nous avons besoin du concept d'”autorité des entités”. Cela signifie qu’une entité donnée n’est plus la propriété d’un seul serveur de jeu dédié, mais qu’il existe plusieurs nœuds de serveur dans le maillage. Ainsi, un nœud de serveur qui contrôle l’entité, et plusieurs autres nœuds de serveur qui ont une vue client de cette entité. Cette autorité doit également pouvoir être transférée entre les nœuds de serveur. Une bonne partie du temps de développement a été consacrée au concept d'”autorité de l’entité” et de “transfert d’autorité” au cours du premier semestre de 2020. C’est la première fois que l’ensemble de l’entreprise a dû travailler sur le maillage des serveurs, car une grande partie du code de jeu a dû être modifiée pour fonctionner avec le nouveau concept d’entité-autorité. À la fin de l’année 2020, la plupart du code (de jeu) a été modifié pour prendre en charge le concept, donc une autre grande étape a été franchie, mais il n’y a pas encore de maillage réel en vue.

Couche de réplication et flux persistant
L’étape suivante a consisté à déplacer la réplication des entités dans un endroit central où nous pouvons contrôler le streaming et la logique de liaison au réseau. Cela nous permet ensuite de répliquer l’état du réseau sur plusieurs nœuds de serveur. Pour ce faire, nous avons dû déplacer la logique de streaming et de réplication du serveur dédié vers la couche “Réplication”, qui héberge désormais le code de réplication du réseau et de streaming des entités.

Dans le même temps, nous avons également implémenté le streaming persistant, qui permet à la couche de réplication de faire persister l’état des entités dans une base de données de graphes qui stocke l’état de chaque entité répliquée en réseau. L’année 2021 a été consacrée au travail sur la couche de réplication et l’EntityGraph, qui nous permet de contrôler le streaming et la réplication des entités à partir d’un processus distinct (séparé du serveur de jeu traditionnel dédié). Ce travail est presque terminé et se trouve dans sa phase finale.

Maillages de serveurs statiques et dynamiques
Cependant, ce n’est pas encore un “maillage”. Le travail sur le maillage proprement dit a commencé et il nous faudra une bonne partie de l’année prochaine pour le terminer, et toutes les conditions préalables que j’ai décrites ci-dessus étaient nécessaires pour en arriver à ce point. La première version de cette technologie sera un maillage de serveurs statiques et constitue le prochain grand pas en avant. Cependant, ce ne sera pas non plus la dernière ! Avec le maillage statique, nous disposerons de la première version d’un véritable maillage mais, comme le nom “statique” l’indique, la capacité à faire évoluer ce maillage est très limitée.

Avant de pouvoir vraiment qualifier cette fonctionnalité de complète, nous devrons franchir une autre étape importante, que nous appelons “maillage dynamique”. Cette étape nous permettra de mailler dynamiquement les nœuds de serveur ensemble, puis de faire évoluer le maillage dynamiquement en fonction de la demande. Une grande partie du travail sur cette partie se fait en parallèle. Par exemple, le gestionnaire de flotte qui contrôle la demande dynamique du maillage est déjà en cours de développement, de même que les exigences en matière de matchmaking qui accompagnent la nouvelle inclusion des “shards”.

Pendant ce temps, de nombreuses équipes de code de jeu doivent également travailler à l’adaptation du code de jeu existant pour qu’il fonctionne pleinement avec un maillage de serveur (et surtout trouver tous les cas limites qui ne feront surface qu’une fois que nous aurons un véritable maillage). Bien que le travail sur l’autorité des entités ait été achevé en 2020, l’autorité des entités n’est actuellement transférée qu’entre le client et un seul serveur, de sorte que certains codes peuvent nécessiter des ajustements supplémentaires.

Avec le maillage dynamique du serveur, il est possible que les grands vaisseaux, comme le Javelin, aient leur propre serveur dédié pour exécuter la simulation faisant autorité pour ce vaisseau et tout ce qu’il contient. Cependant, nous essayons d’éviter d’avoir des règles inflexibles sur la façon dont les entités sont assignées aux ressources de traitement, donc ce ne sera pas toujours le cas. C’est une question d’efficacité, tant en termes de vitesse de traitement que de coûts de serveur. Si nous avions une règle stricte selon laquelle chaque Javelin et tout ce qu’il contient reçoit son propre serveur, cela ne serait pas très rentable lorsqu’un Javelin ne compte qu’une poignée de joueurs. La même règle ne serait pas non plus efficace en termes de vitesse de traitement des serveurs s’il y avait des centaines de joueurs entassés dans le même Javelin, car la règle nous empêcherait de répartir la charge de traitement sur plusieurs serveurs.

Le maillage dynamique des serveurs sera un peu différent dans la mesure où il réévaluera constamment la meilleure façon de distribuer la simulation, afin de trouver le point idéal pour qu’aucun serveur ne soit surchargé ou sous-utilisé. Au fur et à mesure que les joueurs se déplacent dans le verse, la distribution idéale des ressources de traitement changera. Pour réagir à ces changements, nous devrons être en mesure de transférer l’autorité sur les entités d’un serveur à un autre, ainsi que de mettre en ligne de nouveaux serveurs et de fermer les anciens. Cela nous permettra de déplacer la charge de traitement d’un serveur qui risque d’être surchargé vers un serveur qui est actuellement sous-utilisé. Si aucun des serveurs existants ne dispose d’une capacité de réserve suffisante pour faire face à une augmentation de la charge, nous pouvons simplement louer d’autres serveurs auprès de notre fournisseur de plateforme en nuage. Et lorsque la charge de certains serveurs n’est plus suffisante pour les rendre rentables, certains d’entre eux peuvent transférer leurs parties de la simulation sur les autres et nous pouvons fermer ceux dont nous n’avons plus besoin.

Le 07 janvier 2024 à 09:58:00 :
La surenchère de smileys tous plus ridicules les uns que les autres nuit à ta credibilité. Et surtout... Comme d'hab', j'ai pas lu tant c'est indigeste.

Mais rien que le début "dev touche à tout", bon en rien

Bah c'est un sujet tellement complexe, tu ne peux pas expliqué les failles de ce truc à un profane sans faire un pavé. Les stickers c'est juste pour entre le truc plus espacé

Après tu pourras toujours gobé les salades qu'on te vend, moi je te le dis, même le StaticServeur Meshing sera pas si intéressant que ça.
Le jeu sera déjà plus jouable, et on aura un nombre de joueur max augmenter un peu sur chaque instance, mais les planètes sont tellement grande qu'être max 100 sur une planète, bah...

Le 07 janvier 2024 à 10:10:36 :

Le 07 janvier 2024 à 10:06:12 :

Le 07 janvier 2024 à 09:52:07 :

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Bonne lecture !

Tu vois c'est intéressant, parce que j'avais pas la partie "Couche de réplication et flux persistant", c'est en gros le maestro que j'ai décrit à la fin du pavé, mais c'est lui qui va bouffer toute la charge entre chaque nœud, donc si tu as mes 50 joueurs dans deux nœuds, c'est lui qui bouffe trois fois la charge au minimum (ça peut monter si les joueurs changent de nœuds).

Je te le dis, le Serveur Meshing tel qu'il est vendu ne va jamais arrivé, on aura juste des instances comme tout MMO...

Le 07 janvier 2024 à 10:21:14 :

Le 07 janvier 2024 à 10:10:36 :

Le 07 janvier 2024 à 10:06:12 :

Le 07 janvier 2024 à 09:52:07 :

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Bonne lecture !

Tu vois c'est intéressant, parce que j'avais pas la partie "Couche de réplication et flux persistant", c'est en gros le maestro que j'ai décrit à la fin du pavé, mais c'est lui qui va bouffer toute la charge entre chaque nœud, donc si tu as mes 50 joueurs dans deux nœuds, c'est lui qui bouffe trois fois la charge au minimum (ça peut monter si les joueurs changent de nœuds).

Je te le dis, le Serveur Meshing tel qu'il est vendu ne va jamais arrivé, on aura juste des instances comme tout MMO...

Le maillage du serveur a en fait très peu d’impact. Le client ne diffuse déjà que les entités qui sont à portée de vue. Il peut y avoir de légères améliorations, car nous pouvons être un peu plus agressifs avec l’élimination de la portée sur le client car, actuellement, certains objets ont un rayon de diffusion gonflé pour que des fonctionnalités comme le radar ou les missiles fonctionnent correctement. Avec le Server Meshing, nous pouvons découpler le rayon de diffusion du client et du serveur. Cependant, ces améliorations seront minimes sur le client. Néanmoins, des FPS plus rapides sur le serveur amélioreront l’expérience globale car le décalage du réseau sera considérablement réduit.

-----
Le streaming persistant et le maillage de serveurs augmenteront considérablement la quantité de données que nous devons faire persister, nous savions que nous devions faire quelque chose à ce sujet. C’est pourquoi Benoît et son équipe chez Turbulent ont complètement réinventé la façon dont nous allons faire persister les données sous la forme d’EntityGraph, qui est un service hautement évolutif construit au-dessus d’une base de données hautement évolutive qui est optimisée pour exactement le type d’opérations de données que nous effectuons. En plus de cela, nous développons également la couche de réplication, qui agit comme un cache en mémoire hautement évolutif de l’état actuel de toutes les entités d’un shard, éliminant ainsi la nécessité de la majorité des requêtes que nous envoyions aux services persistants existants. C’est vrai, il y aura des services hautement évolutifs jusqu’au bout !

Pour aider à réduire/éliminer toute latence supplémentaire que la couche de réplication pourrait introduire, nous la construisons pour qu’elle soit gérée par événement plutôt que par tic-tac comme un serveur de jeu traditionnel. Cela signifie que lorsque des paquets arrivent, il les traite immédiatement et envoie la réponse et/ou transmet les informations aux clients et serveurs de jeu concernés. Une fois que le travail sur la version initiale de la couche de réplication sera terminé (le service hybride), nous effectuerons un passage d’optimisation pour nous assurer qu’elle est aussi réactive que possible. Et, bien qu’il s’agisse en fin de compte d’une décision à prendre par DevOps, nous les déploierons dans les mêmes centres de données que les serveurs de jeu eux-mêmes, de sorte que la latence du réseau sur le fil due au saut supplémentaire entre la couche de réplication et le serveur de jeu devrait être inférieure à une milliseconde. Oh, et ai-je mentionné que la couche de réplication sera hautement évolutive ? Cela signifie que si nous détectons que la couche de réplication provoque des points de latence dans certaines parties du jeu, nous pourrons la reconfigurer pour remédier au problème.

Tres joli, TraumaTeam

En 2014 Chris Roberts a dit en personne que c'était des instances...
Il parlait de Terrada qui n'existe toujours pas ses milliers de joueurs dans la stratosphère et à la question les joueurs pourront ils se voir, il a répondu que non

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

hors la seul et unique solution est d'avoir un moteur capable de gérer de lui meme enormement de joueurs comme eve online, celui de CIG est minable on le dit depuis 12 ans

Bon maintenant leur rythme est de promettre dans 12 mois en début d'année le saint graal, cette année n'a pas echappé à la règle, le reste etant du pipeau de conférenciers dont ils nous abreuvent abondamment pour faire tomber les dons

Le 07 janvier 2024 à 11:02:08 :
En 2014 Chris Roberts a dit en personne que c'était des instances...
Il parlait de Terrada qui n'existe toujours pas ses milliers de joueurs dans la stratosphère et à la question les joueurs pourront ils se voir, il a répondu que non

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

hors la seul et unique solution est d'avoir un moteur capable de gérer de lui meme enormement de joueurs comme eve online, celui de CIG est minable on le dit depuis 12 ans

Bon maintenant leur rythme est de promettre dans 12 mois en début d'année le saint graal, cette année n'a pas echappé à la règle, le reste etant du pipeau de conférenciers dont ils nous abreuvent abondamment pour faire tomber les dons

Toi à la 4.0

Le 07 janvier 2024 à 10:21:14 :

Le 07 janvier 2024 à 10:10:36 :

Le 07 janvier 2024 à 10:06:12 :

Le 07 janvier 2024 à 09:52:07 :

Le 07 janvier 2024 à 09:24:37 :
Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Bonne lecture !

Tu vois c'est intéressant, parce que j'avais pas la partie "Couche de réplication et flux persistant", c'est en gros le maestro que j'ai décrit à la fin du pavé, mais c'est lui qui va bouffer toute la charge entre chaque nœud, donc si tu as mes 50 joueurs dans deux nœuds, c'est lui qui bouffe trois fois la charge au minimum (ça peut monter si les joueurs changent de nœuds).

Je te le dis, le Serveur Meshing tel qu'il est vendu ne va jamais arrivé, on aura juste des instances comme tout MMO...

C'est bien que tu le reconnaisses car c'est la remarque que je voulais te faire. Donc on peut discuter

Ton raisonnement est valide uniquement si le RL n'existe pas.

Sur la saturation expontentielle avec le nombre de joueur, elle est evitée grace à la fonction de Replication du RL. Le RL va garder en memoire(cache) toutes les infos nécessaires aux autres nodes et joueurs. Cela concerne non seulement les résultats des simu des nodes, mais surtout les lectures dans la base de données graphdB et tous les inputs des joueurs.

Grace au RL tu peux scaler en evitant le cauchemard du nombre de connexions direct.

D'ailleurs les nodes ne se connectent pas entre eux comme dans un réseau p2p. Ils passent exclusivement à travers le RL, justement pour eviter de transmettre N fois la meme info.

Enfin pour la synchro. Ce qu'on voit c'est que leur archi est asynchrone. Exactement comme ton client. Ton client ne se met pas en pause le temps de recevoir les infos serveur. Il les extrapole, puis corrige après. Ben la c'est parei coté node. Je n'en suis pas certain mais c'est ce qu'on peut comprendre.

CIG a dit explicitement que le RL recevait les données des RL en mode "push". Le RL fait transiter les infos entre tout le monde comme elles arrivent. Si un node tourne a 15 fps les infos arrivent à 15 fps et sont retransmises à 15 fps aux joueurs et nodes. Et si ca passe à 30, ben tout le monde recoit les infos à 30 fps.

Donc tu peux avoir un node vide à 30 fps et un node à coté à 5 fps. T'auras juste une zone de jeu qui galere pendant que l'autre tournera nickel.

Le 07 janvier 2024 à 11:15:32 :

Le 07 janvier 2024 à 10:21:14 :

Le 07 janvier 2024 à 10:10:36 :

Le 07 janvier 2024 à 10:06:12 :

Le 07 janvier 2024 à 09:52:07 :

> Le 07 janvier 2024 à 09:24:37 :

>Bon, je vous le dis tout de suite, je suis dev touche à tout, mais ça n'empêche pas de savoir qu'on va me la mettre quand on vend une feature ou une technologie à la con...

Un gros pavé avec plein de stickers pour donner du poids à ton récit, comme je les déteste, et tu aurais dû condenser sérieux...

Alors déjà le schéma "d'escroc" comme tu le prétends n'est pas fait par CIG mais par la communauté.
Ensuite tu ne fait que des spéculations, et il y a déjà des posts avec des débats sur le server meshing et de son possible fonctionnement.

Je t'invite aussi à regarder cette vidéo : https://www.youtube.com/watch?v=GYkTByID3BA
Sinon je propose aux modos de fermer cette horreur à lire, et de rediriger l'auteur vers le topic approprié du serveur meshing.

J'aurais aimé pouvoir modifier le post, mais je ne peux pas...

Par contre ce n'est pas des spéculations, regarde bien la démo serveur meshing, tu verras qu'ils montrent 4 écrans, chacun représentes le point de vue de chaque serveur et tu vois que pour les deux serveurs (Rouge et Bleu) ils se voient pas entre eux.

Ce cas de figure de Serveur Meshing avec 3 serveurs est idéaliste, mais il n'est pas applicable en réalité.

Et même avec deux serveurs, tu as toujours le soucis de communication entre serveurs, c'est pas non plus de la spéculation, mais de la logique, tu augmentes exponentiellement les communications = tu augmentes la latences exponentiellement aussi.

Tu penses pas qu'on a le droit de savoir un minimum comment ils comptent implémenter leurs trucs ? Sans donner trop de détails, juste faire un schéma pas fais par la commu...
Pour moi ça montre que eux même ils sont pas confiant dans la façon de faire...

Bonne lecture !

Tu vois c'est intéressant, parce que j'avais pas la partie "Couche de réplication et flux persistant", c'est en gros le maestro que j'ai décrit à la fin du pavé, mais c'est lui qui va bouffer toute la charge entre chaque nœud, donc si tu as mes 50 joueurs dans deux nœuds, c'est lui qui bouffe trois fois la charge au minimum (ça peut monter si les joueurs changent de nœuds).

Je te le dis, le Serveur Meshing tel qu'il est vendu ne va jamais arrivé, on aura juste des instances comme tout MMO...

C'est bien que tu le reconnaisses car c'est la remarque que je voulais te faire. Donc on peut discuter

Ton raisonnement est valide uniquement si le RL n'existe pas.

Sur la saturation expontentielle avec le nombre de joueur, elle est evitée grace à la fonction de Replication du RL. Le RL va garder en memoire(cache) toutes les infos nécessaires aux autres nodes et joueurs. Cela concerne non seulement les résultats des simu des nodes, mais surtout les lectures dans la base de données graphdB et tous les inputs des joueurs.

Grace au RL tu peux scaler en evitant le cauchemard du nombre de connexions direct.

D'ailleurs les nodes ne se connectent pas entre eux comme dans un réseau p2p. Ils passent exclusivement à travers le RL, justement pour eviter de transmettre N fois la meme info.

Enfin pour la synchro. Ce qu'on voit c'est que leur archi est asynchrone. Exactement comme ton client. Ton client ne se met pas en pause le temps de recevoir les infos serveur. Il les extrapole, puis corrige après. Ben la c'est parei coté node. Je n'en suis pas certain mais c'est ce qu'on peut comprendre.

CIG a dit explicitement que le RL recevait les données des RL en mode "push". Le RL fait transiter les infos entre tout le monde comme elles arrivent. Si un node tourne a 15 fps les infos arrivent à 15 fps et sont retransmises à 15 fps aux joueurs et nodes. Et si ca passe à 30, ben tout le monde recoit les infos à 30 fps.

Donc tu peux avoir un node vide à 30 fps et un node à coté à 5 fps. T'auras juste une zone de jeu qui galere pendant que l'autre tournera nickel.

Faux, le RL va bouffer tout les échanges entre le client et les serveurs de simu et il va se faire surchargé.
Pour chaque client un RL devra faire 3/4 échanges (client > RL > Simu > RL > client) - je compte pas les passages sur le RL donc ça fait 4 échanges - plusieurs fois par secondes (20 ticks au mieux, mais même à 5 ticks c'est énorme et inefficace). Imagine un peu avec une dizaine de joueurs comment il va prendre cher.

Surtout que la quantité de données des serveurs simu est non négligeables (calcules physiques, dégâts, déplacement etc...)

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

Tout est dit, rien à ajouté. Tu regardes l'équipe qui travail sur le projet et leur CV + ce qui se fait à côté sur les autres MMO avec des équipes bien meilleure. Tu as tout compris sur l'arnaque du server meshing qui est une carotte pour les dons.

Le 07 janvier 2024 à 12:54:31 :

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

Tout est dit, rien à ajouté. Tu regardes l'équipe qui travail sur le projet et leur CV + ce qui se fait à côté sur les autres MMO avec des équipes bien meilleure. Tu as tout compris sur l'arnaque du server meshing qui est une carotte pour les dons.

vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Le 07 janvier 2024 à 13:01:06 :
vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Visiblement, et comme je l'ai dit par le passé, c'est le genre de type à vouloir des gens de moins de 30 ans avec 15 ans d'expérience
Il y a bien une différence entre une équipe qui se donne les moyens et d'autres qui sont frileux à l'idée de prendre le moindre risque pour vendre la même soupe

Le 07 janvier 2024 à 13:01:06 :

Le 07 janvier 2024 à 12:54:31 :

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

Tout est dit, rien à ajouté. Tu regardes l'équipe qui travail sur le projet et leur CV + ce qui se fait à côté sur les autres MMO avec des équipes bien meilleure. Tu as tout compris sur l'arnaque du server meshing qui est une carotte pour les dons.

vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Benoit Beausejour le CTO de CIG

Brent Rich le CTO de Riot Games

C'est assez simple à constater on peut faire la même avec les gens chez Rockstar, chez Blizzard etc etc
Sans parler des études universitaires qui sont inexistante chez CIG. Et puis on va pas parler non plus des équipes qui ont vraiment aucune xp comparé aux autres studios. Bref ya juste à chercher sur Linkedin pour savoir.

Le 07 janvier 2024 à 13:07:53 :

Le 07 janvier 2024 à 13:01:06 :
vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Visiblement, et comme je l'ai dit par le passé, c'est le genre de type à vouloir des gens de moins de 30 ans avec 15 ans d'expérience
Il y a bien une différence entre une équipe qui se donne les moyens et d'autres qui sont frileux à l'idée de prendre le moindre risque pour vendre la même soupe

Riot Games a pris des risques, en 2009 avant de sortir leur jeu, ils ont emprunté de l'argent, ils étaient sur la paille si le jeu aurait pas fonctionné, ils auraient du rembourser des crédits sur plusieurs années. Ça c'est prendre des risques.

Faire de la RnD avec l'argent des autres pendant 11 ans tout en sachant que t'a 99% de chance de te planter, c'est pas un risque ça. D'ailleurs à voir les photos de Chris Robert et son yacht, il vie sa meilleure vie grâce à vous. Si tu veux, je peux te montrer les locaux de Riot Games en 2009, c'était pas les locaux de CIG à Manchester hein.

Un peu de respect envers les devs et les studios indé ou pas qui prennent des vrais risques avec leurs argents et qui se plantent souvent.

Le 07 janvier 2024 à 13:07:53 :

Le 07 janvier 2024 à 13:01:06 :
vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Visiblement, et comme je l'ai dit par le passé, c'est le genre de type à vouloir des gens de moins de 30 ans avec 15 ans d'expérience
Il y a bien une différence entre une équipe qui se donne les moyens et d'autres qui sont frileux à l'idée de prendre le moindre risque pour vendre la même soupe

S'il y a bien des personnes qui ne prennent aucun risque financier si ce n'est percevoir leur salaire de directeurs c'est bien star citizen sans compter la revente des biens acquis et des goodies

LE vrai risque aurait ete de mettre 700 million de dollard sur la table des 2012 et faire le pari de se faire rembourser par les dons, mais ça ils se sont bien gardés de le faire

Le 07 janvier 2024 à 13:23:08 :

Le 07 janvier 2024 à 13:01:06 :

Le 07 janvier 2024 à 12:54:31 :

Cela fait plus de 25 ans que des ingenieurs senior, pas les juniors sortis des écoles de CIG qu'il faut former, ce n'est pas moi qui le dit c'est eux.
Si la solution miracle existait, tous les jeux en ligne l'aurait adopté...

Tout est dit, rien à ajouté. Tu regardes l'équipe qui travail sur le projet et leur CV + ce qui se fait à côté sur les autres MMO avec des équipes bien meilleure. Tu as tout compris sur l'arnaque du server meshing qui est une carotte pour les dons.

vous avez cru que c'était des junior qui s'en chargeait du meshing ? Ah et c'est pas parce que t'es junior que t'es débile et incapable.

Benoit Beausejour le CTO de CIG

Brent Rich le CTO de Riot Games

C'est assez simple à constater on peut faire la même avec les gens chez Rockstar, chez Blizzard etc etc
Sans parler des études universitaires qui sont inexistante chez CIG. Et puis on va pas parler non plus des équipes qui ont vraiment aucune xp comparé aux autres studios. Bref ya juste à chercher sur Linkedin pour savoir.

Donc, si je comprends bien ton propos, un mec qui a monté une boite et l'a fait tourné pendant 21 ans est moins compétent qu'un type qui a simplement gravi les échelons du monde de l'entreprise en changeant de boite tous les ans ?

J'adore les forums de JVC, tu peux te permettre d'insulter des gens dans leur dos sans même avoir a les connaitre, sur la base d'informations parcellaires trouvées ça et là sur le net.