[ouliane]

>>>>>>>>>> ndt : Unveiled #33 original en anglais ICI. <<<<<<<<<<<<<

Dose of Design -par Ben Pielstick

Implementation Audiovisuelle

Dans la précédente Newsletter, J'ai parlé des considérations relatives à l'apparence générale et aux sensations en combat. À ce stade du développement, nous commençons réellement à raccorder les éléments audio et visuels aux compétences, une tâche qui nécessite une attention particulière en raison de la manière unique dont fonctionne notre système de compétence.

Dans un jeu qui aurait des compétences prédéterminées, nous assignerions simplement un ensemble spécifique d'animations, d'effets visuels et de sons à chaque compétence particulière, à jouer chaque fois qu'un joueur l'active. Dans Camelot Unchained, cependant, elles sont construites par les joueurs à partir d'une liste de composants disponibles. Chaque élément audiovisuel doit être différent en fonction de la combinaison de composants, une fois réunie, lorsqu'un joueur construit sa compétence. Par conséquent, aucun composant ne peut contenir une définition complète pour les animations, les effets visuels et les sons à jouer au cours d'une compétence dans laquelle il est utilisé. Au lieu de cela, nous devons diffuser l'information entre les composants. Lorsqu’ils sont combinés, leurs informations globales doivent préciser les animations, les effets visuels et les sons à rechercher. Nous devons le faire pour chaque ensemble de composants qui peuvent être combinés pour construire une compétence valide. C'est beaucoup !

La façon dont nous nous y prenons, est l'utilisation de balises. Nous définissons un ensemble de balises pour chaque composant; Ces balises peuvent être regroupées lorsqu'une compétence est créée à partir de plusieurs composants. Lorsque nous ajoutons toutes les balises de chacun des composants dans une compétence, nous pouvons utiliser la liste combinée des balises pour rechercher les animations, les effets visuels et les sons dont ces compétences particulières ont besoin.

Chacun de ces éléments est légèrement différent ! Par exemple, les balises pour les particules peuvent nécessiter de préciser quelles articulations du squelette du personnage dont elles doivent être jouées, alors que les sons ne le font pas. Cela signifie que les balises sont définies séparément pour chaque élément audiovisuel, ainsi que les données supplémentaires nécessaires pour répondre aux besoins de chaque type de données.

Cela finit par être beaucoup de données ajoutées à chaque composant de compétence. En définitif, ceci est nécessaire compte tenu de la complexité du système de compétence que nous créons. Une fois que le reste du code requis sera en place, il permettra à chaque système de lire ses balises définies à partir d'une combinaison unique de composants, que les joueurs ont choisi pour construire leurs compétences et sélectionner les éléments audiovisuels appropriés à jouer. Par exemple : si un guérisseur a un composant “Rune” pour un soin de vie, et un autre pour cicatriser les “Wounds” (blessures) et un composant “Shape”(forme) pour un projectile à distance, et un autre pour une zone d’effet en cône, alors un projectile de cicatrisation et un projectile de soin seront visuellement et avoir une sonorité différents, et un projectile de soin et un effet en cône de soin seront tout aussi différents.

À l'avenir, cela nous permettra également d'utiliser cette information pour déterminer ce qui se passe lorsque les compétences interagissent entre elles sous notre système AIR. Quand un effet de feu et un effet d'eau entrent en collision dans le jeu, nous prendrons les balises présentes sur chaque effet et utiliserons la liste combinée de celles-ci pour rechercher ce qu'il faut exécuter (dans ce cas-là, vapeur, etc.), comme si nous construisions une nouvelle compétence.

Le système AIR n'est pas prévu pour le début du test Beta 1. Cependant, au moment où il sera prêt, le système de marquage, auquel il s'appuie, aura déjà pas mal avancé dans conception. Après tout, comme je viens de l’expliquer, ces balises sont ce à quoi tout le système de compétence dépend du moment où nous jouons un son, affichons une particule ou faisons en sorte que le personnage effectue une animation dans le cadre de l'activation d'une compétence.

La définition de ces balises et la construction des systèmes qui les utilisent ne constituent qu'une petite partie du développement continu de Camelot Unchained. L'attribution d'ensembles de balises peut ne pas sembler être une partie du “game design”, comme la création de nouvelles classes ou l'équilibrage des armes et des armures, mais la construction d'un jeu implique beaucoup de travail dans les coulisses comme celui-ci, qui est essentiel pour faire fonctionner le jeu, même si Il n'est pas visible lorsque vous y jouez.

J'espère que cela vous a permis de mieux comprendre certaines des fonctionnalités les moins évidentes, qui entrent dans la création d'un jeu comme Camelot Unchained, en utilisant un moteur de jeu personnalisé, qui ne comporte aucune de ces pièces déjà pré-construites et prêtes à l'emploi. Nous sommes impatients de vous montrer les résultats de bien plus de ces fonctionnalités à venir, alors que nous continuons à travailler vers le début des test de Beta 1.

------------------------------------------------------------------------------------------

State Of The Build -par Brittany Aubert

Il y a un vieux dicton sur les averses d'avril et les fleurs de mai. Eh bien, il n’a pas plu qu’un peu ici à Seattle, et donc je ne serais pas surprise si tout un jardin botanique pousserait au tournant du mois. Et il est toujours étrange d'entendre que c'est totalement différent de nos collègues de Fairfax, qui vivent les quatre saisons en une seule semaine.

Mais malgré ce temps humide, nous sommes à l'intérieur, à produire du code, coincé à regarder les gouttes de pluie contre les vitres. Il a eu de nombreuses semaines productives pour les programmeurs à CSE, et notre attention au travail c’est tourné vers la mise en fonction des systèmes que nous avons mis en place, tout en gardant les yeux tournés vers Beta 1.

Et avec cela, passons au “State of the Build” de ce mois-ci et abordons certains des éléments les plus importants qui se sont réunis au cours du mois écoulé. Vous remarquerez ici un style légèrement différent - comme nous l'avons fait avec nos User Stories, nous proposons une version plus concise et condensée de nos progrès, qui est, nous l’espérons, beaucoup plus lisible et empêchera la newsletter de s’envoler jusqu'à 25 pages. Espérons que vous apprécierez

Fledgling : Le mois dernier, j'ai écrit un post-mortem pour dévoiler notre nouveau processus de test. Une amélioration que nous avons décidé pour créer un autre serveur dans notre pipeline. Fledgling existent désormais entre Hatchling et Wyrmling / Wyrmling Prep. Nous conservons généralement des “checkpoints” plus stables sur Wyrmling, habituellement un build qui a introduit une modification majeure ou une mise à jour. Mais à mesure que le développement s'est accéléré, nous avons dû proposer une solution qui nous permettrait de tester un code plus récent, sans verrouiller Hatchery et empêcher l'équipe de soumettre son travail.

Animation : Pour quelque chose qui a été présenté dans d'innombrables jeux vidéo depuis la fin des années 80, il est encore incroyable de voir combien de travail il faut exécuter pour faire sauter quelque chose. Il existe de nombreuses animations différentes, qui entrent dans un cycle de saut unique (prép, sauter, atterrir, et parfois plus), en prenant en compte la physique, à la fois la gravité et la collision, et aucun de ces éléments n'inclut l'aspect «ressenti». Le saut est-il réactif ? Cela dure-t-il assez longtemps ? Se ressent-il un peu trop flottant ? Que se passe-t-il si le joueur appuie sur le bouton plus longtemps ? Et toutes ces questions ne répondent pas uniquement avec plus de code. C'est la beauté du développement de jeux - un groupe de personnes vraiment futés (dans ce cas, Scott, Andrew et Rob) travaillant ensemble pour que quelque chose se ressente bien.

Ciblage manuel et Armes de siège : Matt avait travaillé sur le ciblage manuel depuis quelques semaines et a récemment progressé vers les armes de siège, alors que nous avons recueilli des retours sur différents modes de visée. Cet ordre était dû à une question de dépendance - le ciblage manuel devait être opérationnel avant même le fonctionnement des armes de siège. Mais cette visé doit-elle être dans un état définitif ? Pas exactement. Il reste encore beaucoup de logistiques de conception qui doit être discutée en ce qui concerne le ciblage manuel, mais il est assez fonctionnel pour avancer dans la tâche suivante. C'est une de ces choses de production “nerdy” que j'apprécie vraiment : prendre différentes pièces de puzzle et les imbriquer sur l’ensemble plus grand.

Transitions invisibles entre zones : Notre technologie multi-serveurs permet aux joueurs de passer d'un serveur à l'autre, mais il existe actuellement un écran de chargement pendant ce processus. En voyant que cela casse un peu la magie, nous avons travaillé pour les supprimer et y faire des transitions, vous l'avez deviné, invisible. Nous avons terminé les premières étapes de ce travail localement, en évitant la suppression des entités, qui sont transférées entre les serveurs, puis en supprimant l'écran de chargement lui-même. Nous continuons à déployer une étape après l'autre à mesure que nous atteignerons la fonctionnalité souhaitée, qui consiste actuellement à placer manuellement les déclencheurs sur lesquels les joueurs vont interagir et déclencher une transition, et en supprimant le délai lors de la réapparition du joueur dans le monde.

Rendu des particules : Ce qui a commencé comme une revue sur certaines optimisations des shaders pour permettre les batailles à grande échelle, s'est transformé en une mise à niveau complète du rendu, et maintenant nous voyons les fruits de ce travail. En outre, nous avons de nouveaux shaders permettant aux particules d'être éclairées par le monde, de recevoir des ombres et d'utiliser des “normal maps”. Le gain le plus important a été sur notre amélioration de la manipulation de la transparence, ce qui est clairement essentiel pour l’apparence des particules, et une poignée d'optimisations sur les shaders. Résumés dans un seul paragraphe, cela ne rend pas justice au travail que George, Dave, Bull et Mike ont effectué pour rendre cela possible. Ce fût une sacré aventure ! Mais c'était un grand pas en avant pour que notre jeu devienne magnifique visuellement, et Mike pourra le rendre plus époustouflant en utilisant ses nouveaux joujoux.

Énormément de récupération de données : C'est probablement la chose la moins sexy de cette liste. Mais c'est l'une des plus importantes. Parfois, les bugs peuvent être difficiles à repérer, et quand on a un jeu en fonctionnement, il est crucial de réagir rapidement en cas de problème. Colin a ajouté un traqueur supplémentaire à notre base de données, au lieu du système de fichiers, afin de mieux remédier à certains problèmes de stabilité sournois avec nos proxies. Le travail récent de Marc simplifie la façon dont nous étiquetons les messages de retour, ce qui nous permet de rechercher rapidement dans une pile de texte pour des informations critiques.

Nettoyage interne : C'est dans l’ordre naturel du développement d’un jeu que, pour chaque nouvelle fonction qui a été réalisée, des travaux nouveaux et inconnus se manifestent et doivent être résolus. Nous sommes à un point critique dans le développement où nous commençons chaque tâche en nous posant la question : "Est-ce vraiment nécessaire pour la Beta 1 ?" Très souvent, ces tâches surprenantes ne sont pas liées à un “User Story” spécifique, mais plutôt sur Les économies que nous allons faire grâce soit à l'efficacité ou la diminution du nombre de bugs à l'avenir. Cela affecte indirectement chaque User Story.

• En réarrangeant l'ordre de certaines tâches du serveur, nous avons évité un problème particulier où les joueurs pouvaient être chargés dans une zone avant que les compétences ou les bâtiments n'aient été chargés, ce qui a mettait le jeu dans un très mauvais état.
  

• JB a eu l'idée de transférer notre chargement des compétences du système de fichiers vers la base de données. Cela expose beaucoup d'informations à l'interface utilisateur, qui n'étaient pas facilement accessibles avant, rendant nos UI existantes plus réactif, sans écrire un tas de code qui pourrait être rejeté, lorsque notre nouveau style d’UI sera finalisé.
  

• Tout en réalisant les étapes pour créer Fledgling, Tim a appris et standardisé le processus d'implantation d'un nouveau serveur de développement. Il va sans dire que Fledgling ne sera pas le dernier serveur que nous créerons pendant le développement, de sorte que ce processus soit la clé de plus de simplicité et moins propice aux erreurs. Nous préférerions que la difficulté ne soit que de proposer de nouveaux noms de serveurs drôles, qui correspondent à notre schéma de dénomination existant.
  

[ouliane]

Artitup -par toute l’équipe artistique, images par Scott Trolan

Puisque Tyler a demandé à Scott de se concentrer sur les animations ce mois-ci, le reste de l'Équipe Artistique s’est attelé à aider dans la rédaction de cette partie ! D’où le format un peu spécial de cet article. Chaque artiste a rédigé sa propre courte description, sur quoi il ou elle travaillait durant le mois passé, pour vos beaux yeux. Nous présentons un Art It Up de groupe de la part de toute l’équipe artistique !

Sandra : J’ai passé ce mois à travailler sur une deuxième itération de presque toutes les animations, qui sont nécessaire en ce moment au maniement de la Hallebarde. J’appelle ceci “Hallebarde 2.0”. Avec ce nouveau système d’animation en place, et les améliorations que Scott et Andrew ont découvert, je peux m’enflammer dans les mouvements, sans aucunes restrictions. Partant de notre rapide version, des animations indépendantes du bas et haut du corps, aux animation de combat du corps en entier, est vraiment un grand pas pour nous, animateurs. Juste ce seul changement nous permet de faire des animation plus fluides et bien meilleures.



En même temps que les nouvelles animations nécessaires pour le nouveau système d’animation, Scott et moi avons corrigé, poli, et ré-ajusté certains des vieux clips d’animation, qui étaient très grossiers, pour pouvoir lancer les tests. Une fois que nous avons eu les transitions entre posture, fonctionnant avec différentes armes, nous avons réalisé qu’il nous manquait le mouvement d’attente sans arme en mode combat. De ce fait, j’en ai réalisé un pour vous permettre de rester sur place désarmé, mais toujours sur la défensive. Même si tout monde adorait la pose penché en “T” bouche-trou, nous savions qu’il fallait la remplacer. xD Plus tard, nous travaillerons sur quelques animations de coups de poing aux mains nues, juste au cas où vous vous trouveriez désarmés, ou non-préparés pour un combat impromptu.

Michelle : Au début du mois, j’ai esquissé différentes variations par royaume d’un scorpion, une arme de siège. Heureusement tout se passa rapidement, même le processus d’acceptation finale. La partie la plus difficile a été de comprendre comment les mécanismes fonctionnaient, comme cela Jon aurait assez d’informations visuelles pour faire la version “in-game”. Jon est déjà en train de modeler le troisième de ces scorpions cette semaine, travaillant avec moi, non seulement sur le visuel, mais aussi sur le comment devrait fonctionner les mécanismes. Quand nous aurons le temps, et les possibilités d’animation du côté technique, nous ferons des animations plus mécaniquement cohérent. Si vous jetez un oeil à notre chaîne, vous pouvez retrouver nos streams, si vous voulez voir ce processus créatif en action.



Il est honnête de préciser que je n’ai aucune expérience sur la conception d’UI, ce qui fait que ce mois a été rude. Ce que je pensais être une promenade de santé, s’est transformé en chemin de croix, lorsque j’ai réalisé que c’était horriblement compliqué ! Grâce aux supers retours de l’équipe, je fais de bons progrès sur ces éléments d’UI et les designs de plein-écran, bien que certaines choses, comme les affichages des états de santé, prennent un peu plus de temps que prévu. Il y a plusieurs aspects que nous voulons communiquer, côté gameplay, et ça commence à être comme surveiller un véritable tableau de bord ! Donc, concevoir tout cela est très intéressant, mais est un vrai challenge à garder une cohérence à tous ces indicateurs, tout en gardant un visuel agréable.

Bien que l’UI était ma priorité, j’ai aussi travaillé avec Dionne sur les guides des variations par royaume pour les différents biomes. Ceux-ci furent de rapides coloriages pour donner une idée générale à creuser. Mon but principal est de garder une certaine consistance entre les biomes de chaque royaume. Je donne les directives, et c’est finalement aux artistes 3D de tout rassembler, et de venir me voir s'ils ont besoin de plus de direction.

Jon : Ce mois, j’ai modelé les armes de siège de type scorpion Arthurien, Viking et TDD (basse, haute résolution et textures). N’ayant jamais vu personnellement une de ces machines de guerre, comprendre leurs mécanismes a été un véritable défi pour moi ! En m’appuyant sur des croquis, images, vidéos et avec l’aide de quelques supers Backers, j’ai pu finalement mieux comprendre le fonctionnement de ces engins, me permettant d’aboutir à des modèles satisfaisants.



Maintenant que nous avons résolu le problème de comment lier les armes aux personnages, nous voulions voir le retour de nos capes. Le modèle initial était juste un quelque chose de rapidement fait, donc j’ai réalisé un ensemble de textures générique de cape, ainsi que des variations très spécifiques aux royaumes pour les différencier. Ces capes ont un peu plus de “mouvement” apparent que les premières versions. Les prochains tests autour de l’animation et des armes nous donnerons une meilleure idée sur leurs prochaines modifications.

De plus, après de bons retours sur la revue des tailles des armes, j’ai redimensionné et changé toutes les armes qui avaient besoin d’être ré-ajustées. Notre objectif principal n’est pas seulement de garder un aspect quelque peu réaliste, mais aussi de permettre leur identification de loin. Même si ce n’est pas définitif, nous pensons que nous sommes juste comme il faut.

Dionne : Pour ce mois, je me suis concentrée sur la création des variations par royaume pour différents actifs d’environnement, dont nous avions précédemment réalisé les versions neutres. En plus, j’ai créé plusieurs cerisiers saules japonais en fleurs, accompagnés de leurs ensembles de textures pour le sol. Lorsque nous créons de nouveaux actifs, nous gardons à l’esprit que nos actifs doivent être des “kits réutilisables” pour en faire de nouveaux. Dans ce cas, je peux prendre certaines des géos des arbres saules et les transformer en arbres effrayants des marais plus tard. L’objectif global ici est de s’assurer que vous ne voyez pas l’exact même configuration d’environnement trop longtemps, lorsque vous vous baladez à travers les grandes cartes. A cause de la grandeure du monde, et de la taille de notre équipe, nous devons travailler dur ET intelligemment.



Alors que nous continuons à créer des nouveaux actifs, nous serons capables de remanipuler des zones préexistantes, pour y rajouter plus de variations par la suite. Par exemple, l’actuelle forêt de pins suffit pour l’instant, mais nous avons déjà plusieurs autres pins en production. Comme l’éditeur d’environnement est génial, tout ceci peut être ajouter bien plus tard, quand les nouveaux actifs seront prêts. La prochaine étape de ce travail sera de transposer le tout en “modes”, et peaufiner les détails pour se soit… parfait !

Mike C : J’ai passé la plupart de mon temps à tester tous les nouveaux changements du système de particule récemment installés. Bull a apporté plus améliorations majeures sur la façon dont fonctionne l’éditeur. Je peux maintenant très facilement réarranger les éléments de l’arbre hiérarchique des particules, tout comme couper / coller entre les systèmes de particule. Maintenant, lorsque quelqu’un a besoin d’une variation d’un effet déjà existant, cela ne prend que quelques minutes pour le faire.



Plusieurs gros ajouts ont été introduits sur le rendu des particules, et j’ai plusieurs nouvelles options de contrôle, qui définissent la manière dont les particules se font face et s'alignent, lorsqu'elles sont créées ou se déplacent. En outre, les particules supportent maintenant plusieurs nouveaux modes de rendu. Ils peuvent maintenant être éclairés par le monde lui-même, complété par un support pour des “normal maps” pour leur donner l'illusion de volume ou de surface. J'ai fait quelques séries de feuilles tombantes pour la zone de test de Tyler, qui démontrent la combinaison de particules éclairées / normal maps. Le support pour plus de modes est à venir, y compris une distorsion pour simuler la brume de chaleur, les ondes de choc ou les surfaces de réfraction. De plus, les particules supportent également certains des systèmes de rendu PBR, pour encore plus de souplesse...

James K : Ce mois-ci, j’ai travaillé en tandem avec Charles à améliorer la boutique CSE pour une mise à jour future. Nous avons fait des avancés pour la rendre plus facile à utiliser sur différentes fonctions, en ajoutant une navigation plus réactive et des Tiers regroupés. Ca sera un peu moins chromé, mais la facilité d'utilisation devrait améliorer l'expérience de nos Backers ! La section des filtres a été simplifiée, de sorte que les Backers puissent rapidement afficher les Tiers qui les intéressent.



J'ai également travaillé sur des icônes de dégâts pour notre chat de discussion et le système de santé “Tête haute”(HUD). Ils étaient assez délicats, car nous avions besoin de montrer un élément sans couleurs, et aussi de l'intégrer dans un cadre de 15x15 pixels. Avec l'aide de l'équipe et de nos Backers, nous avons pu nous mettre d’accord sur un ensemble d'icônes qui devraient fonctionner correctement pour notre première version. Ensuite : les icônes de classe, ainsi que des armes, des armures et des items. Tout cela aura probablement une certaine révision tout au long du développement, mais il est essentiel de faire en sorte que notre Beta 1 se passe vraiment comme dans un jeu.

Tyler : Etre agent de production sur le projet , ainsi que “lead environment artist”, demande de savoir jongler et d’être patient. Mon attention varie généralement entre ces deux emplois; cependant, ce mois-ci, j’ai dut consacrer bien plus de temps aux graphismes. De ce côté des choses, j’ai été occupé à actualiser et garnir de vieux actifs pour qu’ils fonctionnent avec le nouveau moteur de rendu, tout comme importer de nouveaux, lorsque j’en avais le temps. Les anciens seront la plupart du temps utilisés dans la deuxième version des biomes existants, ainsi que trouver des moyens de créer les nouveaux sans repartir de zéro. Cela aboutit à un peu de supervision avec Dionne, alors qu’elle remplit les manques dans les actifs des variations par royaume, que nous vous avons montré précédemment. Il y a toujours une première version “acceptation-du-concept”, puis suivent les variations.



En termes de construction de biomes, Ben était occupé à créer de grossières nouvelles îles pour la Beta 1. Cette configuration initiale est assez rapide, mais nous avons réalisé que la façon dont il assemble les choses et la façon dont je le fais moi, ne s’accordent pas. Nous avons pris du temps ce mois-ci pour définir un plan, permettant des itérations plus rapides des «biomes» en changeant la façon dont nous assemblons les cartes avec notre éditeur de mod d’environnement. Mon objectif personnel est de voir des personnes, autres que moi-même, rassembler des actifs et des topographies de façons différentes que ceux prévues, à créer des environnements nouveaux et intéressants. L'équipe artistique peut ensuite passer continuer et modeler tout cela. Dans cet esprit, il y a encore plusieurs jours de travail fastidieux et de tests à réaliser, mais le gain devrait être plus de variété et plus de variations par rapport aux actifs existants, avec moins de temps total à les créer.

Tout temps libre que j'ai eu après cela, a été consacré à s'assurer que Scott, Sandra et Andrew ont ce dont ils ont besoin pour continuer à améliorer les animations et le système affilié pour la Beta 1. L'animation a été un objectif très important, qui est déjà payant. Croyez-le ou non, j'ai rassemblé tous les artistes hier pour regarder Scott faire courir un personnage masculin sur les collines, puis sauter d'une corniche. Cette phrase représente des semaines de travail de plusieurs personnes pour que cela se ressente et se voit bien, en particulier l'animation de chute qui commence quelques secondes après le saut du rebord !

Ensuite, nous nous sommes concentrés sur la boucle entière des armes qui sont portées sur le personnage, pouvant être équipées et rangées pendant les changements de posture et en s'asseyant. L’action de s'asseoir peut sembler étrange à spécifier dans ce cas, mais elles a des implications de conception qui peuvent exiger des changements de posture pour s'asseoir et se relever. Bonus : nous allons ajouter quelques emotes. Le défi de faire tout cela a été tout à fait exaltant, et j'ai personnellement beaucoup appris sur les systèmes d'animation, à travailler avec toute l'équipe.

Oh, j'avais presque oublié ! J'ai également lentement assemblé une variation sur le "Biome d'automne" qui a une pile d'actifs VFX prêts dans les modèles environnementaux. Le but ici est de nous donner des cas de test dans le jeu, suite à la mise à jour du système de rendu des particules et des nouveaux shaders. George et Dave peuvent entrer dans le jeu et déterminer où nos attentions seront portées pour la prochaine étape sur la performance. Entre-temps, nous mettons en place une carte de test amusante pleine de particules, dans lesquelles les Backers pourront se s’amuser, tout en nous donnant des retours sur la performance de leur propre configuration PC. Cette tâche m'a également permis d'optimiser quelques actifs, ainsi que passer du temps de jeu supplémentaire sur les maps de surbrillance de certains actifs. Très amusant !

Scott : La collaboration constante entre l’équipe artistique et de développement, ce mois-ci, a permis une accélération de la mise en œuvre des tests et de la réorganisation des animations. Andrew a créé des outils pour nous permettre de créer de nouveaux clips d'animation en «mélangeant» les animations du haut et du bas du corps, du bras droit et gauche à partir de clips préexistants. Par exemple, cela nous permettra d'utiliser un clip de course du bas du corps existant et de le coupler avec un clip du corps supérieur tenant un nouveau type d'arme. Si jamais nous modifions le(s) clip(s) existant(s) de la course, ils mettront automatiquement à jour tout clip "mixte" qui l’(es) utilise(s). Pourquoi cela est-il si pratique ? Eh bien, cela nous permet de modifier et de mettre à jour nos actifs à mesure que le nombre d'animations requis augmente pendant le développement.



Nous avons également continué à améliorer l'apparence des sauts du personnage, ce qui a été un défi supplémentaire, car nos personnages utilisent la physique côté serveur. Cependant, le gain a été évident, avec des personnages combinant différents cycles de mouvements, alors qu'ils montent et descendent des collines. Nous soutenons également d'autres choses comme un saut en pleine course, par rapport à votre saut sur place, ainsi que des animations pour un temps de chute plus long, au cas où vous vous retrouverez projetés dans les airs !

J'ai également eu le temps d'améliorer l'apparence des mouvements de la grande hache, ainsi que de créer une animation de poussé en arrière (knockback) basique, qui attend sa mise en place par d'Andrew. Ce coups de recul devrait être sympas, car nous avons déjà fait une liste d'idées amusantes pour lui donner une bonne apparence et ressentie.

Comme notre grossière première version pour permettre un combat basique est en train de se conclure, c’est excitant de voir où nous pouvons apporter des améliorations et nous concentrer à polir les animations !

[ouliane]

Tech Central -par George Davison

Les écrans HDR et CU

Cette édition spéciale de Tech Central provient d'une réponse de George à une question d'un de nos Backers sur les écrans HDR. Nous la reprenons ici, développé dans un article épique pour votre lecture personnelle !

On nous a récemment demandé si CU supporterait les écrans HDR via notre système d'éclairage HDR.

La réponse courte est oui ; Nous prévoyons de supporter les nouveaux modes d'affichage HDR sur le matériel dédié, et cela devrait être une amélioration spectaculaire sur la qualité. Cependant, ça ne sera pas exactement comme vous l'attendez.

Le HDR dans les films et les formats d’affichage

HDR signifie “High Dynamic Range”("imagerie à grande gamme dynamique"). Mais ce n’est pas très approprié, car l'acronyme est utilisé de différentes manières signifiant par la même différentes choses.

Le terme HDR provient de la photographie. La plupart des films ont un rapport de contraste d'environ 1: 10 000. Cela signifie que le blanc, le plus brillant possible, à une exposition donnée, et avec des paramètres optimisés pour la gamme, d’environ 10 000 fois plus brillant que le gris le plus sombre. Ou 10 000 couches de gris entre les plus sombres et les plus légères. Cela peut être appelé «rapport de contraste» ou «gamme dynamique» de l'image.

Une image d'appareil photo numérique en RAW comporte entre 2 et 8 fois la gamme d'une caméra vidéo, selon la technologie. En utilisant ce fait et la capacité de nombreux appareils photos à prendre plusieurs versions de la même image sur différentes expositions, les photographes peuvent créer des images avec une grande gamme dynamique. Ce qui signifie que les détails dans l'image seront visibles dans une gamme de luminosité supérieure à la normale pour le film ou pour l'impression.

Même si la technologie de capture des images s'est améliorée, l’affichage et l’impression continuent à utiliser les mêmes standards depuis des décennies. Et tandis que l'impression sera toujours limitée en gamme, moins même que les photographies, la gamme disponible pour les écrans s'est améliorée récemment avec les OLeds et les cartes LED dynamiques

Tonemapping (mappage des teintes)

L'impression et la gamme d’affichage standard ont un taux de contraste d'environ 1:64 (selon la norme sRGB et rec 709).

Les photographes peuvent produire des images avec des plages de 1: 1 000 000 et certaines technologies d'affichage standard peuvent produire des rapports allant jusqu'à 1: 600.

Nous traduisons des images d'une gamme à l'autre, depuis le sRGB à la luminosité de l'affichage réelle, ou descendons d'une photographie HDR à une impression en utilisant un processus appelé tonemapping.

Ecraser une gamme dynamique élevée vers une autre inférieure, sans modification, créerait une image lavée à l’affichage. Le Tonemapping remappe la courbe de luminosité pour garder le contraste élevé dans les zones où il est le plus visible.

Lors de l'impression d'images HDR, de nombreux photographes utilisent une version plus complexe du tonmapping appelée contraste local. Ce processus est souvent simplement appelé HDR dans la communauté de la photographie, mais en réalité il fait le contraire. Il prend une image HDR et assombrit certaines zones tout en éclaircissant les autres, de sorte qu'elle soit toujours visuellement attractive, lorsqu'elle est cryptée et affiché sur un périphérique à faible dynamique, ou lorsqu'elle est imprimée.

Ce processus crée un effet “cartoon”, contrairement aux jeux vidéo traditionnels non HDR.

Le HDR dans les jeux vidéo

Le HDR dans les jeux vidéo vise l'effet inverse de la photographie HDR. Nous voulons rendre le monde en grande gamme dynamique. Dans notre cas au 1:16 384. Ensuite, nous simulons l'effet de l'enregistrement sur une caméra à gamme limitée. Comme sur un film, il surexpose les parties claires et perd en détails dans les ombres.
Cela n’a rien avoir avec la façon dont nos yeux perçoivent naturellement la lumière, mais à travers les films et la photographie, nous avons été formés à percevoir cela comme un effet plus réaliste. Et il nous permet de rendre l'éclairage réel en utilisant des fonctions beaucoup plus réalistes, ce qui améliore encore le réalisme.

A côté : comment perçoit-on la luminosité.

La façon dont l'œil humain perçoit la couleur n'est pas linéaire. Nous voyons beaucoup plus de détails dans les zones lumineuses que dans les zones sombres, et le rapport entre les luminosités est encore plus important dans la façon dont nous percevons la lumière en tant qu’humain. Cette courbe signifie que nous voyons quelque chose qui comprend environ 20% de luminosité à mi-chemin entre le noir et le blanc.

La norme sRGB, et maintenant la rec 709, utilisent cette non linéarité pour décrire comment nous stockons et transmettons des images entre les périphériques afin qu'ils gardent la même apparence partout. Cela se fait en mappant cette gamme, de sorte que chaque différence perceptible de luminosité soit mappée autour de la même proportion quantitative dans les nombres utilisés pour décrire chaque couleur. De cette façon, nous ne gaspillons pas de bits en encodage sur les variations de gris foncé, que l'œil humain ne peut même pas percevoir.

L’impression et Les standards d’affichage de gamme standard ont un taux de contraste d'environ 1:64. Certains affichages permettent une plus grande gamme, mais utilisent des astuces de tonemapping pour afficher une gamme plus large sans modifier grandement la façon dont les images se ressemblent. L'affichage d'une image d'une certaine gamme sur une autre non calibrée sans tonemapping, créerait une image qui ne ressemblerait plus à l'original ; elle serait délavé ou ses parties plus claires seraient en surexposition.

Précision : Gamme de couleurs

La gamme de couleurs se réfère à la capacité d'un écran, d'une appareil photo ou d'une imprimante à capturer, imprimer ou afficher avec précision toutes les couleurs que l'œil peut voir. La gamme décrit le spectre complet de couleurs qui peut être affiché, capturées ou encodées dans un format d'image. sRGB, appelé Rec709 lorsqu'il est utilisé sur les téléviseurs HD, est une norme pour l'encodage d'images et décrit comment une valeur numérique dans un fichier image devient une couleur réelle.

La Rec 709 ne peut pas décrire toute le spectre des couleurs qu'un humain peut voir. Cependant, cela marche bien, car il fonctionne correctement pour toute la gamme de couleurs que les périphériques d'affichage standard peuvent afficher. Jusqu'à l'introduction de téléviseurs HDR, qui peuvent eux afficher à la fois plus de couleurs et plus de luminosité que la norme précédente prenait en charge.



(Image via https://commons.wikimedia.org/wiki/F...nd_Rec_709.svg, creative commons attribution license.)

Ce qui nous amène enfin aux moniteurs HDR et aux jeux vidéos.

La plupart des moniteurs HDR des dernières années étaient plus un appel marketing. Ils ont commercialisé une courbe de contraste agressive, en la faisant passer pour plus de détails visuels, sans réellement augmenter la gamme dynamique au-delà de 1: 600.

Cependant, il existe maintenant une nouvelle norme pour le 10 Bit UHD HDR, avec laquelle les moniteurs HDR les plus récents sont compatibles. La nouvelle norme apporte une augmentation spectaculaire du contraste, mais plus important encore, elle augmente la gamme et se tourne vers un encodage à 10 bits. Cela permet d'afficher plus de détails fins dans cette nouvelle gamme, sans perdre la qualité de l'image, comme cela se produirait si nous avons simplement élargi la gamme de la norme existante.

Ses avantages seront principalement automatiques, pourvu que votre carte vidéo et D3D prennent en charge la nouvelle norme. Cependant, bien qu'il s'agisse d'une gamme dynamique supérieure à toutes les normes d’encodage précédentes, la technologie réelle d'affichage passe maintenant uniquement à la gamme supportée par les moniteurs CRT de la génération précédente.

La technologie n'a pas encore atteint le point où regarder un téléviseur serait semblable à regarder par la fenêtre. Les téléviseurs HDR ne sont pas encore à rivaliser avec la gamme dynamique complète que l'œil humain peut percevoir dans un instant T, et encore moins la gamme complète sur laquelle l'œil peut s'adapter au fil du temps.

La différence entre la pleine lune et le soleil est de 1: 400 000, et une pleine lune de nuit semble encore brillante à nos yeux. La gamme d’efficacité réelle de l'oeil est d'environ 1: 1 400 000 000 000, tandis que les meilleurs moniteurs UHD HDR ont une gamme de luminosité réelle d'environ 1: 20 000, stockés dans un format de données qui est juste assez grand pour ne pas tronquer cette gamme déjà très limitée.

Cependant, sur les jeux qui le supportent, vous verrez une augmentation spectaculaire du détail des couleurs. Parce que, bien que la technologie des écrans n'ait pas amélioré la plage de contraste immensément, nous pouvons retransmettre des variations beaucoup plus subtiles dans les images avec la nouvelle norme de stockage 10 bits, donnant un contraste et une gamme plus grands.

Ainsi, les joueurs peuvent s'attendre à voir moins de postérisation (qui est du bruit et des lignes dans des zones de couleur lisse, comme le ciel) et une meilleure reproduction des couleurs. Et si le jeu le prend en charge, ils peuvent voir des différences de luminosité à l'écran, environ 2 à 4 fois plus brillantes que précédemment.

Alors que cette génération d’écran HDR sera une amélioration marquée pour les jeux qui les supportent, ne croyez pas à tout le battage médiatique que vous voyez. Ce ne sera pas comme regarder par une fenêtre, et cela ne supprimera pas la nécessité de devoir atténuer les surexpositions lumineuses dans les systèmes HDR des jeux vidéo. Dans certains cas, il se peut même que cela ne se distingue pas des téléviseurs non HDR avec des modes de tonemapping à contraste élevé, souvent appelés mode Vivid ou Dynamique.

Voilà, c’est tout sur ce sujet. J'espère que vous avez apprécié ces réflexions sur le HDR et les jeux ! Si je cherchais un nouvel écran aujourd'hui, je choisirais un écran UHD HDR10 ou HDR12. La technologie va rapidement s'améliorer, mais il pourrait être utile d'attendre que les prix et les normes se stabilisent, même si je pense que les téléviseurs HDR seront l'avenir des jeux.

[guedgued]

Tu carbure à quoi ?

Vraiment merci au nom de la communauté fr qui continue à croire en ce jeux

[Bloodkissou]

Merci Ouliane

[Philinne]

Merci

[Scoubee]

Merci !

[ouliane]

"Art It Up !" de posté. Tech Central devrait prendre un peu plus de temps, car pas mal de vocabulaire que je ne maîtrise pas...

[Shikaru]

grand merci Ouliane , mais quel homme!
Ça va paraître peut être bizarre mais je suis rassuré de savoir que le système AIR ne fera pas partie de la B1 (on s'en doutait un peu) BETA en vue pour cet été je le sens

[Atixia]

Énormément de tâches accomplies du côté de CSE ainsi que du tiens Oulinane, encore merci !!

[Artheb]

Super, merci Ouliane

[ouliane]

Troisième et dernière partie de la newsletter #33 "Tech Central" par George Davidson est postée.

[Scrooge McDuck]

Merci à toi pour le boulot