Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Combat : pas de fausse physique


Recommended Posts

Aujourd’hui nous allons parler des comment nous avons utilisé le moteur physique chez l’équipe de combat.

 

Unity comprend un moteur physique assez robuste d’entrée de jeu, donc notre premier objectif était de le faire marcher sur un environnement du style client/serveur. Cela ne fut point chose facile, mais l’enjeu en valait la chandelle vu que notre objectif est d’utiliser une physique réaliste dans autant d’éléments de gameplay que possible. Nous supposons que ça va engendrer plein de nouveau gameplay car il est difficile de prédire les résultats quand on jette des minotaures et des centaures tels des boules de pachinko (jeu de loto japonnais... le japon….) dans un combat. Ça sera soit génial, soit vraiment horrible. Notre but est de créer un monde avec cette simulation physique réaliste, donner à chaque archétype des jouets (tu la sens la charge des centaures ?), et laisser les joueurs voir ce qu’ils peuvent faire de tout ça. Ensuite, nous ajusterons en enlevant ce qui ne marche pas et en gardant le fun.

 

Les joueurs ont tendance à avoir des attentes spécifiques concernant les capacités de leurs personnages dans les jeux – la norme pour les mmos de la dernière décennie fut d’autoriser les personnages une course de 145 km/h, de s’arrêter immédiatement, et tourner plus vite qu’une pièce à pile ou face. Aussi absurde que cela puisse avoir l’air, c’est plutôt normal si l’on prend en compte différents facteurs et si cela permet au gameplay d’être plus apprécié.

 

La plupart d’entre nous ont l’habitude de voir ce qui RESSEMBLE à de la physique dans les mmos, mais qui sont en vrais que des effets de lumières et de fumés entre le serveur du jeu et le client joueur. Mettre en place de la fausse physique requiert beaucoup de temps et d’efforts afin que l’effet rendu soit beau. C’est une des raisons pour lesquelles nous souhaitons utiliser le moteur natif d’Unity : nous pouvons créer plus de jouet pour vous beaucoup plus vite.

 

Vous avez peut être vu des personnages dans un mmo utiliser une compétence de lasso magique afin d’attirer un personnage jusqu’à eux.  C’est généralement très beau. Derrière la scène cependant il se passe deux ou trois bricoles afin de rendre l’effet possible. Dans la plupart des cas, l’attaquant doit avoir une ligne de visée ininterrompue avec sa cible (pas de rochers / mobiliers entre les deux). Le serveur téléporte ensuite (ou « warps ») la cible au pied de l’attaquant. Les deux joueurs voient de belles animations, mais ce n’est pas vrai. C’est faux (toute une enfance détruite… snif). Le résultat final est qu’un joueur peut en attirer un autre quel que soit sa taille ou masse. Cela n’est pas de la vraie physique. Cependant, le rendu est là et est beau.

 

Dans Crowfall, nous faisons cette action de manière différente.

 

Chaque personnage a un panel d’attributs physiques, tels que la masse et la traînée (résistance), qui sont définies archétypes par archétypes  selon ce que nous pensons à le plus de sens. Nous utilisons des valeurs similaires à ce que nous pensons un humain ou un centaure utiliseraient, gardant à l’esprit que nos humains font 2m de haut, cours à 6m/s, et peuvent sauter 1.5 m en l’air en armure de plaque. Quelle bête!

 

Le lasso, quand effectué, tire un rayon (RayCast) vers le centre de son réticule HUD (le centre du viseur). Actuellement, ce rayon est fait de telle sorte qu’il continu, même après avoir atteint une première cible, jusqu’à sa portée maximale, de fait « attrapant » plusieurs cibles. (Donc ne marchez pas en file indienne pour cacher votre nombre ou vous courrez le risque d’être tous attrapé en un pull). Le rayon applique une vélocité inverse à tout ce qu’il touche, et ce dans la direction du Chevalier, que ce soit un objet du décor (baril) ou un autre joueur. A partir de la masse de la cible, et sa vélocité, le moteur physique détermine à quelle vitesse les objets se font projeter vers le Chevalier (Nous avons vite découvert qu’il fallait aussi augmenter temporairement la masse du Chevalier lors de se sort afin qu’il ne soit pas pulvériser par les objets qui lui arrivent dessus). Les applications possibles vont loin : vous pouvez vous servir d’objets pour déplacer d’autres objets ; déplacer des joueurs (et objets) au-dedans et en dehors d’AOE. Ajouté à ce système un environnement destructible et les choses deviennent très intéressantes ! (y’a que moi qui imagine 10 chevaliers qui tire sur un mur ou des combats de tronc d’arbres ?)

 

Comme nous pouvons ajuster la masse de chaque personnage selon leurs archétypes, et ce, en temps réel, nous pouvons contrôler la facilité avec laquelle chacun peux être attiré ou poussé par les différentes forces physiques du jeu. Ceci est grandement différent par rapport aux autres mmos qui sont sur le marché  où le plus petit des personnages est affecté de la même manière par les capacités d’un joueur qu’un autre personnage immensément plus grand (Aion ?). Ceci est d’habitude fait afin de garantir une consistance dans le gameplay, mais nous avons la volonté de prendre des risques car nous pensons que cela va nous conduire vers un gameplay assez fun (et, pour être honnête, si ça ne marche pas, nous pouvons toujours faire machine arrière et mettre des valeurs normalisées).

 

Certaines des valeurs clefs avec lesquelles nous avons expérimentées jusqu’à présent sont :

 

La Masse :

La masse d’un objet de X unités (aléatoires). Nous augmentons/décrémentons cette valeur afin que l’objet se fasse plus ou moins facilement bousculé.

 

La trainée (résistance)

Cette valeur est à peu près équivalente au frottement de l’air. Nous nous en servons afin de rendre les objets plus comme des plumes (c’est mignon) ou comme des bus (moins mignon). Le Chevalier, par exemple, flottait trop loin quand il sautait, donc nous avons optimisé cette valeur et le voilà qui retombe beaucoup plus vite vers le sol (bonjour le sol). Cela réduit la portée de ses sauts et donne l’impression qu’il y a un poids derrière lui quand il tombe. En utilisant cette valeur, nous pouvons donner au fae (elfe) un effet « chute telle une plume », ou autoriser le « forgemaster » d’atterrir lourdement (hard land) à la fin du pouvoir super-saut. Nous voulons vraiment que chaque personnage soit différent à jouer plutôt que d’avoir un personnage normalisé portant différente tenue/apparence (skin suit).  

Les types de Friction

Nous avons quelques types de frictions avec lesquels nous pouvons et avons joué. La friction statique est celle d’un objet sur une surface, et la friction dynamique est celle d’un objet en mouvement. Généralement, nous aimons que la capsule (zone de contact standard dans Unity pour un personnage) du joueur soit plus comme du papier de verre quand elle se frotte contre un autre objet plutôt qu’elle glisse telle une surface lisse & liquide.

Nous avons d’autres valeurs que nous pouvons utiliser, comme le facteur de rebondissement pour rendre une surface… rebondissante ; mais nous ne sommes pas encore au point où nous essayons de faire rebondir des choses dans tous les coins (une idée serait de faire rebondir les boules de feu sur le bouclier du chevalier pour la rediriger vers un autre endroit).

Nous avons une longue liste de différents jouets physique que nous allons essayer. Nous avons même une liste de pouvoir appelés iFrames, qui retire le joueur de la simulation physique le temps de l’attaque. Nous les utilisons généralement quand le joueur doit sauter en l’air ou passer au travers de la capsule d’un autre joueur. Les pouvoirs avec cet effet peuvent aussi servir à éviter d’être balancé dans tous les coins.

Ceci est une de nos plus grandes zones d’expérimentation, et nous avons bon espoir que les résultats seront à la hauteur de l’attente. Même dans le cas où aucun des pouvoirs fous inventés ne marcheraient, les bénéfices d’avoir un système plus réaliste apporterons une meilleur expérience de jeu (un jeu qui prend en compte la physique de manière réaliste augmente l’aspect tactique et réduit la possibilité de cheat).

 

Nous espérons que vous avez apprécié cette aperçue des efforts de notre équipe de combat, alors qu’ils continuent leurs efforts vers la première sortie jouable (first playable).

Thomas « Blixtev » Blair,

Design Lead


Note personnelle : j'ai ajouté parfois des (mauvaises) blagues entre parenthèses ou des commentaires persos. Si cela vous gène, je retire immédiatement. 

Comme d'habitude, désolé pour les erreurs et prévenez moi si ça pique trop les yeux :D

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...