Jump to content
Maarkreidi

Intervention de Chris en personne sur Spectrum.

Recommended Posts

Dans  le post “ASK the Chairman........ Il est de retour !!” je parlais d’un échange entre un backer et Chris Roberts qui avait motivé le chairman à sortir de l’ombre. 
J’ai décidé de vous traduire leur échange car il est riche en enseignements divers. J’ai uniquement gardé les postes des deux protagonistes principaux, pas besoin du reste. De plus, le ton du Backer (@Camural) reflète bien l’esprit qui règne sur Spectrum depuis un certain temps. 

 

Voici le compte rendu de la discussion de ce 9 septembre :

 

@CAMURAL

Le système de salles atmosphériques - 4 ans plus tard

J'étais sûr que la CIG nous avait montré une vidéo sur le "room system" il y a longtemps et je l'ai trouvée :
Star Citizen : Around the Verse 3.13 - LA 10 novembre 2016

Je me demandais où nous en étions presque 4 ans plus tard, j'ai testé quelques trucs et j'ai fait une vidéo.



J'ai eu quelques commentaires : le Red a un bouclier aérien, enfin, seuls quelques vaisseaux ont un bouclier aérien, par exemple le Prowler. Les boucliers aériens ont aussi un effet visuel. Je ne suis pas au courant que la Cutlass Red a un bouclier aérien, mais cela n'a pas d'importance ;) : Je viens de faire la même chose avec un Aurora MR : quitté le siège du pilote, enlever le casque, ouvrir la porte : tout va parfaitement bien.
Je sors et j'entends le bruit  du "Je meurs - je n'ai pas d'oxygène", je rentre et je vais de nouveau bien.


Chris Roberts

Le Room System est dans le jeu depuis un certain temps et fonctionne pleinement, y compris l'égalisation des gaz / de l'atmosphère entre les volumes de la pièce (y compris la dissipation dans la pièce globale alias espace ouvert / le vide sidéral)

Lorsque vous suffoquez par manque d'oxygène, c'est parce que vous êtes dans une "pièce" où il n'y a pas assez d'oxygène.

Le Room System est en gros la façon dont le jeu décrit les volumes de gaz, leur pression, leur densité et leur température ; ainsi une planète a une pièce (c'est son atmosphère) ; un vaisseau a des pièces (divers compartiments entre les cloisons), même "The Coil" dans Squadron 42 a son volume décrit par une "pièce".

Nous l'utilisons pour le Player Status System (respirer de l'oxygène), pour le vol atmosphérique (le système des pièces contient toutes les informations en termes de densité et de composition de l'atmosphère en termes de gaz que le modèle de vol utilise pour calculer la traînée et la portance), la météo (certains des effets de sol actuels sont en partie influencés par la température de la pièce, la densité et même la composition des gaz dans l'atmosphère), les traînées de condensation (dans l'atmosphère et dans les nuages de gaz de l'espace) et les effets de l'entrée dans l'atmosphère sur les vaisseaux.

Le Room System est donc très important pour de nombreux systèmes et fait partie de Star Citizen depuis des années.

Ce que disait @MGibson-cig et qui a peut-être été perdu dans la traduction car vous ne connaissez pas nos termes internes, c'est que les salles peuvent avoir deux états : mutable et immuable. Mutable signifie que la pièce a une quantité finie de densité / pression / gaz qui peut passer à une autre pièce si elle y est connectée et qu'il y a une différence de pression. Ainsi, si vous ouvrez une porte vers l'espace à partir de votre Aurora, si la pièce interne est réglée pour être mutable, l'atmosphère à l'intérieur s'échappera à l'extérieur. Immuable signifie que la pièce contient ce qui est considéré comme une quantité infinie de gaz et que sa pression ne changera pas. Les atmosphères des planètes sont des pièces immuables, tout comme le vide de l'espace. Lorsque nous avons commencé à installer des pièces sur les véhicules, nous n'avions pas encore mis en place le système de survie, nous n'avions donc aucun moyen de fournir plus d'oxygène à une salle qui en avait perdu, et les concepteurs ont donc réglé les salles du vaisseau sur immuable (fourniture infinie d'oxygène en gros) comme mesure temporaire, car sinon, si vous ouvriez votre porte dans l'espace, vous perdriez votre atmosphère interne respirable et vous étoufferiez si vous n'avez pas de combinaison spatiale. Tous les vaisseaux ont des salles, et en fait, si les gens suffoquent parfois à bord d'un vaisseau à certains endroits, c'est parce que le volume de la pièce n'a pas été correctement réglé et qu'il y a une partie du vaisseau sans pièce, et sans pièce il n'y a pas d'atmosphère et le jeu traite tout ce qui se trouve à l'extérieur d'une salle comme du vide.

Nous avons la mise en place initiale des composants de survie et de leurs évents connectés qui fonctionnent en interne, mais le déploiement pour les vaisseaux prendra un certain temps car nous devons littéralement "plomber" les vaisseaux avec un ensemble de composants supplémentaires, pas seulement le composant de survie mais aussi tous ses évents. Nous avons quelques autres caractéristiques systémiques des vaisseaux, comme des cockpits plus interactifs (style DCS) sur lesquels nous avons travaillé, ainsi que le système d'incendie dynamique (qui utilise et affecte également la pièce/l'atmosphère) et une mise à jour du système de "tuyaux" qui partage les ressources comme l'électricité, la chaleur, le carburant, l'atmosphère entre les composants qui sera plus flexible et évolutif ; Comme tout le monde a toujours plus de travail que de temps, il sera plus efficace de mettre à jour plusieurs choses une fois que nous aurons ouvert un vaisseau pour le mettre à jour, d'où la nécessité de mettre en place certaines des fonctionnalités qui nous attendent dans les coulisses.

Il y a beaucoup de gameplay systémique très cool que nous avons travaillé pour terminer en arrière-plan pour les vaisseaux qui, une fois réunis, créeront une simulation de vaisseau spatial comme aucune autre. Laissez-moi vous donner un exemple qui tient compte de nos nouveaux dommages physiques (sur lesquels nous travaillons pendant que je rédige ; c'est une des choses dans lesquelles je suis assez impliqué), des incendies, des pièces, des tuyaux et des systèmes de statut des joueurs.

Une balle passe à travers le bouclier du vaisseau, qui absorbe une partie de son énergie cinétique, mais pas suffisamment car la vitesse de la balle était élevée, tout comme sa masse, car il s'agissait d'une balle qui perçait le blindage. Elle parvient à pénétrer le blindage et frappe un composant interne, disons un nœud de relais d’énergie (autre chose sur laquelle nous travaillons dans le cadre du remaniement du système de tuyauterie). Le nœud d’énergie est endommagé, ce qui lui donne une chance de "rater" lors de son utilisation. Quelques minutes plus tard, le nœud se déclenche, faisant sauter son fusible et s'enflammant. L'équipage du vaisseau ne se rend pas compte qu'un incendie s'est déclaré dans l'un des couloirs latéraux, car il est occupé à combattre les vaisseaux qui l'attaquent. Le feu commence à se propager le long des surfaces inflammables, et lorsque le feu commence à engloutir d'autres composants, ils s'enflamment également. L'ingénieur sur la passerelle du vaisseau voit sa console clignoter en rouge pour l'avertir que plusieurs composants sont défaillants et, en regardant le schéma de son navire, il voit qu'un incendie s'est déclaré sous les ponts. L'ingénieur décide de sceller les portes de cloisonnement du couloir pour contenir l'incendie, mais les portes n'ont pas de courant car le noeud d'alimentation est hors service ! Il demande à un de ses compagnons d'équipage de quitter sa tourelle et d'attraper un extincteur pour éteindre le feu qui se dirige lentement vers la salle de la génératrice. Le feu qui atteint la génératrice d'un vaisseau ou ses réserves de munitions sont deux moyens sûrs de faire exploser votre vaisseau. Avec le système de dommages physiques, les vaisseaux n'explosent plus seulement lorsque leurs points d'impact atteignent zéro, ils explosent parce que quelque chose à l'intérieur est devenu critique et a explosé (à cause des dommages ou de la chaleur), ce qui endommage alors tout le reste. En dehors de cela, les dommages affecteront la capacité de fonctionnement du vaisseau ou son intégrité structurelle, de sorte qu'ils pourraient aussi devenir une coque sans vie autant qu'ils pourraient disparaître dans un éclair de lumière. Lorsque le membre d'équipage arrive dans le couloir où le feu s'est déclaré, il a déjà consommé une énorme quantité d'oxygène dans cette "pièce" (le couloir) et a libéré des gaz nocifs, si bien qu'il ne peut plus respirer et se retire rapidement pour enfiler une combinaison et un casque résistant au feu. En désespoir de cause, l'ingénieur parvient à détourner l'énergie du nœud détruit par un nœud secondaire qui rétablit l'alimentation d'un nombre suffisant de portes de cloison pour lui permettre de contenir le feu. Remarquant qu'il y a un sas externe dans la zone scellée, il l'ouvre, évacuant l'oxygène des couloirs et des pièces scellées vers le vide de l'espace, privant le feu de la capacité de brûler, en éteignant la plus grande partie. À ce moment-là, le membre d'équipage est habillé convenablement et peut éteindre le feu qui a passé la porte de la cloison avant qu'il ne puisse se développer à nouveau. L'ingénieur referme alors le sas et permet au système de survie de reconstituer l'air dans la partie ventilée du vaisseau. Une fois cela fait, le mécanicien ouvre la porte de la cloison pour permettre au membre d'équipage d'entrer avec un fusible de remplacement pour le nœud d’énergie, ce qui rétablit le courant dans cette partie du vaisseau, puis retourne dans sa tourelle. Le combat a été serré, mais le vaisseau est toujours en vie et au combat !

Ce que je décris sera possible une fois que nous aurons terminé et déployé les systèmes sur lesquels nous travaillons. Je sais qu'il peut être frustrant d'attendre que toutes ces fonctionnalités soient en ligne, mais je vous promets que tout le monde travaille aussi dur et aussi intelligemment que possible pour y parvenir ; nous allons simplement viser un niveau de jeu systémique (par rapport à un scénario) plus élevé que la plupart des jeux, sinon tous, et concevoir tout cela de manière à ce qu'il fonctionne en multijoueur à cette 'échelle n'est pas une mince affaire.

Je m'investis beaucoup pour rendre le gameplay de Star Citizen aussi systémique que possible, car je pense que cela ouvrira de nombreuses possibilités de gameplay émergent et immersif. L'inconvénient de cette approche est qu'il faut plus de temps pour voir les résultats que pour écrire des scénarios, car il faut d'abord construire les systèmes fondamentaux et les faire interagir les uns avec les autres avant que l'étendue du gameplay ne devienne apparente. Mais à long terme, et pour que les gens puissent se plonger dans l'univers de Star Citizen pendant de nombreuses années à venir, c'est l'approche qui aura les meilleurs résultats.


Camural@Camural

Chris, c'est toujours le même vieux discours, je ne voulais même pas répondre, mais voilà :
-nous y travaillons
-nous savons à quel point c'est frustrant
-Nous avons déjà ceci dans le jeu, mais il manque la technologie X
-Chris continuant à décrire en détail comment le système est censé fonctionner un beau jour

Je ne veux même pas avoir autant de détails dans le modèle de dommages, je suis parfaitement d'accord avec un modèle de dommages/système de pièce qui semble bien à première vue.

En 8 ans, CIG n'a même pas réussi à atteindre cet objectif, il manque encore beaucoup de mécaniques de base et ce que nous avons est au mieux amateur.

Ce que toi, Chris, tu décris dans ton commentaire prendrait au moins 10 à 20 ans de plus.

C'est là que réside le problème, en ignorant les bases, en utilisant des substituts de mécanique amateur, en parlant de la façon dont le jeu sera Grand, mais vous ne pourrez jamais fournir autant de détails (ce dont nous n'avons pas besoin, rendez-les crédibles à première vue, fait) à moins d'avoir 4 fois plus de monde.

Je reviendrai certainement dans 1, 2, 3, 4, 5 ... ans et je suis sûr que nous entendrons les mêmes excuses.

 

Chris Roberts

Je ne le ferais pas normalement, mais je sais que vous avez investi beaucoup de temps dans Star Citizen, y compris sur les tests et la création de contenu communautaire, donc je vais prendre votre réponse comme un signe de frustration et essayer d'ajouter un peu plus de contexte pour vous aider à voir une image plus large.

Qu'espériez-vous obtenir de votre poste original ? Je supposais que c'était -

Citation

Je me demandais où nous en étions presque 4 ans plus tard, j'ai testé quelques trucs et j'ai fait une vidéo.

J'ai partagé des informations sur la situation dans laquelle nous nous trouvons, et pourquoi vous ne voyez pas quelque chose que vous pensez devoir voir. Une partie de ma motivation pour répondre est que je vois couramment des gens supposer des choses qui ne sont pas vraies comme le système de salle n'étant pas dans le jeu parce qu'un aspect du système n'a pas le comportement qu'ils pensent qu'il devrait avoir. Je voulais vous donner un contexte et des informations supplémentaires afin que vous (et les autres participants à ce fil de discussion) compreniez mieux ce qui est dans le jeu, ce qui ne l'est pas et pourquoi, et ce qu'il reste à faire.

Si vous voulez m'encourager ou encourager d'autres développeurs à répondre aux questions, il est préférable de ne pas remettre en question le professionnalisme des gens ou de faire des déclarations générales. Si quelqu'un vous faisait cela dans votre travail, je suis sûr que ce serait irritant. J'ai la peau plus épaisse que la plupart des développeurs de CIG, et je me rends compte que tout le monde ne parle pas dans sa langue maternelle ou ne se rend pas compte que la façon dont ils ont formulé les choses n'était peut-être pas la meilleure, mais en général il vaut mieux aborder les choses avec une critique constructive, en laissant de côté les ad hominems. Vous n'investiriez pas autant de temps dans quelque chose si vous ne vous en souciiez pas, alors pourquoi consacrer de l'énergie à poster quelque chose qu'un développeur rejettera parce que cela ressemble à une attaque ? Je peux vous dire que le fait d'être prévenant envers quelqu'un et de le traiter avec respect vous permettra d'aller beaucoup plus loin que le simple fait d'être méprisant. L'équipe de développement lit ces forums et d'autres endroits comme reddit, et les commentaires de la communauté sont très utiles, mais les commentaires qui font l'objet d'une action, qui sont transmis en interne et qui sont discutés sont du type constructif, et non du type trop négatif. Le simple fait de dire que quelque chose craint n'aide pas. Il est utile que l'utilisateur explique pourquoi ça craint pour lui et qu'il ait des idées pour éventuellement rectifier la situation.

Ma plus grande déception avec le discours moderne sur Internet est qu'il y a une grande part de cynisme, surtout dans les forums ou les débats sur Reddit, et qu'une partie des gens pensent le pire. Si une fonctionnalité est manquante, en retard ou buggée, c'est parce que la société ou le développeur a menti et/ou est incompétent, par opposition au fait qu'elle a juste pris plus de temps et a eu plus de problèmes que l'équipe ne l'avait imaginé lorsqu'elle a commencé à la construire. De par leur nature même, les développeurs sont optimistes. Il faut l'être pour construire des choses qui n'ont jamais été construites auparavant. Sinon, le simple poids de ce qui doit être fait peut vous écraser. Mais être optimiste ou ne pas prévoir les problèmes n'est pas la même chose que de mentir ou d'induire délibérément les gens en erreur. Tout le monde à CIG est incroyablement passionné par l'idée de faire de Star Citizen le bac à sable de l'univers le plus immersif, massivement multijoueur à la première personne, et tout le monde travaille très dur pour y parvenir. Si nous pouvions faire mieux, plus vite, plus efficacement, nous le ferions. Nous sommes tout aussi frustrés par le temps que cela prend. Nous pratiquons l'estimation ascendante des tâches lorsque l'équipe qui met en œuvre la fonctionnalité la décompose et donne son estimation du temps qu'il lui faudra. La direction ne dicte pas de délais, nous fixons simplement des priorités pour les équipes car il y a toujours beaucoup plus de choses à faire à un moment donné que nous n'avons de personnes pour les faire. Nous revoyons et essayons constamment d'améliorer notre processus de développement AGILE et la façon dont nous estimons les sprints. Au fur et à mesure que le code, les fonctionnalités et le contenu s'enrichissent, la maintenance et le support des fonctionnalités et du contenu existants augmentent, ce qui peut réduire le temps dont dispose une équipe pour le développement de nouvelles fonctionnalités, ce qui signifie que vous avez toujours la même qualité de vie dans une version que lorsque vous fournissez de nouvelles fonctionnalités et du contenu. Parmi la communauté, il y a la même volonté de faire évoluer le jeu sans bogues, mais aussi de proposer de nouvelles fonctionnalités et de nouveaux contenus, souvent proposé par les mêmes personnes.

Des choses comme le Salvage n'ont pas été repoussées sur un coup de tête, mais parce qu'en termes de priorité, nous avons estimé qu'il serait prématuré de travailler sur le Salvage avant que le système iCache et les dommages physiques ne soient mis en œuvre dans le jeu, car cela change fondamentalement notre façon de gérer l'état, de gérer les dommages et les débris. C'est pourquoi, lorsqu'il nous a été demandé d'accorder la priorité à l'allocation des ressources, nous avons défavorisé le Salvage afin de construire l'infrastructure pour qu'elle soit vraiment performante, au lieu de travailler sur un système que nous devrions remanier lorsque l'iCache et le nouveau système de gestion des dommages seront mis en place.

Nous avons également décidé d'investir plus de temps dans la qualité de vie, les performances et la stabilité de Star Citizen, car il est joué activement chaque jour par des dizaines de milliers de personnes ; les jours normaux, nous avons en moyenne plus de 30 000 personnes différentes qui jouent et au plus fort des événements cette année, nous avons atteint 100 000 comptes uniques jouant en une journée, ce qui est assez impressionnant pour un jeu dans un état Alpha précoce. Nous sommes en bonne voie pour atteindre plus d'un million de joueurs uniques cette année. Star Citizen possède déjà les principaux gameloops d'une simulation spatiale : transport de cargaisons, commerce de marchandises, mercenaires, pirates, chasse aux primes et exploitation minière. Le simple fait de passer du temps à les peaufiner et à les terminer rendrait Star Citizen, avec tous ses détails et sa fidélité, plus captivant que n'importe quelle simulation spatiale "finie" à laquelle vous pouvez jouer aujourd'hui.

Nous avons montré un aperçu du nouveau format de la feuille de route ( https://robertsspaceindustries.com/comm-link/transmission/17727-Star-Citizen-Squadron-42-Roadmap-Update ) sur lequel nous travaillons. Une partie de la motivation pour changer la façon dont nous partageons les tâches sur lesquelles nous travaillons et leur progression est que la communauté peut obtenir une meilleure visibilité des choix difficiles auxquels nous sommes confrontés chaque jour sur le projet et voir sur quoi chaque équipe travaille exactement, par opposition aux quelques tâches que nous nous sentons à l'aise de partager parce que nous pensons avoir une forte probabilité de les réaliser ce trimestre. Lorsque nous faisons un examen des priorités et que nous avançons ou ajoutons une tâche, il y a toujours quelque chose qui doit être repoussé. Le nouveau format qui suit nos 58 équipes de fonctionnalités et de contenu qui travaillent sur Star Citizen et Squadron 42, pourra montrer sur quoi chaque équipe travaille et si une nouvelle initiative comme l'amélioration de l'expérience de transport de fret est ajoutée, vous verrez les tâches qui sont repoussées sur les équipes qui travailleront sur cette nouvelle initiative. A titre indicatif, ces équipes peuvent être composées de 4 à 20 personnes et sur les 58 équipes, seules 11 sont exclusivement dédiées à Squadron 42 et 12 à Star Citizen, le reste étant partagé (graphiques, moteur, acteur, véhicule, IA, VFX, son, etc.), bien que les priorités en matière d'acteur, de véhicule et d'IA dépendent en grande partie des besoins de Squadron.

Le changement de format de la feuille de route était une priorité pour nous au début de l'année, lorsqu'il était clair que le format actuel de la feuille de route n'aidait pas, d'autant plus que les équipes ne voulaient vraiment pas s'engager avant d'être absolument sûres que leur fonctionnalité allait aboutir, ce que vous ne savez normalement que six semaines avant la sortie, en raison du vitriol qu'elles voyaient lorsqu'une tâche était repoussée, malgré nos meilleurs efforts pour que tous ceux qui regardent la feuille de route actuelle lisent et reconnaissent les avertissements ( https://robertsspaceindustries.com/roadmap/board/1-Star-Citizen/info ) qui disent explicitement que certaines des tâches risquent de glisser. Lassé de tout cela, j'ai pensé qu'il serait préférable pour la communauté de voir le même point de vue que moi et le reste de la direction du développement de Star Citizen et Squadron 42. Cela n'empêchera pas les gens d'être en désaccord avec nos priorités ou avec le temps que prend une tâche, mais au moins cela permettra de partager l'image globale et les gens pourront voir exactement sur quoi chacun travaille à tout moment et combien de temps cela devrait prendre. Ils pourront voir les choses changer quand elles le feront pour nous et, espérons-le, apprécier le nombre de personnes qui travaillent vraiment dur pour faire de Star Citizen un jeu comme aucun autre. L'une des raisons pour lesquelles la nouvelle feuille de route prend du temps est que nous construisons un système qui visualise tout cela comme un niveau supérieur directement à partir de notre base de données JIRA. Nous prévoyons d'utiliser une version plus verbeuse de la feuille de route publique pour notre programmation interne des sprints, de sorte que les données que vous verrez seront une version aseptisée de ce que nous voyons (nous ne partagerons pas publiquement les noms et les affectations des développeurs individuels pour des raisons évidentes, mais en interne, nous verrons cela).

J'ai l'impression, d'après votre réponse, que c'est le temps pris et les priorités qui vous frustrent, car vous avez l'impression que nous nous concentrons sur les mauvaises choses. Je comprends ce point de vue, mais vous regardez les choses de l'extérieur sans savoir exactement ce qu'il faudra faire et dans quel ordre pour obtenir le gameplay qui placera Star Citizen au-dessus de tout le reste. C'est le jeu dont j'ai rêvé toute ma vie. Maintenant que je suis en mesure de le réaliser, je ne suis pas prêt à compromettre son potentiel parce qu'il prend plus de temps que je ne l'avais imaginé au départ. Ce à quoi je vais m'engager, et ce qui est une priorité interne, c'est d'améliorer le gameplay actuel et la qualité de vie au fur et à mesure, car Star Citizen est déjà amusant à bien des égards, même s'il est plus bogué et moins stable que je ne le voudrais, et le simple fait de finir et de peaufiner les bases le rendra aussi ou mieux jouable que la plupart des autres jeux.

Je peux vous promettre que le gameplay que j'ai décrit n'est pas une chimère, et qu'il ne faudra pas 10 à 20 ans pour le réaliser. J'ai décrit des systèmes qui fonctionnent ou sur lesquels nous travaillons ; nous avons même montré les premières versions de certains d'entre eux, comme le feu dans Inside Star Citizen. Je ne peux pas vous promettre exactement à quel trimestre cela se fera, mais une fois que le travail sur le web de la nouvelle feuille de route sera terminé, vous pourrez voir les équipes progresser vers la réalisation de ce que je décris en temps réel.

Je vous remercie pour votre soutien et votre passion au fil des ans. J'espère que ce regard supplémentaire vous a été utile


 

Je ne sais pas vous mais moi cette intervention de Chris Roberts m'a fait énormément plaisir car il recentre le débat et répète encore une fois ses intentions quand à l'avenir du jeu. Intentions qui n'ont pas changé depuis le départ mais il fallait le souligner pour les nouveaux arrivés entre temps.

 

Source : https://robertsspaceindustries.com/spectrum/community/SC/forum/3/thread/atmospheric-room-system-4-years-later

Trad : @Maarkreidi SwissStarships.org

 

zbwfBnp.gif

"... there are a lot of Freelancer fans out there that love that, that mouse control where guns target for you but noit’s going to be Wing Commander"

source: http://tinyurl.com/q46br4w

Link to post
Share on other sites

Quelle patience, mais je te l'aurais envoyé c.....

Pour moi on pourra commencer à râler dans deux ans si on a toujours rien dans les mains.

Dans deux ans ça fera 10 ans de développement pour un AAA qui part de rien, c'est une durée tout à fait normale.

Rk2ZR95.gif

Link to post
Share on other sites

×
×
  • Créer...