[ouliane]

Je ne traduirai que les parties intéressantes techniquement de la Newsletter #27 d'octobre 2016, Art it Up, Dose of Design, State of the Build et Tech Central. Désolé des fautes d'orthographes, grammaticales et des anglicismes à foison. Bonne lecture. Newsletter originale


State Of The Build -par Cory Demerau

Un mois chargé vient de se terminer avec beaucoup de gros projets “back-ends” finalisés dans le même temps ces dernières semaines, permettant de valider de grosses fonctionnalités d’un coups. La plus grande de toute est une mise à jour majeure de notre netcode, nous permettant de faire un plus large nombre de choses plus facilement et rapidement. les compétences aussi ont fait un progrès majeur maintenant que la plus grande partie du coeur du système est opérationnelle, tout en permettant beaucoup de progrès dans l’ajout de toutes les compétences nécessaires pour chacune des neuf classes prévues pour la Bêta. Que ce soit les compétences, warbands, éclairage et performances serveur, il y a eu des changement pour chacun ce mois-ci. Regardons tout ça !

Compétences:

• Ajout de noeuds/paliers supplémentaires dans les composants pour la création de compétences.
• Les compétences peuvent être désormais dépendant des consommables. Les archers peuvent utiliser des flèches, les physiciens des élixirs, etc ...
• Les pierres du Stonehealer ont maintenant des points de vie et donc destructibles par des attaques.
• Les effets de déviation n'inversent plus les soins et les dégâts. Ce qui signifie que si une déviation amène dans le négatif les dégâts d’une attaque, cela ne vous soignera plus.
• Fixé certains problèmes avec les interruptions (avoir votre compétence annulée par le mouvement/dégât reçu).
• Les compétences peuvent désormais avoir de la pénétration d’armure. Ce qui le rend plus susceptible de percer l'armure lourde de votre cible et de produire leurs dégâts maximums.
• Premier jet pour les postures. Pour l’instant, les joueurs entrent en “posture de voyage” lors de arrivée en jeu. Des postures supplémentaires seront ajoutées rapidement !
• Fixé un problème avec les résistances d’armure.
• Le suivi des compétences a été ajouté, permettant aux joueurs d’exécuter de multiples compétences en même temps.
• Les joueurs peuvent désormais utiliser des compétences autres que celles créées, comme celles des engins de siège.
  

Warbands:.

• Fixé différents bugs dans les Warbands et amélioration de leur performance.
• Les leader de warband ont maintenant plus d’options et sont proprement affichées sur l’UI. Si le leader de la Warband la quitte, un autre joueur devient le leader. Le leader peut aussi donner les commandes à un autre joueur avec la commande /makeleader. Les leaders de warband peuvent désormais /kick d’autres joueurs hors du groupe, ou /promote des membres pour leurs permettre d’inviter d’autres joueurs.
• Il y a une taille maximum pour une warband (8 joueurs pour l'instant).
  

Personnages:

• Fixé certains problèmes qui causaient les valeurs de régénérations à ne pas fonctionner/s’afficher correctement.
• Les personnages peuvent maintenant recevoir des traumatismes, lorsqu’ils subissent trop de blessures sur une même partie du corps.
  

Serveur:

• Fixé certaines erreurs qui occasionnaient notre compilateur de script à utiliser bien trop de mémoire. C’est un gain majeur de performance serveur.
• Le client se connecte et se déconnecte dynamiquement aux serveurs, selon les zones concernées par leur joueur. Si un serveur s’ouvre alors que vous jouez et que cette zone est proche, le client s’y connectera et vous verrez la zone apparaître. Aussi, si vous vous éloignez suffisamment d’une zone distante, le client se déconnectera de ce serveur.
• Révision massive de notre code réseau UDP ajoutant plusieurs bénéfices, incluant telles que :
  
  
  • Génération de code qui créent automatiquement du code pour la communication entre le Serveur de Jeu et le Serveur Proxy. Ce code généré permettra en définitive d’autres type de serveurs, tels que le Groupe de Serveur, à automatiquement recevoir des données du Serveur de Jeu.
  • Plusieurs améliorations sur l’utilisation la bande passante sur tous les domaines utilisés par les compétences, avec assez de généralisation pour que les systèmes non spécialisés puissent en profiter à l'avenir. Les couches de réseau supportent maintenant le nouveau modèle entité-composant que nous avons créé durant la réhabilitation.
    
  
  

Client:

• Fixé une erreur avec notre code d’authentification, comme ceci Windows ne se plaindra plus que nous ne somme pas sécurisé durant les quelques semaine après notre renouvellement annuel.
• Fixé un crash au démarrage.
  

Equipements:

• Les armes ont désormais des stat de pré-requis. Si vous ne les remplissez pas, vous pouvez toujours équiper l’arme, mais vos compétences ne s'activeront pas.
• Les équipements supportent maintenant le placement sur l’une des nombreuses options d’emplacement. Ceci est surtout utilisé par les armes sans spécifications (peuvent être portées autant sur la main droite ou gauche).
• L’artisanat des armes a été amélioré de façon à ce que les armes ne soient plus automatiquement pour la main droite uniquement. Les “ à deux mains” utilisent maintenant les deux emplacements et les armes sans spécifications peuvent aller n’importe où.
• L’apparence des armes est maintenant dépendante du royaume choisi et chacun d’entre eux à un set d’armes différents. Allez découvrir les différentes épées et bâtons de chaque royaume !
• Ajout d’une commande serveur qui nous permet d’effacer facilement les équipements et de re générer l’équipement par défaut pour chaque personnage, comme cela nous n’avons pas besoin d’effacer les personnages quand un équipement a besoin d’être changé.
  

Artisanat:

• Les points de ressource peuvent maintenant exister dans le monde et utiliser /harvest à côté permettra au joueur de récupérer la substance appropriée. (Note : aucun n’a été placé dans les zones d’Hartchery... pour l’instant)
• Parcelles : fixé un bug qui obligeait les informations d’une parcelle à n’être mises à jour pour un joueur, uniquement si une autre quelconque mise à jour se faisait sur le joueur.
  

Graphismes:

• Activé le “High Dynamic Range Lighting” (HDR). Ceci devrait faire des éclairages atmosphériques plus réalistes. (le ciel sera plus brillant lorsque l’on se trouve dans les endroits sombres, et les endroits sombres plus sombres, lorsque vous vous trouvez en dehors.)
• Fixé le crash d’un driver sur les vieilles cartes Nvidia.
• Différentes améliorations sur la façon dont nous construisons les particules, nous permettront de produire plus d’effets intéressants bien plus vite.
  

UI:

• Les messages de discussion sont mieux gérés, évitant ainsi de se bloquer à cause d’un trop grand nombre de message en même temps.
  

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

Artitup -par Scott Trolan

Encore un bon mois productif parmi la team Art. Beaucoup d’additions, de corrections et d’expérimentations ont été ajouté à l’éditeur et au Build.

Dionne et Jon (DiJon ?) mettent les bouchés doubles, alors qu'ils soumettent un assortiment massif d'armes uniques par royaume à l’éditeur. Jon continu de modifier ses modèles haute résolution en faible polygones, pour que Dionne puisse faire les UV, textures et les importer dans l’éditeur. Notre inventaire d’armes disponibles s'agrandit de plus en plus chaque jour.



Le mois dernier, nous avons ajouté un nouveau cycle d’animation de marche et de course aux personnages.Ce mois-ci, Sandra pris le fichier de “course” existant et réussi à le remanier pour le cycle “course” des personnages féminins. En plus, elle ajouta un subtil déhanchement au cycle de “marche féminine".



Comme les nouvelles animations et possibilité d’équiper les armes dans la main droite ou gauche sont arrivées, des corrections aux marqueurs d’attache existant dans chaque fichier d’animation étaient à effectuer. Ce processus est bientôt terminé, et nous verrons bientôt des boucliers faisant face correctement, les haches et les armes aux tranchants asymétriques tournées vers le bon sens lorsqu’elles sont équipées ou non. Me voici travaillant sur les boucliers :



Michelle a conçu et fourni des illustrations conceptuelles détaillées et des exemples à Jon et Dionne, pour qu’ils puissent texturer les armes. Elle travail actuellement sur le design d’une nouvelle armure de la Cour d’automne des Tuatha Dé Danann.



Mike C. continu de préparer ses fichiers pour les améliorations à venir sur l’éditeur de particules. Il expériment aussi de nouvelles façons de réutiliser les VFX existants pour être capable de prototyper et de réutilisation plus rapides.



James K. a porté plusieurs chapeau ce moi-ci. Lorsqu’il ne crée pas de nouveaux composants d’UI pour le jeu, il dessina et fournit un nouveau logo et animation pour notre segment de livestream “Bring Out Your Devs™”.



De la part de toute l’équipe artistique, nous vous souhaitons un merveilleux et sans-danger Halloween !

[ouliane]

Dose of Design-par Ben Pielstick

Trouver le plaisir de jeu

Une grande partie du temps et des efforts fournis pour le développement du jeu tourne autour d’arranger les choses dans un état fonctionnel de base. Dans le bulletin du mois dernier, j'ai parlé de la façon dont cela se produit pendant le prototypage; Prenant des idées passant des concepts abstraits vers le fonctionnel, aux systèmes jouables, puis prêts pour le banc de test. Maintenant que nous sommes un mois plus loin dans notre développement, j'ai pensé que ce serait le bon moment pour discuter de la prochaine étape, après avoir posé les bases d'un système de jeu important (comme le combat), qui est de «trouver le plaisir de jeu».

Lorsque la version prototype d'une nouvelle fonctionnalité fait son entrée dans le jeu pour la première fois, il y a presque toujours un long chemin à parcourir avant d'être finalisé et prêt à expédier. Bien qu'un bon prototype donne vie avec précision le concept de base d'un design pour la première fois, il y a encore probablement beaucoup de détails à déterminer, et beaucoup d'ajustements encore à faire avant qu'une mécanique commence vraiment à amener le niveau de plaisir qu'il est destiné à apporter.

La pose d'une bonne fondation a beaucoup à voir avec la facilité ou la difficulté de ce processus. Cela peut être pour de nombreuses raisons; Par exemple, la modularité - pour remplacer des parties d'un système par de meilleures, sans avoir à effectuer une reconstruction totale ou une évolutivité, comme par exemple nécessiter de nombreuses optimisations pour améliorer les performances. Autre exemple: restructurer les sources de données pour passer d'une valeur codée à une solution basée sur des scripts ou des bases de données. Un prototype idéal est celui qui peut être construit rapidement, itéré avec, et développé facilement. Ces attributs sont souvent en désaccord les uns avec les autres, cependant: grossièrement, les systèmes inflexibles sont généralement les plus rapides à construire afin de voir si une idée fonctionne, et jeter le moins possible si elle ne fonctionne pas, tandis que les solutions extensibles écrites plus proprement ont tendance à prendre plus de temps, mais peuvent être plus facilement construites lorsque vient le temps d'itérer.

Itérer sur les mécaniques de jeu, les tester, et itérer un peu plus, est où les concepteurs de jeux ont tendance à passer beaucoup de leur temps. La majorité du plaisir qui est mis dans un jeu provient de la subtilité des détails de superposition sur un système qui jouent le rôle le plus important dans la définition de l'expérience de jeu du joueur. Cela inclut des choses comme réviser des indices audio et visuels, ajuster les nombres d'équilibre, et réviser les réponses scriptées en entrée. Il est surprenant parfois comment même de petits changements peuvent faire une grande différence sur la perception du joueur de son amusement en jeu. Des choses comme le nombre de pas qu'un personnage fait par mètre, la façon dont un bouton se met en surbrillance pour indiquer qu'il est prêt à l'emploi, ou le volume de l'effet sonore quand un joueur lance une certaine action, peut affecter de façon drastique la sensibilité et l'amusement qu’un jeu fait ressentir, sans même plonger dans des choses beaucoup plus évidente comme la quantité de dégâts d'une attaque, ou combien de temps un sort prend à se lancer.

Comme vous pouvez vous y attendre, cela peut être un processus long et difficile d'analyser chaque aspect d'un système et de l'ajuster soigneusement pour maximiser le plaisir, tout en maintenant l'harmonie avec toutes les autres parties du jeu. Les capacités, après tout, doivent être aussi amusantes à jouer et utiliser contre et en contre des adversaires, et les effets qui fonctionnent bien en eux-mêmes, aussi doivent bien fonctionner dans le chaos d'une bataille, où ils se mélangent avec beaucoup d'autres effets en même temps. C'est pourquoi beaucoup de tests et de multiples cycles d'itération sont nécessaires, et ce pourquoi passer d’un premier essai d’un nouveau système vers une expérience définitive pour les joueurs, où ils trouveront beaucoup plus d'amusement, peut prend un certain temps.

En ce moment, nous approchons de la fin de notre phase de prototypage du combat dans Camelot Unchained. Les composants d'aptitude de base pour chaque classe ont été scripté et sont actuellement testés. Très bientôt, notre nouveau système de rétroaction audio et visuelle au client sera prêt à nous laisser jouer des animations, des sons et des effets de particules coïncidant avec l'utilisation des capacités construites à partir de ces composants. Lorsque le système sera en place pour la première fois, cela nous permettra d’avoir notre premier regard sur le gameplay du combat comme il est censé être dans Camelot Unchained. (Bien que, bien sûr, de nombreuses fonctionnalités et le contenu devront encore être créés.) Il s'agit d'un grand pas en avant dans le développement du jeu, mais bien sûr, ce n'est qu'un point de départ pour essayer le combat, voir quelles sont les parties amusantes, et de décider comment nous pouvons les améliorer. De même, nous veillerons également à ce que les parties manquant d’intérêts, et de décider de ce que nous pouvons changer à leur sujet, ou comment ils pourraient potentiellement être remplacés. Voilà comment nous allons procéder.

Nous comptons sur ceux d'entre vous soucieux de tester le jeu pour nous aider à faire ces décisions, à la fois en fournissant vos commentaires dans les sondages et sur nos forums, et simplement en participant à nos tests en jeu. Cela générera des données pour notre système de mesure, que nous pouvons examiner pour aider à décider où notre attention est le plus nécessaire. Il peut être un peu chaotique au début, surtout lorsque nous martèlerons les parties grossières dans notre prototype du système initial, mais plus nous ajusterons et ajouterons des fonctionnalités supplémentaires pour aider à améliorer l'expérience, plus polie et amusant le jeu deviendra. Nous sommes tous très impatients de partager ce processus avec vous, alors que nous continuons à travailler vers un point où toutes les parties majeures du combat sont prêtes pour le test de gameplay. Jusque-là, gardez un oeil sur nos mises à jour des progrès et toutes les invitations de test qui arrivent, alors que nous continuons à nous assurer que toutes les pièces se réunissent, en continuant à améliorer chaque étape du chemin.

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

Tech Central-par Rob Argue

Layered Arithmetic Expressions / LAEs (Expressions arithmétiques par couche) ou: Comment j'ai appris à cesser de m'inquiéter et d'aimer les mathématiques

Le fonctionnement des mathématiques dans les jeux peut être une chose délicate, où même les changements subtils peuvent avoir un effet important sur le résultat. Ces subtilités peuvent provenir de plusieurs endroits: comment les maths sont appliqués, déterminer l'ordre des opérations, ou même les maths (autrement sans rapport) de systèmes interagissant. Puisque nous faisons un jeu PvP, c'est pour une de ces raisons principales que le min-maxing y est né : nous devons être en mesure d'avoir un très bon contrôle sur les mathématiques afin de garder les choses équilibrées et saines.

Faisons un petit problème de math pour examiner certaines des difficultés potentiels et des complexités avec un exemple totalement hypothétique. Encore une fois, je le répète, tout dans les exemples suivants est complètement hypothétique, et ne reflète pas les compétences réelles dans le jeu ou les valeurs :

Vous avez une vitesse de déplacement de base de 10m/s. Vous avez un buff de vitesse de déplacement de + 50% avec vos bottes “Pas rapides”, un buff de vitesse de déplacement de + 50% en étant sur une route, un buff de vitesse de déplacement de + 50% par le buff de hâte de groupe et un buff de vitesse de déplacement de + 50% en étant un loup-garou pendant la pleine lune. Quelle est votre vitesse de déplacement totale ?

Il s'agit d'un calcul assez simple, mais la réponse dépend en fait grandement sur la façon dont plusieurs buffs sont appliqués.

Si vous ajoutez tous les buffs ensembles, puis les appliquez, vous obtenez : 10 * (1 + (.5 + .5 + .5 + .5)) = 30
Mais si vous les appliquez un à la fois, vous obtenez : 10 * 1.5 * 1.5 * 1.5 * 1.5 = 50.625

Ce qui est bien sûr une énorme différence (la croissance exponentielle est une chose infernale). Il est clair que nous voulons généralement éviter ce genre de chose, mais cela peut être difficile à faire lorsque ces systèmes ne se connaissent pas les uns les autres. La personne qui conçoit l'équipement travaillait de façon indépendante de l’autre qui travaillait sur les compétences, alors comment sont-elles censées savoir qu'elles devraient ajouter leurs buffs ensemble avant de les appliquer ? Ensuite, le système de “loup-garou” dans son ensemble n'a été ajouté qu’un an plus tard, mais maintenant la personne en charge de cela à besoin de savoir la façon dont les équipements et les compétences fonctionnent, et de les utiliser aussi. Si le code dans chaque système doit être conscient du code des autres systèmes afin de pouvoir fonctionner, alors il se transforme rapidement en une véritable pagaille infaisable.

Cela devient encore plus compliqué lorsque nous décidons que le bonus sur route doit être appliqué après tous les autres bonus, nous donnant ainsi :
10 * (1 + (0,5 + 0,5 + 0,5)) * 1,5 = 37,5

Et puis vous gagnez aussi le titre “Pied léger”, ce qui vous donne +5 à la vitesse de déplacement, mais où cela s'applique-t-il ?
Avant tout les buffs? (10 + 5) * (1 + (0,5 + 0,5 + 0,5)) * 1,5 = 56,25
Après la première série de buffs? (10 * (1 + (5 + 5 + 5)) + 5) * 1,5 = 45
Après le buff sur route? (10 * (1 + (0,5 + 0,5 + 0,5)) * 1,5) + 5 = 42,5

Le pire des cas ici est qu'il importe dans quel ordre les buffs ont été ajoutés au joueur (ont-ils obtenu le titre “Pied léger” avant ou après avoir mis leurs bottes?), ce qui signifie que parfois vous obtenez un nombre ou bien un autre, mais même lorsque vous parvenez à éviter cela, il est toujours compliqué d'y arriver. Lorsque vous faites des maths avec beaucoup d'opérations et de nombres, il y a une bonne chance de se louper d'une certaine manière, tellement que s’en est une plaisanterie assez universelle que l'on doit s’efforcer de faire un nombre pair d'erreurs de signe afin d'obtenir la bonne solution à un problème. Et ne me parlez même pas des parenthèses manquantes ou la façon dont l'ordre des opérations est facilement mélangé.
.
Fondamentalement, les mathématiques sont généralement une énorme douleur pour obtenir 101% correcte, surtout quand il a beaucoup de parties, et plus encore quand elles proviennent de sources multiples qui ne se connaissent pas nécessairement les unes des autres. Tout ce que nous pouvons faire pour simplifier cela permettra de réduire les bugs et de rendre l'équilibrage plus facile.

Ce que nous utilisons pour jouer avec tout cela, c'est ce que j'appelle des expressions arithmétiques en strate (LAEs). L'idée est assez simple: avoir des expressions qui sont littéralement l’ordre des opérations indépendantes, puis utiliser un petit nombre de couches de ceux-ci pour obtenir le contrôle en retour sur l'ordre des opérations. C'est le format dont presque chaque nombre du système de compétence existe dedans, ainsi nous pouvons très facilement ajouter / enlever les buffs, les modificateurs, les limites, etc. à tout. Au fur et à mesure que nous utilisons une compétence, nous accumulons toutes les mathématiques dans une de ces LAEs, et chaque fois que nous en avons besoin, nous l'évaluons. Cela fonctionne également magnifiquement pour le débogage, car nous pouvons voir pourquoi un nombre resort être une valeur spécifique très facilement (et donc peut rapidement ajuster les nombres si nécessaire), ce qui est quelque chose que nous espérons pouvoir permettre aux joueurs d'accéder à l'avenir.

Les spécificités des mathématiques sont :

Pour chaque couche

• Ajoutez toutes les valeurs d'addition ensemble.
• Ajouter toutes les valeurs (normalisées) multiplicatives ensemble.
• Appliquer des limites au multiplicateur (cela empêche les choses comme les résistances causant des dommages négatifs).
• Multiplier les résultats des points 1 et 3.
• Appliquer des limites au résultat (donc on pourrait théoriquement avoir une limite de vitesse universelle, par exemple).
• Passer cette valeur comme une valeur additionnelle à la couche suivante.
  

Pour en revenir à nos précédents exemples maintenant :

Dans le premier exemple (avec les quatre + 50% buffs), nous jetons simplement tout cela, avec la valeur de base, dans la première couche, et nous obtenons le résultat désiré. Dans notre syntaxe interne composée, ça ressemblerait à ceci (avec les étiquettes en dessous) :
[Couche1 + 10] | [Couche1 * 1.5] | [Couche1 * 1.5] | [Couche1 * 1.5] | [Couche1 * 1.5]
-------(Base)-----------(bottes)------------(route)---------------(buff)---------(loup-garou)--

Notez que l'ordre de ces opérations n'a pas vraiment d'importance. Par exemple, si la vitesse de base est déplacée à la fin pour une raison quelconque, comme ceci :
[Couche1 * 1.5] | [Couche1 * 1.5] | [Couche1 * 1.5] | [Couche1 * 1.5] | [Couche1 + 10]
------(Bottes)-----------(route)--------------(buff)----------(loup-garou)----------(base)-----

ça n’a pas vraiment d'importance ; Il évaluera la même chose.

Oh attendez, nous voulions que le bonus sur route s'applique après les autres buffs ? Il suffit de le mettre dans la deuxième couche, fini :
[Couche1 + 10] | [Couche1 * 1.5] | [Couche2 * 1.5] | [Couche1 * 1.5] | [Couche1 * 1.5]
------(Base)------------(bottes)------------(route)---------------(buff)---------(loup-garou)--

Pas besoin de penser où le mettre, ou quelles parenthèses à utiliser, comme précédemment - ça fonctionne simplement.

Et maintenant pour notre titre “Pied léger”. Nous pouvons contrôler s’il va avant n'importe quel buffs en le mettant sur la première couche, avant le buff de route en le plaçant dans la deuxième couche, ou après tous les buffs en le plaçant sur la troisième couche. Par exemple, mettons le sur la couche 1:

[Couche1+10] | [Couche1*1.5] | [Couche2*1.5] | [Couche1*1.5] | [Couche1*1.5] | [Couche1+5]
------(base)----------(bottes)-----------(route)------------(buff)--------(loup-garou)-----(Pied léger)-

Encore une fois, aucun des problèmes que nous avions ci-dessus, juste ajouter et c’est fait.

Une autre bonne chose à propos des LAE est qu'elles peuvent être combinées sans douleur, donc nous pouvons faire des choses comme stocker toutes les opérations sur les dommages de l'attaquant en une, et celles des résistances de défense dans une autre, puis les combiner ensemble et obtenir l'expression correcte pour “Combien cette attaque d'épée fait contre ce gars portant de la maille”.

Dans l'ensemble, les LAEs sont un système souple et direct qui cherche à minimiser la quantité de minuties mathématiques que nous avons à gérer, à permettre une introspection facile et à réduire les bugs mathématiques, ce qui devrait nous permettre d'éviter des explosions involontaires de nombres. Une meilleure gestion de l'équilibrage.

[Zuleika]

Merciii !

[Scoubee]

Merci pour l'initiative !

[eLiat]

Merci pour le taff, c'est cool

[Coeurdur]

Merci pour le texte détaillé assez plaisant !!!

Han Michelle, elle n'a pas qu'un talent artistique certain !

Heu Ouliane, grand fou !

Merci.

[Turlogh]

merci pour la traduction !

[boulcas]

Gg !!

[Aeodo]

GG ouliane

[Esco]

Merci à toi .. vraiment sympa ..

[Tapdur Neanias]

Merci pour la traduction Ouliane, je propose que l'on t'attribue un titre honorifique pour l'effort que tu fais pour la communauté: " Traducteur du Roy "

[Nabotep]

Merci bien Ouliane pour la traduction !

[guedgued]

Merci c'est toujours un travail assez conséquent on le voit.
LA motivation est revenue?

[algweln-thorum]

merci ouliane pour la traduction, gros boulot ^^