Чи повинні незалежні розробники ігор орієнтуватися на старіше обладнання?

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

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

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

Будь-яке розуміння цього питання буде дуже вдячне.

У цю епоху старий апарат став неправильним. Старе обладнання не потрібно повільно. 6 років - 2009 рік, а DirectX11 вже існував. У нас все ще не так багато нових.

Вам потрібно врахувати дві речі:

• особливості
• потужність

особливості

Це рівень інструкцій, які апаратне забезпечення буде підтримувати, DirectX9,10,11 або OpenGL щось (це залежить від драйверів). І набір інструкцій процесора: SSE4, AVX ..

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

потужність

Це пункт, який повинен масштабуватися на сучасній машині, а не на застарілому верстаті. У високому кінці 2009 року потенційно є GeForce GTX280, це дуже потужно і набагато потужніше, ніж ваш APD AM6 A6-3650 APU або щось подібне.

Потрібно зрозуміти гігантський розрив продуктивності між низьким та високим рівнем сучасної машини. Тому що це значною мірою перевищує розрив у роботі ваших шестирічних машин на високому рівні.

Таким чином, це не розгляд ринку щодо відновлення, це розгляд ринку щодо оригінального бюджету на покупку. І якщо вам потрібно орієнтуватися на сучасні ноутбуки або настільні комп’ютери низького класу, вам все одно доведеться масштабувати масштаби і набагато більше, ніж ви думаєте.

Спробуйте подбати про роздільну здатність, піксельну частоту та пропускну здатність графічної пам'яті. Ви граєте на ці фактори завдяки кількості пропусків екрану, ширині Gbuffer, якщо у вас відкладене затінення (дуже дороге на машинах низького рівня), роздільній здатності ваших текстур та їх кількості, присутній на екрані в будь-який момент часу. Багатство полігону не буде проблемою, якщо ви не орієнтуєтесь на обладнання 2002 року. Складність шейдера ALU / FPU також не буде проблемою, якщо ви не орієнтуєтесь на апаратне забезпечення 2005/2006.

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

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

Як правило, чим ширше обладнання для роботи будь-якої програми, тим більше можливостей вам доведеться продати. Скільки різноманітності ви можете підтримати, багато залежить від гри. Така гра, як Dwarf Fortress, може бути дуже масштабованою, як з точки зору вимог до обробки, так і графіки. FPS з реалістичною фізикою, як Амнезія, не так вже й багато. Моя пропозиція полягала б у тому, щоб написати свою гру так, щоб її можна було запустити на якомога ширший апаратний набір і все-таки дати хороший досвід. Вам не обов’язково потрібно підтримувати все це відразу, але, маючи змогу переналаштувати його на новіші / старіші / просто-звичайні апаратури, легко виплачуватимете дивіденди у міру зростання вашої вентиляторної бази та по мірі прогресування технології.

Є дві речі, які полегшать ваше життя, коли справа стосується того, щоб ваша гра запускалася на широкому наборі пристроїв, і вони мало стосуються віку обладнання, на яке ви орієнтовані (принаймні безпосередньо):

1) Якщо можливо, розділіть бекенд з фронтенду. Якщо частина, яка займається математикою, про те, які фігури роблять що, де має чітко визначений інтерфейс для передачі цієї інформації до тієї частини, яка відображає її на екрані та приймає введення користувача, то ви можете легше відрегулювати її (як правило, інтерфейс ) до нового обладнання, не возившись з іншим. Якщо написано таким чином, багатьом видам ігор можна було б надати фронти, починаючи від найвищої 3d графіки, до анімованих спрайтів на веб-сторінці, до чистих символів тексту ASCII. У цей момент ви можете вибрати, що реалізовувати, виходячи з того, хто, на вашу думку, придбає гру зараз. І ви можете розширитись до нових вихідних схем, оскільки люди виявляють інтерес - без того, щоб возитися з ядром гри.

2) Наскільки можливо, пишіть переносний код. Залежно від конкретної поведінки DirectX 9.3c або будь-якого іншого, ви можете зробити це швидше, але коли ви зрозумієте, що вам слід випустити версію для Android, вам доведеться переробити багато роботи. Вибір бібліотек та мов, які не залежать від одного постачальника, та які відповідають відкритим та чітко визначеним стандартам, серйозно зменшить ваше навантаження в довгостроковій перспективі. Пам'ятайте: написання програми - це зазвичай невелика частина роботи порівняно із підтримкою програми. (Якщо ви не збираєтесь бізнес-модель "запланованого застарівання", але це, швидше за все, не зможе отримати у вас великий фан-бази з часом.)