Chad McKinney est toujours aussi impressionnant dans son rapport avec la communauté, une fois encore il n'a pas hésité à répondre aux questions des Backers sur le Spectrum, même les questions les plus insignifiantes ou celles dont on a déjà eu mainte et mainte fois des réponses.
Ce matin, j'ai donc dû faire un tri, relever les questions qui m'ont semblé réellement pertinentes, aussi bien au niveau de la question que de la réponse donnée, afin d'apporter une traduction complète ou partielle, et pour d'autres ce ne sera qu'un simple résumé.
L'une des ces questions porte sur les "casiers à monstres", récemment évoqué par CIG pour permettre de faire entrer ou sortir un PNJ dans le Verse, un joueur s'interroge du coup sur l'impact de ces casiers reproducteurs sur le jeu et du fait de la pertinence de sa question j'ai jugé bon d'en traduire l'intégralité.
Les casiers à monstres seront-ils utilisés pour "faire semblant" à long terme ?
Qu'en est-il de Quantum ?
Pour moi, l'un des aspects les plus importants de Star Citizen, peut-être même le plus important, est que Star Citizen fait tout son possible pour ne jamais "faire semblant". Star Citizen essaie de tout faire, de manière simulée et systématique autant que possible, et suffisamment tactile pour permettre aux joueurs de voir clairement comment tout est fait avec le moins de fioritures possible. Je pense que c'est une des raisons principales pour lesquelles les gens n'aiment pas les ascenseurs magiques qui se déplacent librement dans l'espace, préférant les ascenseurs entièrement matérialisés comme ceux de GrimHex et de Levski. Le "Verse" tactile est certainement l'un des aspects les plus importants qui expliquent pourquoi Star Citizen se sent si réaliste et immersif.
Les "casiers à monstres" apparaissent comme une autre étape, comme les ascenseurs, dans la direction du "faux". Un casier à monstres est une porte avec un petit placard derrière laquelle les PNJs peuvent être engendrés et détruits hors de vue, sans aucune restriction quant au nombre de PNJs qui sont engendrés, ou au taux d'engendrement. Auparavant, la principale consigne était que tous les PNJ aient un cycle de vie complet, aient un emploi à la station en tant que gardien de sécurité, commerçant, technicien de réparation, etc., dorment en habit et aient du temps libre pour se déplacer et utiliser les installations. Le système d'agents de Quantum promet d'étendre ce plan à l'ensemble de l'univers, en transportant des gens, des pirates et des commerçants autour du Verse, simulé à haute efficacité lorsqu'il est hors de portée d'un joueur, mais en déplaçant chaque PNJ individuellement en tant qu'agent. Potentiellement, un joueur pourrait suivre n'importe quel PNJ, par exemple un commerçant, lorsqu'il rejoint l'équipage de son navire de commerce, décolle et s'envole ailleurs, atterrit et vaque à ses occupations en général lorsqu'il se déplace autour du Verse. J'espère sincèrement que nous pourrons même nous faufiler à bord du navire marchand du PNJ et voir l'équipage mener sa vie à plein temps à bord du navire alors qu'il suit sa route commerciale ! Peut-être même nous révéler comme un passager clandestin et vivre une aventure improvisée avec les commerçants du navire PNJ, jusqu'alors non décrit, selon la personnalité du capitaine et de l'équipage.
Les casiers à monstres vont à l'encontre de ce plan. Plutôt que de faire vivre aux PNJs un cycle de vie complet, le but des casiers à monstres est de faire naître des PNJs à partir de rien, de leur faire accomplir une tâche spécifique dans le monde, puis de les renvoyer dans un casier à monstres pour qu'ils soient détruits. Cela facilite les choses ; c'est pourquoi les jeux le font traditionnellement de cette manière. Vous n'avez pas besoin de vous soucier de faire déplacer les PNJs vers un endroit où ils sont nécessaires, vous les faites surgir du néant quand vous en avez besoin.
Il est également évident que le jeu est truqué lorsque le nombre de PNJ que vous souhaitez, y compris un nombre infini, peut sortir d'un petit espace artificiellement fermé, caché derrière une porte. Il ne s'accorde pas systématiquement avec le reste du Verse et, comme les ascenseurs, il se fera remarquer !
Un joueur ne peut jamais suivre un PNJ dans un casier à monstres. On ne peut jamais voir le cycle de vie complet d'un tel PNJ, car il n'aura pas un cycle de vie complet. Il sera juste engendré et désespéré selon les besoins. Cela dévalorise considérablement le PNJ ; vous savez que le PNJ n'a été créé que pour cette occasion, et qu'il sera détruit une fois sa tâche terminée. Le PNJ n'a aucun impact sur la vie du Verse.
Donc, ma question est la suivante :
Les casiers à monstres sont-ils une solution à long terme ? Sont-ils censés exister dans le jeu à la sortie, ou sont-ils une mesure temporaire qui sera supprimée une fois que Quantum sera en ligne et pourra créer des cycles de vie complets pour les PNJ ?
Les casiers de reproduction vont effectivement faire partie de la solution à long terme du jeu, mais il y a certains détails clés que vous ignorez peut-être. Tout d'abord, on suppose ici que les entités engendrées par ces casiers sont des ardoises complètement vierges et qu'on ne les reverra plus jamais lorsqu'elles se désagrègeront. Ce ne sera pas le cas pour tous les PNJs car il y a au moins deux mécanismes que nous allons utiliser et qui résulteraient en un comportement similaire à celui que vous recherchez. Premièrement, il y aura une classe de PNJ de plus grande importance qui aura une certaine quantité de simulation virtuelle même si aucun joueur n'est présent. Ces PNJs pourraient faire partie d'une mission par exemple, et leurs horaires et leurs déplacements dans le Verse seront simulés en arrière-plan. Lorsque vous les rencontrez une fois, ils peuvent apparaitre ou quitter une zone via un casier de reproduction selon les circonstances, et vous les reverrez probablement plus tard.
Un autre cas est que le backend va en fait suivre les entités qui ont été créées via un service de création d'archétypes de personnages, et chacune de ces entités aura diverses propriétés et balises qui peuvent être utilisées pour correspondre à des demandes futures. Cela signifie par exemple que si vous volez quelque chose dans un magasin ou essayez d'agresser quelqu'un et que la sécurité est appelée de manière dynamique, il est possible que le même agent de sécurité vous arrête plus tard ou soit appelé en renfort à un contrôle routier.
Étant donné l'étendue du monde que nous essayons de créer, il serait en fait impossible de simuler tous leurs horaires et chaque détail de leur vie, mais nous pouvons faire la différence en utilisant une combinaison de création dynamique, de simulation virtuelle et de réutilisation de modèles pour obtenir le type de jeu que vous recherchez.
Les placards et les casiers de reproduction sont simplement un moyen de faire entrer ou sortir des entités d'un endroit, mais ils ne sont pas le créateur de cette entité dans notre monde de jeu, c'est plutôt le système d'archétype du personnage qui va les suivre, donc leur programmateur peut les faire monter dans un train, aller au travail, revenir, aller dîner, dormir, etc. et oui, dans certains de ces points de mouvement, il y a peut-être un casier de reproducteurs impliqué, mais cela ne signifie pas que chaque PNJ que vous voyez est seulement probabiliste. L'idée est que les quanta et les autres systèmes comme le système de mission dynamique pourront utiliser les casiers de reproduction pour faciliter le déplacement des entités à travers le monde, et lorsqu'il y a des surtensions nécessaires (sauvegarde de sécurité, etc.) avoir un moyen d'amener les PNJ dans les zones nécessaires sans interrompre l'immersion.
Gardez également à l'esprit que les casiers de reproduction ne seront pas le seul moyen d'y parvenir, car lorsque vous êtes au milieu de l'espace ou dans une zone aléatoire sur une planète, d'autres mécanismes peuvent être utilisés, comme les PNJs engendrés par le QT ou les dropships.
-- Chad McKinney
Pourriez-vous, par hasard, revenir en arrière et régler tous les problèmes connus ?
Voici le genre de question qui fût déjà posée par le passé, venant généralement de joueurs qui ont du mal à comprendre le concept d'Alpha, et Chad est bien gentil d'y répondre une nouvelle fois. J'ai malgré tout conservé la réponse de Chad, mais écourté la question pour n'en garder que l'essentiel.
Chaque patch, il y a une liste de problèmes connus, mais la moitié de ces problèmes ne sont jamais réglés dans le PTU, et sont poussés sur le LIVE, et ensuite CIG oublie pratiquement ces problèmes, et les laisse persister pendant des mois, voire des années (...)
Pensez-vous qu'il soit possible de faire plus d'efforts pour corriger tous les bugs de rupture du jeu avant que les patchs ne soient mis en ligne, ou dès que possible ?
Il faut toujours trouver un équilibre entre la correction des bogues et le développement des fonctionnalités (et généralement se diriger vers une version 1.0).
Nous pourrions arrêter ce que nous faisons et nous concentrer vraiment sur l'élimination des bogues, mais alors le prochain patch serait très léger sur les fonctionnalités.
De plus, lorsque vous travaillez sur de nouvelles fonctionnalités, il arrive souvent que des bogues se reproduisent ou que le système qui en était victime soit modifié ou même supprimé, le problème est donc que vous visez toujours une cible mouvante. Les jeux qui n'ont pas à soutenir un produit en direct ont l'avantage de pouvoir laisser les choses se casser de différentes manières pendant qu'ils finissent le jeu et de laisser de la place pour le flux. Vers la fin, vous avez alors un gros effort à faire pour peaufiner et finaliser les choses (et souvent vous atterrissez avec un patch du jour 1 pour démarrer). Pour les jeux en direct, vous devez cependant maintenir les choses à flot tout en essayant d'avancer.
Finalement, il s'agit donc simplement d'un équilibre et plus vous vous concentrez sur la correction des bugs, plus vos objectifs de développement peuvent prendre du temps.
-- Chad McKinney
Le "i" de iCache, c'est pour "Ignite" ?
L'iCache est le sujet du moment, et c'est normal du fait qu'il soit attendu, de nombreuses questions tournent autour de l'iCache, et certaines sont parfois... surprenantes... Mais pas sans intérêt... Comme celle-ci...
En regardant cette intéressante vidéo de Fondation Apache aujourd'hui, je me suis rendu compte que c'était comme Ignite Cache, qui dans mon cerveau s'est transformé en iCache, car Ignite semble faire beaucoup de choses dont iCache est censé s'occuper.
Est-ce qu'iCache va s'installer au-dessus d'une technologie open source ou est-ce qu'il est complètement fait maison ?
Non, le "i" dans iCache n'est pas pour "ignite", il est pour "item". Il s'agit en fait d'une raison historique anecdotique plus que tout (Il y a deux problèmes difficiles en informatique : Nommer les choses, Invalidation du cache, et les erreurs "off-by-one"). Dans l'implémentation originale de la persistance, les "objets" étaient les seules choses qui étaient stockées (armes, armures, centrales électriques, etc.), donc le cache pour les entités peut avoir été plus prescient, mais le cache pour les objets (items) est resté et c'est ainsi.
Maintenant, pour répondre à votre question, est-ce qu'il va se placer au-dessus de l'open source ? Oui et non. Je vais d'abord être un peu plus précis et souligner que, techniquement, la flotte de services iCache fait partie d'un écosystème plus large de services et de systèmes de jeu pour la persistance globale et l'architecture de streaming des serveurs. Si nous ne parlons que l'iCache lui-même, il s'agit donc en grande partie d'une solution écrite sur mesure. Cela dit, l'équipe responsable de l'arrière-plan utilise certaines bibliothèques open source, ce qui fait qu'elle n'est pas entièrement propriétaire, mais il est certain que ce n'est pas Ignite d'Apache. Cependant, si vous prenez du recul et que vous regardez l'écosystème plus large, vous pouvez certainement trouver des technologies qui sont construites sur des sources ouvertes telles que Kafka, Redis, Mongodb, etc. et nous cherchons également à déplacer certaines parties de notre backend vers une architecture native du Cloud, y compris l'utilisation de grpc. Une tonne de travail a été consacrée à ces projets et, lorsqu'ils seront utiles, nous les exploiterons certainement, même s'il y aura toujours des moments où la meilleure solution sera quelque chose que nous devrons faire nous-mêmes pour un projet aussi unique que Star Citizen.
-- Chad McKinney
Le SSOCS n'a-t-il pas fonctionné comme prévu ?
En voilà un qui en a gros, manifestement il en attendait beaucoup plus des "promesses" faites autours du SSOCS et a encore un peu de mal à comprendre que chaque amélioration technologique ne va pas forcément se ressentir en jeu de façon immédiate, mais que c'est l'ensemble de toutes ces technologies que sont le SSCOCS, l'iCache, le Server Meshing, etc. qui vont permettre d'arriver aux résultats attendus, et encore, même une fois ces technologies toutes en place il y aura probablement encore du travail à accomplir...
Devons-nous attendre la version 2 du SSOCS ?
Les ressources et les outils pour la génération de localisation procédurale ne sont-ils pas encore prêts ?
Ces éléments seront-ils intégrés dans la prochaine version de Planet Tech ?
Avez-vous affecté ces ressources ailleurs parce que ce n'est pas une priorité ?
Attendez-vous que l'équipe d'acteurs intègre des personnes générées par la procédure dans ces lieux ?
Le SSOCS a fonctionné comme prévu et l'argument de Tony est toujours valable. Il y a d'autres raisons pour lesquelles nous n'avons pas repoussé les limites du nombre de ces zones satellites, y compris le travail effectué sur les outils de génération procédurale pour rendre ce contenu intéressant et améliorer le pipeline de création.
Le passage à iCache nous aidera également à avancer dans cette direction puisque nous pouvons pré-ensemencer la base de données avec le contenu et ne pas avoir à le stocker localement en mémoire sur chaque DGS comme nous le faisons maintenant avec le prototype actuel de backend SSOCS.
-- Chad McKinney
Avec un certain nombre de caractéristiques retenues par des conditions préalables, comment les ressources sont-elles utilisées en attendant ?
En voilà une question piège : Mais que font les devs quand ils doivent attendre que technologie dont ils dépendent soit libérée ? Malheureusement, la réponse de Chad n'apporte pas vraiment de lumière à cette question, il nous faudra probablement patienter jusqu'à la sortie de la nouvelle RoadMap pour ce faire une meilleure idée de « qui fait quoi pendant qu'il doit attendre que d'autres aient terminé leur boulot ? »
Un certain nombre de fonctionnalités étant (d'après ce que j'ai compris) bloquées par des prérequis (comme l'iCache qui bloque le Serveur Meshing, Pyro, l'inventaire physique, etc.), comment les ressources travaillant sur ces fonctionnalités se plient-elles à ces prérequis ? Les développeurs sont-ils encore capables de travailler sur ces fonctionnalités, ou faut-il d'abord que les prérequis soient entièrement/partiellement remplis ?
Dans ce dernier cas, où ces ressources sont-elles allouées ?
Travaillent-ils sur quelque chose de nouveau pendant qu'ils attendent ou autre chose ?
Je suis juste curieux de savoir comment la difficulté à développer la technologie de ce jeu affecte la capacité à travailler sur d'autres fonctionnalités.
Chaque cas est différent, il n'y a donc pas une seule réponse. Dans certains cas, les équipes travaillent simplement sur autre chose, mais il y a des endroits où certaines parties deviennent disponibles pour un usage interne et des tests, de sorte que des fonctionnalités peuvent être développées en fonction de ces cas, même si l'ensemble n'est pas prêt à être publié.
-- Chad McKinney
Q&R en vrac
Certaines questions/réponses sont si succinctes que j'ai préféré les résumer ou les tronquer plutôt que les traduire. Ce n'est pas à mon habitude, mais comme évoqué ce samedi, je dois consacrer moins de temps à la gestion du site et il m'est ici plus simple et plus rapide de résumer ou d'effectuer une traduction partielle que de traduire intégralement et mettre au propre certaines Q&R.
Dans quelle mesure Quantum fonctionne-t-il, si tant est qu'il fonctionne ?
La réponse de Chad est sans surprise, c'est en court de développement, mais on apprend qu'il a pu voir une démo récemment organisée par les concepteurs pour montrer les progrès réalisés, mais qu'ils ne sont pas encore prêts à nous en montrer plus.
Pourquoi ne puis-je pas "vivre" dans mon Carrack ?
Une question récurrente sur les bugs de déconnection dans l'espace ou sur une planète qui ne nous permet pas toujours de réapparaitre au bon endroit, et généralement on se retrouve proche du soleil de Stanton. Mais la question est plus ciblée sur l'impact que pourrait avoir l'iCache sur ce bug, je vous laisse donc la réponse de Chad :
L'iCache et la persistance globale devraient certainement aider à la déconnexion des lits et nous donner l'architecture dont nous avons besoin pour aller au-delà. Le problème avec le système actuel est que, comme nous n'avons pas vraiment de persistance globale, il existe une sorte de machine de Rube Goldberg pour sauver et reconstruire les parties impliquées pour le faire fonctionner. Avec la persistance globale qui disparaît et au lieu d'utiliser un mécanisme très rond, tout est persisté dans l'espace, ce qui devient le cas commun.
-- Chad McKinney
Les nouveaux panneaux d'ascenseur supporteront-ils le "Quick-Press F" ?
Je ne sais pas vous, mais moi, la refonte des panneaux d'ascenseur me rend dingue, et me retrouver avec une liste à rallonge qu'il faut faire défiler jusqu'en bas pour enfin pouvoir accéder au bouton souhaité me fait dire que la refonte des panneaux d'ascenseur est plus jolie, mais bien moins pratique que l'ancienne version, et pourtant, l'ancienne version est loin d'être idéale.
Alors quand un joueur évoque la possibilité d'utiliser le Quick-Press F pour accéder plus rapidement à la fonction recherchée, cela me fait chaud au coeur même si je pense que cela ne solutionnera pas pour autant le problème qui est plus dans la disposition des touches (éviter le défilement) qu'autre chose. En tout cas, la réponse de Chad ne permet pas de dire si cela sera amélioré ou non, il fait suivre, c'est déjà ça...
C'est la conséquence du passage à une mise en oeuvre basée sur l'IU au lieu du système d'interaction qui a cette caractéristique d'interaction rapide. Le cadre de l'interface utilisateur pourrait l'ajouter en option, en partie c'est une question de conception, et ensuite il faudrait un peu de réflexion sur la façon dont vous dictez le choix par défaut, puis les implémentations existantes devraient être mises à jour, mais c'est possible. Je vais peut-être le soumettre à l'équipe UI pour voir ce qu'elle en pense.
-- Chad McKinney
A l'avenir, pourrons-nous acheter/louer des hangars/appartements/aires dans le Verse pour nous-mêmes ou nos organisations ?
L'achat et la location d'espaces font depuis longtemps partie de notre vision, bien que l'iCache et la persistance globale soient essentielles pour rendre cela possible.
Y a-t-il eu des changements dans ces idées et si oui, pouvez-vous nous dire ce qu'ils sont ?
Oui, je suis sûr qu'il y a eu des changements au fil des ans, selon la personne à qui vous avez posé la question et la citation à laquelle vous faites référence, il serait donc difficile de répondre exactement. Cela dit, si je pouvais généraliser, je dirais qu'avec les planètes procédurales et la persistance globale, nous nous sommes donné la possibilité d'être beaucoup plus ambitieux avec ces idées que ce que l'on pensait possible à l'origine.
-- Chad McKinney
Quand les planètes commenceront-elles à tourner en orbite ?
Je ne suis pas dans la communauté depuis longtemps, mais il est clair que les planètes ne sont toujours pas en orbite les unes autour des autres. J'ai entendu dire que certains bloqueurs doivent être retirés avant de commencer. Mais je n'ai jamais eu tous les détails sur ce qu'il faut faire pour que les planètes commencent à tourner en orbite.
Est-ce également lié au fait qu'il faut le Server Meshing et l'iCache pour soutenir cela ?
Voici au moins une chose que je peux dire qui ne dépend pas de l'iCache. Non, en fin de compte, il y a beaucoup de petits problèmes qui surgissent lorsque vous mettez en orbite (ce que nous avons pu faire pendant des années en fait !), car cela pose des problèmes dans de nombreux systèmes de jeu. En voici un exemple : La navigation. Imaginez que vous voulez tracer la route d'un satellite à un avant-poste sur une lune à travers le système solaire. Selon votre vaisseau, cela peut prendre un certain temps et, au moment où vous vous retrouvez à mi-chemin du saut, la route que vous avez empruntée peut devenir invalide car elle peut être bloquée par un objet qui s'est déplacé en vue. Ce n'est pas un problème insurmontable et nous avons des plans sur la façon de le résoudre, mais nous n'avons pas encore fait le travail.
-- Chad McKinney
Mobiglass pour appeler/stocker les navires ?
Pourquoi ne pouvons-nous pas utiliser notre Mobiglass lorsqu'il est à portée pour appeler ou stocker des navires ? Cela semble être une question de bon sens, une valeur ajoutée qui existe aujourd'hui avec les sociétés de location de voitures.
La question tombe sous le sens, la réponse de Chad est plus prudente et se résume à :
Oui, c'est prévu d'améliorer tout cela, mais on ne peut en dire plus pour l'instant
Pop-up des Contrat/Mission "d'assistance au combat"
A croire que ce joueur a lu dans mes pensées...
-- ile-avalon
Pour moi, ces pop-ups sont assez ennuyeux et envahissants car ils sont parmi les seuls qui se produisent pour les missions alors que tous les autres existent au sein du gestionnaire de contrat. Sans le casque, elles sont encore plus envahissantes car le texte est massif et ne tient pas facilement sur l'écran.
Quelques questions au hasard concernant les pop-ups :
Ces missions ne sont-elles disponibles que pour être acceptées avant que la pop-up ne disparaisse ?
Ou bien ces missions apparaissent-elles dans le gestionnaire de contrats ?
Pouvons-nous avoir la possibilité de "cacher" ces pop-ups si nous voulons les ignorer ?
Est-il prévu d'améliorer les pop-ups/notifications du HUD pour les contrats ?
Nous prévoyons de revoir les balises de service et les contrats, notamment pour améliorer le traitement des notifications. Nous avons prévu de travailler sur un nouveau système de notification qui permettra de faire la queue dans une application mobiglas afin de ne pas devoir se contenter de recourir à des lecteurs de spam, et de disposer de filtres configurables pour mettre en sourdine certains types de notifications. Les balises de service et autres systèmes de jeu seront portés sur ce nouveau système et nous espérons que vous aurez un peu de tranquillité !
-- Chad McKinney
Quantum et Quanta. Le rapport 9 pour 1 entre PNJ et joueurs n'existe plus ?
Depuis le début du projet, on nous a dit que l'économie sera tirée par les PNJs puisque le ratio par rapport aux joueurs serait de 9 pour 1.
Lors du récente AMA avec Chris Roberts, Todd Pappy et Tony Zurovec, M. Zurovec a déclaré, à propos de Quantum et Quanta :
Nous avons passé beaucoup de temps et d'efforts à optimiser la simulation et nous faisons maintenant des tests avec pas moins de deux millions de quanta, mais il semble que nous n'aurons pas besoin de plus de 100K par système pour obtenir les effets souhaités.
Cela signifie-t-il qu'il n'est pas nécessaire d'avoir un ratio PNJ/joueur de 9 pour 1 ?
Que se passera-t-il s'il y a 100 000 joueurs dans un système (ce qui n'est pas impossible, surtout dans les premiers jours suivant le lancement officiel) ? Les joueurs pourront-ils prendre le contrôle de l'économie dans ce système puisqu'il y a autant de joueurs que de Quanta ?
Et comment les rencontres aléatoires fonctionneront-elles si le ratio PNJ/joueur n'est plus de 9 pour 1 ?
Une question fort pertinente, la réponse l'est beaucoup moins, mais je doute que Chad soit la personne la mieux placée pour répondre à une telle question.
Ce que vous considérez comme le ratio va devenir très flou en raison des quanta, de la génération probabiliste, de l'IA virtuelle et des missions. D'une certaine manière, vous pourriez considérer que cela va bien au-delà de ce ratio, en fonction de ce que vous comptez comme PNJ.
-- Chad McKinney
Comprendre le système de coordonnées 64 bits et l'intégration possible avec Server Meshing ?
Une petite dernière pour la route...
M'est avis que ce joueur n'a pas poussé assez loin sa recherche avant de poser sa question, mais il est vrai que cet aspect technique n'est pas évident à assimiler, surtout si l'on prend le train en route... Quoi qu'il en soit, sa question sera probablement utile à beaucoup d'autres et j'ai donc pris soins de la traduire en intégralité.
Je recommande aussi les vidéos de Pulsar42 et Schneider, elles sont très utiles à la compréhension des différentes technologies que CIG met en place.
STAR CITIZEN - Instances et serveurs dans Star Citizen
STAR CITIZEN - Object Container Streaming et Server Meshing
A noter qu'il existe des vidéos plus récentes sur le sujet chez Pulsar42, mais je n'ai pas encore eu le temps de les visionner moi-même et préfère donc vous renvoyer vers des vidéos dont je connais le contenu. Mais n'hésitez pas à parcourir la chaîne de Pulsar42.
Je suis vraiment impressionné par l'ampleur du jeu. J'ai essayé de comprendre comment gérer la localisation des entités dans un système de coordonnées aussi vaste. J'ai lu et regardé des vidéos sur le "moteur des étoiles" (je crois que c'est le nom non officiel de ce jeu).
Donc, première question :
De la planète à la bouteille d'eau : Une planète a ses coordonnées à l'intérieur d'un système. Cela fait beaucoup de chiffres pour les coordonnées. Mais nous avons une bouteille d'eau quelque part qui doit être rendue et placée sur l'écran. Cette bouteille d'eau a aussi besoin de coordonnées. La planète et la bouteille ont-elles le même format de coordonnées ? Le calcul de tous ces nombres doit épuiser beaucoup de ressources.
Je suppose que le système de coordonnées est basé sur des références, non ? Je veux dire que la planète a des coordonnées référencées au centre du système stellaire (0,0,0). Les coordonnées des bouteilles d'eau, des joueurs, des vaisseaux, etc. sont plutôt référencées au centre de la planète comme 0,0,0. Cela pourrait faciliter un peu les choses, mais... si le joueur regarde le ciel, il peut voir d'autres planètes et elles doivent être placées en vue en tenant compte d'autres coordonnées à la fois. C'est un énorme défi ! Je ne comprends pas comment vous avez réussi à faire ça !
Puis, dans un futur proche, de nouveaux systèmes d'étoiles vont apparaître. Comment fera-t-on pour ne pas mélanger les coordonnées ? Chacune commençant par 0,0,0 au centre de l'étoile principale et un code précédant ces coordonnées pour chaque système ?
Dernière question et plus importante. Y a-t-il une théorie ou des plans pour tirer profit de la technologie du Server Meshing pour améliorer la technologie 64 bits ? Je veux dire, au lieu d'une grille générale de coordonnées (nombres avec beaucoup de chiffres), en faisant plusieurs cadres de référence (pensez à des secteurs) d'espaces contraints pour rendre ces nombres plus petits. Je suis donc à un endroit précis. Mes coordonnées sont référencées à un point précis. Lorsque je me rends à un autre endroit, le programme passe à un autre point de référence de la même manière que nous passons d'un serveur à l'autre. C'est donc comme un "système de coordonnées dynamique". Des chiffres plus petits, qui pourraient être "convertis" en "système de coordonnées général" si nécessaire.
Désolé de ne pas avoir pu mieux m'expliquer, j'espère que vous comprenez l'idée. Je vous remercie.
La planète et la bouteille ont-elles le même format de coordonnées ?
Nos coordonnées sont mises en œuvre à l'aide d'un système de zones imbriquées dans lequel un hôte de zone peut être un corps céleste, un vaisseau, une voiture de transit ou une station spatiale.
Un hôte de zone est lui-même une entité et a donc des coordonnées dans la zone qui l'héberge, jusqu'à la zone racine qui est le seul hôte de zone qui se contient lui-même (et ne bouge jamais).
Au fur et à mesure que les entités se déplacent dans le jeu, elles entrent et sortent de différentes zones et leurs coordonnées se mettent à jour en conséquence. Si un hôte de zone se déplace, toutes les entités hébergées "se déplacent" par rapport à lui (bien que techniquement, elles ne se déplacent pas du tout car leur position est juste relative).
En réalité, vous pouvez imaginer une entité existant dans un arbre de zones hôtes dans le monde où sa position mondiale absolue est l'accumulation des transformations de chaque zone hôte au-dessus d'elle avec sa propre position ajoutée à la fin. Nous n'avons généralement pas accès à sa position mondiale dans le code car le jeu est généralement local et est donc le plus souvent traité dans un espace de zone unique.
Puis, dans un futur proche, de nouveaux systèmes d'étoiles apparaîtront. Comment faire pour ne pas mélanger les coordonnées ? Chacune commençant par 0,0,0 au centre de l'étoile principale et un code précédant ces coordonnées pour chaque système ?
Chaque système solaire utilisera toute la gamme des 64 bits, et nous utiliserons une zone unique pour chacun de ces systèmes solaires afin de différencier les coordonnées des différents systèmes.
Dernière question et plus importante. Y a-t-il une théorie ou des plans pour tirer profit de la technologie de maillage des serveurs pour améliorer la technologie 64 bits ?
Avec notre système de zones, ce n'est pas nécessaire.
-- Chad McKinney
