Cela semble devenir une forme de rituel, le Lundi matin, Chad McKinney semble accorder quelques heures de son temps pour répondre aux questions des backers, les sujets y sont des plus divers, et parfois, même une question sans importance peut devenir très intéressantes du fait de la réponse qui fut donnée.
J'ai donc fait un tri et rassemblé/classifié l'ensemble de ces questions & réponses sous la forme d'une blog-annonce Pause-Café que voici.
Expérience du kiosque d'achat
Commençons par une question toute simple sur l'avenir des kiosques de vente du PU, j'ai en grande partie supprimé la question pour n'en garder que le principal.
Je suis vraiment intéressé de savoir si des améliorations sont prévues pour la fonctionnalité des kiosques d'achat dans le PU ?
Il est prévu d'améliorer le kiosque de vente UI/UX, mais la question est plus de savoir quand exactement ces travaux seront programmés, que si. Étant donné que le travail de conception lui-même n'est pas terminé (et que nous essayons généralement de faire en sorte que les parties les plus détaillées d'une conception soient réalisées à proximité de la mise en oeuvre), je ne veux pas entrer dans les détails spécifiques de ce à quoi ces changements ressembleront exactement.
-- Chad McKinney
Des cadavres laissés un peu partout.
Avec les récentes révélations faites dans le Calling all Devs, cette question n'a rien de surprenant et comme on s'en doutait la persistance des corps ne sera pas infinie, mais la réponse est malgré tout intéressante du fait que la vitesse de retrait du corps dépendra en grande partie du lieu où il se trouve...
Ainsi, les cadavres ne disparaîtront pas, et on peut les découvrir. Y a-t-il une limite ?
Verrons-nous une mer de cadavres dans les bunkers ou autres points de mission ?
Quel impact cela aurait-il sur les serveurs ?
Étant clonés, nous savons où trouver nos affaires, mais nous n'avons aucune idée de qui nous a tués.
J'ai déjà mentionné ce point, mais nous avons déjà un système de nettoyage des entités qui vieillissent, et les cadavres ne seront pas différents. C'est un système qui va se développer à l'avenir pour faire face aux défis accrus introduits par la persistance globale et le maillage des serveurs, mais fondamentalement l'idée est que certaines entités ne dureront pas nécessairement éternellement dans tous les endroits en fonction du type de zone, donc par exemple vous vous attendez à ce qu'un cadavre reste simplement assis dans les rues d'une ville très fréquentée, à un moment donné quelqu'un va récupérer un objet qui a été nettoyé, mais d'un autre côté vous pouvez vous attendre à ce qu'un cadavre reste longtemps dans un endroit abandonné aléatoire avec un très faible trafic.
-- Chad McKinney
Inventaire des objets appartenant aux Joueurs
Un backer un peu pressé s'interroge sur le devenir de la gestion de notre inventaire dans sa globalité.
Pouvons-nous obtenir un bouton sur notre mobiglas qui affiche tous les objets que le joueur possède (navires, composants, armes de navire, objets d'armure, armes personnelles, médicaments, divers) comme un inventaire complet, à ce stade, le seul moment où nous voyons ce que nous avons est lorsque nous essayons d'équiper le type d'objet à un emplacement spécifique (taille) sur un navire ou l'avatar ; il serait bien d'avoir une liste de sorte à montrer tout dans le contexte des exemples de menu entre parenthèses ci-dessus ou similaire, peut-être même avec l'emplacement lorsque ICache est en cours, afin que le joueur puisse voir ce qui se trouve dans le hab ou la ferme ou sur un navire (armurerie).
Il y aura des améliorations dans l'inventaire et la gestion des joueurs, je ne veux pas encore entrer dans les détails car tout n'est pas encore finalisé, mais en plus de l'inventaire matérialisé, nous voulons aussi améliorer la façon dont vous visualisez et interagissez avec cet inventaire.
-- Chad McKinney
Emblèmes d'armure et insignes de grade ?
La question est plus longue que la réponse, mais j'ai trouvé la vision du joueur fort intéressante en soit et donc pensé qu'il était bon de la laisser en intégrale.
Je suis donc un vétéran militaire et l'écusson, le grade ou l'insigne est un élément important pour différencier un militaire d'un autre. Évidemment, dans le service, ceux-ci doivent souvent être gagnés par des épreuves difficiles. Du Ranger, du 75e Rgmt, des Marines Marsoc, des Navy Seals, des contrôleurs de combat de l'armée de l'air et des parachutistes, tous ont leurs symboles qui les différencient des autres. D'autres membres des forces armées non spécialisés ont également leur insigne. Bien que je réalise que la majorité des SC seront dans le PU, l'utilisation de grades, d'insignes et d'écussons ou d'autres symboles pourrait ajouter une réelle profondeur et une appartenance à vous, le joueur, en ce qui concerne votre organisation, votre caractère et votre armure.
Pour le mercenaire ou le chasseur de primes, ils pourront personnaliser leur armure avec ce que nous appelons dans le service des "écussons moraux" qui, en fait, ne font que donner un air cool et ajouter du style et de la personnalité à votre équipement. Je me rends compte que ce serait une véritable épreuve, et que cela demanderait un travail supplémentaire pour concevoir et dessiner la place des patchs, etc. sur l'armure, mais en fin de compte, cela insufflerait beaucoup de vie à l'univers, ajouterait de la profondeur, et pour les personnes les plus difficiles, ajouterait un peu d'humour.
Merci d'avoir pris en considération cette idée ! Si vous décidez de concevoir quelque chose dans ce sens, nous espérons que ce sera aussi amusant à concevoir et à créer que pour beaucoup d'entre nous qui peuvent porter leurs écussons avec fierté.
Nous travaillons sur le nouveau système de réputation qui nous permettra, au moins au niveau des données, de suivre diverses statistiques de réputation, y compris les rangs, par rapport aux entités et organisations. Nous chercherons à trouver différents moyens de communiquer ces niveaux de réputation et ces classements dans la tradition et dans les interactions avec le monde du jeu.
Je ne dis pas nécessairement que la personnalisation des armures sera incluse dans ce système (nous aurions d'abord besoin d'un système complet de personnalisation des armures qui n'existe pas) mais des choses de ce genre sont certainement envisagées.
-- Chad McKinney
Orbites planétaires, voyages quantiques et conteneurs d'objets...
Quand les backer veulent réinventer la poudre à la place des développeurs. Cette question est quelque peut confuse du fait qu'elle fait référence à une autre question posée le 19 octobre sur le même sujet.
Je sais que vous y travaillez déjà, mais j'espérais ouvrir le dialogue et voir si cette idée a déjà été explorée ou est peut-être en cours d'exploration :
Il est compréhensible qu'une dynamique orbitale réaliste ne soit tout simplement pas possible en raison des restrictions de vitesse dans un conteneur d'objet donné. Les navires ne sont pas "capables" des vitesses nécessaires pour atteindre une orbite réelle autour d'un planétoïde - à l'exception de Delamar qui est extrêmement petit mais qui a une gravité incroyablement élevée de 1G.
Beaucoup d'entre nous savent que, même si vous POUVEZ activer les orbites des planétoïdes (planètes autour de Stanton, lunes autour des planètes), cela crée une complication où la planète aura bougé au moment où votre voyage quantique vous y amènera. C'est tout à fait logique, vraiment.
De plus, d'après ce que je comprends, le positionnement est entièrement relatif au conteneur de l'objet dans lequel réside un véhicule, n'est-ce pas ?
Le voyage quantique est-il également basé sur le positionnement relatif du conteneur d'objet, ou bien faut-il toujours "s'accrocher" au calcul absolu du soleil/galaxie lors d'un voyage quantique ?
Parce que, voilà ce à quoi j'ai pensé :
Je pense qu'il serait raisonnable que le fait de sauter d'un planétoïde à un autre vous fasse atterrir "derrière", là où ce planétoïde "se trouvait" avant dans son orbite, si vous sautez de très loin.
Ce serait bien de devoir faire un autre saut correctif pour vous "rattraper" sur votre cible. On pourrait même l'agiter comme un "dispositif de sécurité" du voyage quantique pour s'assurer qu'on n'arrive pas à l'intérieur de la planète cible.
Une fois que vous êtes dans le conteneur de l'objet qui contient toute l'orbite de ce planétoïde, alors, votre vitesse initiale est synchronisée et couplée à la cible.
Pourrions-nous peut-être représenter les orbites entières d'un planétoïde donné comme un cylindre creux à paroi épaisse, aussi épais que 2x le rayon orbital du satellite le plus éloigné ? Ensuite, une fois que vous êtes DANS le conteneur de l'objet de l'orbite elle-même, votre élan est synchronisé à la cible et vous pouvez lui faire un QT directement.
Est-ce que cela a un sens ?
Bien sûr, cela suppose que les conteneurs d'objets peuvent même être autre chose qu'un solide primitif... en supposant qu'il puisse s'agir d'un "anneau" comme décrit. C'est compréhensible si le fait d'avoir un trou n'est pas nécessairement une chose que les conteneurs d'objets peuvent faire...
Il y a beaucoup à déballer ici, et vous trouverez peut-être mes réponses pas tout à fait satisfaisantes, mais j'ai pensé ajouter quelques commentaires (puisque c'est en partie une question de design)
Beaucoup d'entre nous savent que, bien que vous puissiez activer les orbites des planètes (planètes autour de Stanton, lunes autour des planètes), cela crée une complication où la planète aura bougé au moment où votre voyage quantique vous y amènera. C'est tout à fait logique, vraiment.
Pour être clair, la navigation que j'ai mentionnée concernant l'orbite n'est qu'une des nombreuses surfaces qui se forment lorsque les orbites sont activées, ce n'est donc pas le véritable bloqueur, c'est plutôt qu'il y a tellement de systèmes différents qui sont touchés que nous n'avons pas encore établi de priorités au point d'avoir un effort concerté entre les équipes pour traiter ces différents problèmes.
Je pense qu'il serait raisonnable que le fait de sauter d'un planétoïde à un autre vous fasse atterrir "derrière", là où ce planétoïde "était" avant dans son orbite, si vous sautez de très loin.
Pour l'instant, l'orientation de la conception est de toujours sauter à l'endroit où la planète se termine, et non pas à l'endroit où elle se trouvait avant le saut, afin d'éviter d'avoir à faire un quelconque saut secondaire de "réparation". Je pense que du point de vue du modèle de jeu, il peut être très frustrant de devoir faire un second saut chaque fois que l'on veut aller quelque part juste pour s'aligner davantage sur la cible, surtout quand on s'attend à ce qu'à l'avenir, on soit capable de tracer un chemin vers l'endroit où l'on devra se rendre pour se trouver à une distance raisonnable de la planète, en tenant compte du temps de trajet.
Bien sûr, cela suppose que les conteneurs d'objets peuvent même être autre chose qu'un solide primitif... en supposant qu'il puisse s'agir d'un "anneau" comme décrit. Il est compréhensible que le fait d'avoir un trou ne soit pas nécessairement une chose que les conteneurs d'objets peuvent faire...
Une chose à noter ici, c'est que les conteneurs d'objets ne bougent pas, en fait ils sont complètement statiques. Ils peuvent naître dans une zone qui bouge (comme une planète) et leur contenu enfants peut être mobile (comme certaines caisses), mais les conteneurs d'objets eux-mêmes sont fixes dans l'espace de la zone, bien qu'ils puissent se déplacer dans l'espace mondial si leur zone bouge.
-- Chad McKinney
Apprentissage Automatique/Profond, iCache & langage de développement
Une série de questions purement technique sur le Maching Learning, le Deep Learnig, l'iCache et le langage utilisé dans le développement de Star Citizen. Pour les plus curieux, retrouvez ci-dessous un lien vers les pages wiki FR du Deep Learning et du Machine Learning.
[wiki] Apprentissage automatique (Maching Learnig) »
[wiki] Apprentissage Profond (Deep Learnig) »
J'ai toujours voulu savoir si les développeurs utilisaient l'apprentissage automatique (Maching Learning) ou profond (Deep Learning) pour tous les techniciens de SC ?
Nous n'en utilisons aucun dans le jeu d'exécution pour le moment, bien qu'il y ait eu des discussions sur les différentes possibilités dans toutes sortes de domaines. Le problème avec l'apprentissage automatique est qu'il est intrinsèquement probabiliste. Vous devez donc considérer exactement ce que vous voulez obtenir de ces systèmes et la qualité de votre modèle dans une situation en temps réel. Dans la plupart des jeux, il est facile d'établir des heuristiques approximatives pour une IA, par exemple, et d'obtenir un comportement suffisamment bon pour convaincre le joueur de penser à un niveau supérieur (F.E.A.R. souvent cité ici comme exemple), mais obtenir un modèle qui se comporte ainsi serait un jeu de balle totalement différent. Je pense qu'il y a certainement un terrain intéressant à explorer ici, mais cela nécessiterait de la recherche et du développement.
En dehors du jeu lui-même, nous commençons à intégrer une certaine IA dans d'autres aspects de notre outil, comme l'analyse, ce qui ne devrait pas être entièrement surprenant pour quiconque suit le rythme dans ce domaine.
-- Chad McKinney
Dans quelle mesure CIG (ou GameDev en général) est-il à la pointe de la recherche ?
Je suis la chaîne youtube two minute papers
et je suis fasciné par les recherches qui y sont présentées, surtout parce qu'elles semblent être pertinentes pour le développement de jeux. Je suis maintenant curieux de savoir si les développeurs de CIG utilisent des sources similaires, quelles sont ces sources et si et à quelle vitesse les nouvelles recherches comme celle présentée dans la vidéo liée sont reprises et intégrées dans Star Citizens.
Il y a des tonnes d'autres exemples sur la chaîne, notamment en ce qui concerne l'apprentissage automatique (c'est-à-dire l'utilisation de celui-ci pour simuler des mouvements au lieu de l'animation et d'autres choses) et je me demande toujours s'il est réaliste que de telles choses fassent leur chemin dans le développement réel, ou s'il y a des retards et pour quelles raisons.
Simulating Dragons Under Cloth Sheets!
En fonction du domaine, nous suivons diverses évolutions intéressantes provenant de groupes de recherche plus formels. Je ne pense pas avoir déjà vu circuler ce papier sur le dragon(!), mais il y a souvent des discussions sur toutes sortes de choses, comme les nouveaux développements en robotique qui améliorent l'heuristique pour les calculs de secousses, ou encore le nouveau papier de SIGGRAPH qui parle des dommages et des déformations de la viande !
https://www.youtube.com/watch?v=eXJi7pkUZn0
Parfois, nous nous efforçons d'intégrer ces idées si elles sont simples, mais souvent, le contexte dans lequel ces documents sont rédigés est très éloigné des réalités d'un jeu en temps réel, donc c'est plutôt pour l'inspiration. Il faut aussi tenir compte du fait qu'un autre mot pour "bleeding edge" est "unproven" et que l'industrie du jeu a maintenant assez bien prouvé comment faire un jeu en 3D. Tout le monde s'efforce maintenant de voir où prendre des risques ou trouver de nouvelles améliorations, mais à bien des égards les moteurs ne sont pas si différents de l'époque de Quake et beaucoup de moteurs (y compris certains modernes) sont même des descendants directs de la base de code de Quake :
https://upload.wikimedia.org/wikipedia/commons/6/63/Quake_-_family_tree.svg
Ce sera un sujet très important, mais quels sont, selon vous, les principaux avantages qu'il reste à rendre le graphisme d'un jeu réaliste ?
Nous devons dépasser la méthode traditionnelle de projection/rasterisation, je pense que le raytracing et le SDF sont l'avenir.
-- Chad McKinney
ICache et serveurs de jeux dans la géolocalisation des jeux ?
Je pense qu'ICache aura une clé de géo-localisation (avec d'autres clés sans doute) pour permettre de trouver rapidement des objets dans une certaine zone physique du jeu. Est-ce exact, et si oui, prévoyez-vous de placer ICache et les VM des serveurs de jeu correspondants sur le même matériel/rack physique ? Est-ce qu'ils fonctionneraient même potentiellement dans la même VM ? Quelles clés prévoyez-vous d'utiliser ?
Nous utilisons quelque chose que nous appelons un StarHash qui est une sorte de geohash formaté spécifiquement pour nos systèmes solaires à l'échelle 64 bits.
https://en.wikipedia.org/wiki/Geohash
Ceux-ci permettront d'interroger spatialement un service appelé (vous l'avez deviné...) service StarHash, qui nous permet d'interroger rapidement des données dans certaines zones, le principal cas d'utilisation étant le streaming serveur. Une version de ce service fonctionne en arrière-plan depuis la mise en oeuvre initiale du streaming sur serveur, mais elle sera maintenant déplacée vers son propre ensemble de services afin que les noeuds du serveur puissent s'interroger mutuellement sur cet ensemble de données.
-- Chad McKinney
Quel langage de programmation a été utilisé pour créer SC ?
J'imagine que les choses ont quelque peu progressé depuis l'époque des CPU 8080 et des 64Kb RAM, lorsque les programmes d'échecs et de dames étaient écrits en langage assembleur puis codés en Basic ligne par ligne sous forme de déclarations peek et poke.
Une amie et moi avons fait un pari amical. Je dis C++, elle dit C#. Il est probable que nous ayons tous les deux torts. Il y a une bouteille de vin en jeu ici.
Le moteur du jeu est presque entièrement en C++ (avec un peu d'assemblage), et en fait nous avons supprimé le Lua de sorte que même le script du jeu n'est pas fait en Lua. Pour améliorer le temps d'itération, nous utilisons quelque chose appelé Recode qui nous permet d'échanger des modifications de code à l'exécution, ce qui est beaucoup plus rapide que de redémarrer le jeu dans son ensemble, tout en nous permettant de conserver les avantages de performance de l'écriture de code natif. Les concepteurs utilisent maintenant un langage de script visuel appelé "subsumption for AI behaviors and mission logic", mais il s'agit d'une très petite quantité de "code" qui est exécutée pendant le temps d'exécution.
Par ailleurs, nous utilisons C# et python pour l'outillage et C++, C#, Ooze et Typescript pour divers services d'arrière-plan.
-- Chad McKinney
Plus de personnel pour corriger les bugs ?
On termine avec une question sur la nécessité ou non d'augmenter les effectifs pour corriger les bugs. Si au premier abord cette question peut donner envie d'y coller un face-palm, il s'avère que la réponse donnée fut fort intéressante et peut concerner quelques candidats désirant postuler chez CIG. D'ailleurs, cela n'a pas trainé, un backer c'est empressé de demander ce qu'il en est des personnes se trouvant dans un pays éloigné, comme l'Australie.
Avez-vous l'intention d'embaucher plus de personnes pour aller corriger l'arriéré de bugs ?
Il semble y avoir un arriéré de bugs, des casses de jeu qui semblent être ignorés. Envisagez-vous d'embaucher d'autres personnes dédiées à la correction des bugs ? Ce serait bien si vous embauchiez plus de personnes qui se consacreraient à la correction des bugs tandis que les autres se concentreraient sur le développement.
La dernière fois que j'ai vérifié, nous avions environ 100 emplois ouverts, donc oui, nous cherchons à nous développer de manière significative. Cela dit, nous voulons maintenir nos normes et je peux au moins dire, au nom du département d'ingénierie, que même si nous essayons de nous développer, nous ne voulons pas que la qualité du code en souffre, il faudra donc du temps pour remplir ces fonctions.
Il faut aussi comprendre que même avec une main-d'oeuvre plus nombreuse, ils ne se concentreront pas uniquement sur la correction des bugs, car il peut être contre-productif de corriger des bugs dans des systèmes de jeu dont la conception est encore en cours de modification. En outre, nous avons de très grands projets techniques en cours, comme l'iCache, la persistance globale et le maillage des serveurs, qui sont encore en développement et qui auront un impact sur les systèmes actuels et en cours de développement. Pour l'instant, nous devons trouver un équilibre entre la correction des bugs et le développement des fonctionnalités. À mesure que nous nous approchons de la version bêta, nous pourrons alors nous concentrer sur la stabilisation et les performances.
-- Chad McKinney
Avec cela, je sais que vous avez des gens d'Europe et d'Amérique, mais êtes-vous prêts à avoir des programmeurs en Australie ? Les fuseaux horaires ne semblent pas être un problème de nos jours, mais nous sommes souvent oubliés ici.
La plupart du temps, nous recherchons des personnes qui peuvent travailler sur place, car GameDev est un projet incroyablement collaboratif. Il nous arrive de travailler à distance, mais c'est souvent temporaire en attendant que le nouvel employé puisse déménager. Comme nous prévoyons toujours de revenir dans les studios sur site, nous recherchons principalement des candidats qui sont prêts à travailler sur place dans l'un de nos sites.
-- Chad McKinney
