Pourquoi ne devrais-je pas permettre de changer le champ de vision, si la technologie le permet?

Il s'agit moins d'une question visant à développer un jeu que de la technologie derrière. Un certain nombre de journalistes de jeux et de joueurs professionnels (dans le secteur des tournois et du divertissement à domicile) martèlent souvent sur le fait que tout jeu à la première ou à la troisième personne devrait avoir un moyen de changer le champ de vision, et je suis d'accord avec eux. La principale raison pour laquelle ils mentionnent cela est parce qu'un assez grand nombre de joueurs souffrent de maux de tête et de fatigue oculaire liés au mal des transports s'ils jouent avec un champ de vision trop contraint.

Je peux comprendre si un développeur indépendant ne le permet pas en raison de contraintes budgétaires, car il doit ajouter un support au moteur pour cela. Cependant, un certain nombre de développeurs utilisent des moteurs tiers de haut niveau comme Frostbite, Unity, Unreal ou Cryengine, mais n'offrent pas d'option pour changer le champ de vision.

Pourquoi ne devrais-je pas permettre de changer le champ de vision, si la technologie le permet?

4A Games, les développeurs de Metro: Last Light recevaient beaucoup de critiques pour ne pas avoir de curseur FoV dans leur jeu. Le responsable de la communauté, Maurice Tan, a défendu sa décision sur les forums Steam comme suit :

La raison principale du maintien d'un FOV fixe est que nous avons des éléments 3D comme la montre et les munitions d'armes qui doivent rester visibles.

De plus, toutes les scènes et cinématiques coupées à la première personne du jeu et chaque animation impliquant les mains d'Artyom - animations d'arme inactive, rechargements, escalade d'échelle, attaques de mêlée, etc. - ont été créées en supposant le même champ de vision fixe.

Changer le FOV briserait toutes les cinématiques et animations - vous pourriez voir à l'intérieur des bras d'Artyom, ou ils sembleraient flotter dans l'air devant vous. Ou pire.

Nous avions envisagé d'offrir trois préréglages FOV, mais cela nécessiterait encore un travail important pour refaire chaque animation, ajuster le HUD et l'interface utilisateur et d'autres tâches apparemment petites mais incroyablement longues.

Même avec un champ de vision plus large mais toujours fixe, les mains d'Artyom sembleraient trop loin. Nous savons - nous avons essayé.

Les performances du jeu sont également liées au FOV - la quantité de détails géométriques que nous mettons dans chaque scène a été en partie déterminée par ce FOV défini, et définir un FOV plus large aurait un impact sur les performances.

La principale raison de ne pas avoir de curseur FoV était qu'ils optaient pour une approche à haute immersion sans hud car toutes les informations importantes pour le joueur étaient affichées sur des éléments 3D dans leur champ de vision. Lorsque votre interface graphique fait partie de votre scène de rendu, la modification du champ de vision change votre interface graphique.

Quelque chose que Tan n'a pas mentionné dans le post ci-dessus mais qui a probablement également fait partie de sa décision est que le FOV est important pour la planification des niveaux. Metro: Last Light est un jeu d'horreur avec beaucoup de sauts et d'autres moments de choc. Il y a beaucoup de situations où le joueur est distrait par quelque chose d'intéressant alors il regarde dans une direction, puis est surpris par une attaque soudaine du côté. Cet effet de choc ne peut fonctionner que lorsque les concepteurs de niveaux connaissent le champ de vision du joueur et savent donc ce qu'ils peuvent et ne peuvent pas voir lorsqu'ils regardent d'un certain point à un autre.

Le même problème apparaît également d'une manière différente lors de la réalisation de cinématiques. Lorsque vous avez des cinématiques à la première personne à immersion élevée, vous voulez probablement avoir un contrôle total sur la caméra pour pouvoir contrôler ce que le joueur peut et ne peut pas voir. Mais lorsque vous ne connaissez pas le FOV, il peut être impossible de diriger correctement la cinématographie. Lorsque le champ de vision du joueur est supérieur à ce que vous attendiez, ils verront des objets qu'ils ne sont pas encore censés voir. Lorsque le champ de vision est plus bas, le joueur ne verra pas ce qu'il est censé voir pendant une cinématique.

Ne pas avoir de curseur FOV dans votre jeu pour des raisons budgétaires ou techniques n'est pas un argument. FOV n'est qu'un paramètre dans la création de la matrice de projection-vue. Après avoir une matrice appropriée, tous les autres calculs suivront d'eux-mêmes. Pour le dire d'une autre manière, rendre le champ de vision modifiable signifie qu'une seule ligne de code doit être modifiée (dans la classe de la caméra en général) et qu'une option doit être ajoutée au menu. Le changement ne se propage pas dans d'autres systèmes, ils ne «voient» que la matrice 4x4 et ne se soucient pas de la signification des valeurs à l'intérieur.

public static Matrix CreatePerspectiveFieldOfView (
         float fieldOfView,
         float aspectRatio,
         float nearPlaneDistance,
         float farPlaneDistance
)

Création de matrice avec champ de vision dans XNA

Cependant, il existe de bonnes raisons de ne pas avoir de curseur FOV modifiable. La définition d'un FOV plus élevé signifie que vous pouvez voir plus de monde à l'écran, cela aura un impact sur les performances. Une autre raison est qu'en jeu compétitif, le joueur avec un réglage FOV plus élevé aura un avantage car ce joueur peut voir plus autour de lui. Enfin, il peut être un choix esthétique. Un champ de vision étroit donnera au joueur une sensation différente d'un champ de vision large. Surtout dans les tireurs avec des couloirs étroits, un champ de vision étroit pourrait ajouter à l'expérience. Un bon exemple de ceci est les jeux Call of Duty où lorsque vous visez vers le bas, le FOV devient plus petit.

(Notez que personnellement, je ne pense pas que l'une des raisons ci-dessus devrait mettre très bas sur le FOV, je veux juste illustrer qu'en aucun cas c'est un problème technique.

Personne n'a mentionné de test.

Chaque aspect du contrôle que vous donnez à un joueur est une autre variable que vous devez tester. Pour une couverture complète approximative, vous devez effectivement jouer à chaque FoV potentiel, dans le cas où vous ne rencontrez des problèmes graphiques qu'à un niveau dans des circonstances particulières lorsque vous êtes dans le FoV le plus large ou le plus étroit, ou "lorsque vous avez enregistré le jeu au plus étroit et ouvert la sauvegarde au plus large ".

Ce coût / retard supplémentaire peut ne pas valoir la valeur supplémentaire de l'élargissement du FoV. Ce n'est pas parce que le moteur le prend en charge qu'il «fonctionnera tout simplement» (bien que cela le rende plus probable). Et ce n'est pas parce que les calculs doivent tous fonctionner que l'expérience utilisateur sera positive.

Du point de vue de l'utilisateur, la principale raison est qu'en multijoueur, un champ de vision plus large donne un avantage injuste.

En tant que développeur, changer le champ de vision est une décision précaire à prendre. Cela devrait également être une décision prise tôt dans le jeu, dans un studio multi-personnes, il est important qu'une fréquence d'images minimale et un FOV soient déterminés tôt afin que les animations et l'abattage d'occlusion aient quelque chose de strict à travailler. Bien sûr, la suppression d'occlusion peut être basée sur de nombreux facteurs, pas seulement sur la vue de la caméra.

Je dirais que la principale raison pour laquelle je n'ai jamais permis de modifier le champ de vision dans le jeu est que lorsque c'est le cas, le gameplay est généralement très modifié, je le sais également comme provoquant le mal des transports. Cela signifiera également que la caméra rend plus, ce qui signifie un énorme impact sur les performances, car les jeux sont généralement optimisés pour leur champ de vision.

Cependant, cela suppose que je vous permets un contrôle total. Il pourrait être possible de permettre à l'utilisateur de modifier le cône de vue, par exemple 70-110 ou quelque chose, mais je ne sais pas sans le tester moi-même.

Les autres ont donné un tas de bonnes raisons - Esthétique (scènes coupées, look & feel souhaité du jeu), équilibrage multijoueur, baisse de performance avec wieder FOV, mais je veux ajouter quelques idées à l'aspect technique:

En particulier, les problèmes techniques sont probablement plus compliqués que beaucoup d'entre vous ne le pensent, car beaucoup de traitement est effectué sur GraphicsBuffers et ces tampons ont généralement une résolution fixe - donc beaucoup de détails graphiques dépendront de la traduction de ces tampons dans la géométrie réelle. . Par exemple, de nombreux algorithmes Shadow modernes (à part les ombres volumétriques) ont de plus en plus de Blocky et de Alias ​​avec un FOV plus élevé et la même taille de tampon. Il en va de même pour tout algorithme qui effectue des opérations de lancer de rayons, car le champ de vision est plus large, les rayons individuels sont répartis sur un arc plus large et plus de détails peuvent se perdre dans les approximations ...