Чому я не повинен дозволити змінювати поле зору, якщо технологія це дозволяє?

Це менше питання, спрямоване на розробку гри, а більше про технології, що стоять за нею. Ряд ігрових журналістів та професійних гравців (як в турнірі, так і в секторі домашніх розваг) часто забивають питання, що будь-яка гра першої чи третьої особи повинна мати спосіб змінити поле зору, і я погоджуюся з ними. Основна причина, про яку вони згадують, полягає в тому, що досить велика кількість гравців отримують головні болі та напруження очей, пов’язані з рухливістю, якщо вони грають із занадто обмеженим полем зору.

Я можу зрозуміти, якщо інді-розробник не дозволяє цього через бюджетні обмеження, оскільки для цього їм потрібно додати підтримку двигуна. Однак низка розробників використовує високопрофільні сторонні двигуни, такі як Frostbite, Unity, Unreal або Cryengine, але не пропонують можливість зміни поля зору.

Чому я не повинен дозволити змінювати поле зору, якщо технологія це дозволяє?

4A Games, розробники Metro: Last Light отримували багато критики за те, що вони не грають повзунок FoV у своїй грі. Менеджер спільноти Моріс Тан захистив своє рішення на форумах Steam таким чином :

Основною причиною збереження фіксованого FOV є те, що у нас є такі 3D елементи, як годинник та боєприпаси, які повинні залишатися видимими.

Окрім цього, всі ігри від першої особи розрізали сцени та кінотеатри та кожну анімацію, що стосувалась Артьома руки - анімовані зброї, перезавантаження, сходи по сходах, атаки ближнього бою тощо - були створені при умові того ж фіксованого поля зору.

Якщо змінити FOV, це порушить усі сцени та анімації - ви зможете побачити всередині Артьома, або вони, схоже, плавуть у повітрі перед вами. Або ще гірше.

Ми розглядали можливість запропонувати три попередні набори FOV, але це все ще потребує значної роботи, щоб повторно виконати кожну анімацію, налаштувати HUD та інтерфейс користувача та інші, здавалося б, невеликі, але неймовірно трудомісткі завдання.

Навіть при більш широкому, але все ж фіксованому полі зору руки Артьома виглядали б занадто далеко. Ми знаємо - ми спробували.

Дія гри також пов'язана з FOV - кількість геометричних деталей, які ми вкладаємо в кожну сцену, частково визначається цим набором FOV, а встановлення ширшого FOV матиме вплив на продуктивність.

Основна причина відсутності повзунка FoV полягала в тому, що вони йшли на підхід з високим зануренням, коли вся інформація, важлива для гравця, відображалася на 3-х елементах у їхньому полі зору. Коли ваш GUI є частиною вашої сцени візуалізації, зміна FOV змінює ваш GUI.

Щось Тан не згадував у вищезгаданому пості, але це, ймовірно, також було частиною їхнього рішення, - це те, що FOV важливий для планування рівня. Метро: Останнє світло - гра, орієнтована на жах, з великою кількістю стрибків і інших ударних моментів. Існує багато ситуацій, коли гравець відволікається на щось цікаве, тому вони дивляться в один бік, а потім дивуються раптовій атаці з боку. Цей шоковий ефект може працювати лише тоді, коли дизайнери рівнів знають FOV програвача і тому знають, що вони можуть і чого не бачать, переглядаючи певну точку до певної іншої точки.

Ця ж проблема виникає і по-іншому, коли спрямовується на розріз. Коли у вас є перфорація першої особи з високим зануренням, ви, ймовірно, хочете мати повний контроль над камерою, щоб мати можливість контролювати те, що гравець може, а що не може бачити. Але коли ти не знаєш FOV, правильно керувати кінематографією може бути неможливо. Коли FOV гравця вищий, ніж ви очікували, вони побачать предмети, які вони ще не повинні бачити. Коли FOV нижче, гравець не побачить речей, які вони повинні бачити під час скорочення.

Немає повзунка FOV у грі через бюджетні чи технічні причини - це не аргумент. FOV - це лише один параметр у створенні матриці перегляду-проекції. Після того, як у вас є відповідна матриця, всі інші розрахунки будуть слідувати самі собою. Якщо сказати це по-іншому, перетворення FOV змінним означає, що потрібно змінити лише один рядок коду (як правило, в класі камери) і що в меню потрібно додати опцію. Зміна не поширюється на інші системи, вони лише "бачать" матрицю 4x4 і не байдуже, що значення значень всередині неї.

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

Створення матриці з полем зору в XNA

Однак є вагомі причини не мати змінного повзунка FOV. Встановлення більш високого рівня FOV означає, що ви можете бачити більше світу на екрані, це вплине на продуктивність. Ще одна причина полягає в тому, що в конкурентній грі гравець з більш високою настройкою FOV матиме перевагу, оскільки той гравець може бачити більше навколо себе. Нарешті, це може стати естетичним вибором. Вузький FOV дасть гравцеві інші відчуття, ніж широкий FOV. Особливо у стрільців із вузькими коридорами вузький FOV міг додати досвіду. Хорошим прикладом цього є ігри Call of Duty, коли коли ви прицілюєте свій погляд, FOV стає менше.

(Зауважте, що особисто я не вірю, що будь-яка з наведених причин повинна дуже низько ставитись до FOV, я просто хочу проілюструвати, що це жодним чином не є технічною проблемою.

Одне, про що ніхто більше не згадував, - це тестування.

Кожен аспект контролю, який ви надаєте гравцеві, - це ще одна змінна, яку ви повинні перевірити. Для орієнтовного повного висвітлення вам ефективно доведеться грати на кожному потенційному ФоВ, якщо ви отримуєте графічні випуски лише на одному рівні за конкретних обставин, коли ви знаходитесь у найширшому FoV чи вузькому, або "коли ви зберегли гру в найвужчому та відкритому режимі" збереження на найширшому рівні ".

Ця додаткова вартість / затримка може бути не вартим додаткової вартості розширення FoV. Тільки тому, що двигун підтримує, це не означає, що він "просто запрацює" (хоча це робить його більш імовірним). І лише тому, що всі розрахунки повинні працювати, не означає, що досвід користувача буде позитивним.

З точки зору користувача, головна причина полягає в тому, що в мультиплеєрі більш широкий FOV дає несправедливу перевагу.

Як розробник, зміна поля зору - це невпевнене рішення, яке слід прийняти. Це також повинно бути рішенням, прийнятим на початку гри, в студії з кількома особами важливо, щоб мінімальна частота кадрів і FOV визначалися на ранньому етапі, щоб анімація та відключення оклюзії мали щось суворе. Звичайно, Виключення Оклюзії може базуватися на численних факторах, а не лише на камері.

Я б сказав, що головна причина, по якій я ніколи не дозволяв FOV змінюватися в грі, полягає в тому, що, коли це так, геймплей взагалі сильно змінюється, я також знаю, що це викликає хворобу руху. Це також буде означати, що камера надає більше сенсу масованого хіта на продуктивність, оскільки ігри, як правило, оптимізовані для їх набору FOV.

Однак, припускаючи, що я дозволяю тотальному контролю. Можливо, буде поле, щоб користувач міг змінити конус перегляду на скажімо 70-110 чи щось таке, але я не знаю без тестування цього.

Інші давали купу вагомих причин - естетичні (вирізані сцени, бажаний вигляд та відчуття гри), багатокористувацьке врівноваження, падіння продуктивності за допомогою wieder FOV, але я хочу додати кілька ідей до технічного аспекту:

Особливо технічні питання, ймовірно, більш складні, ніж багато хто з вас думає, оскільки багато обробляється на GraphicsBuffers, і ці буфери зазвичай мають фіксовану роздільну здатність - тому багато деталей графіки залежатиме від перекладу цих буферів на фактичну геометрію . Наприклад, багато сучасних алгоритмів тіней (крім об'ємних тіней) виглядають все більш кричущими та постраждалими з більшим FOV і тим же буферним розміром. Те ж саме стосується будь-якого алгоритму, який виконує відстеження променів, як операції, оскільки FOV ширший, одиничні промені поширюються в більш широку дугу, і більше деталей може загубитися в наближеннях ...