Що слід враховувати при оцінці бібліотек, двигунів та рамок для створення гри?

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

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

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

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

1. Складіть список особливостей, які вас цікавлять, тобто підтримка 2D / 3D, освітлення, фізика, мова, яку ви добре знаєте, тощо.
2. Ранжуйте їх на основі важливості для вас, виходячи з вашого поточного проекту.
3. Дослідіть свої варіанти та для кожного варіанту спробуйте класифікувати їхні функції підтримки на основі того, наскільки вони узгоджуються з цілями вашого проекту.
4. Використовуйте той, який найкраще відповідає вашим цілям. Крім того, ви можете обрати кілька кращих і дати їм тест-драйв. Реалізуйте просту функцію своєї гри і подивіться, яка з них вам більше подобається.

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

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

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

Якщо ви збираєтеся бути лише для Windows, то бібліотеки DirectX і C # на базі C # є вагомими кандидатами. Якщо ви хочете бути багатоплатформою, тоді ви хочете переглянути бібліотеки на базі OpenGL та C / C ++ або Flash, якщо ваша гра 2D і ви можете дозволити собі інструменти Adobe. Як і ваша платформа, ваша мова програмування впливатиме на наявні ваші бібліотеки. Програма, написана на C ++, буде важко викликати бібліотеку Java.

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

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

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

• Чи робить бібліотека те, що потрібно?
• Це спеціалізовано робити те, що потрібно? Скільки клопоту прикріплене до нього?
• Як він сконструйований? Ви хочете блювати, коли бачите? Якщо так, то, мабуть, це не найкращий вибір як для вашого здоров'я, так і для здорового здоров’я.
• Чи достатньо вона гнучка для ваших потреб? Непогано помітити, що бібліотека не працює після того, як ви вже написали половину свого коду з нею.
• Яким майбутнім доказом є бібліотека? Чи розробник додає функції з часом? Він фіксує речі? Він вдосконалює справи? Це може дуже змінити, якщо буде ймовірно, що розвиток вашої гри займе кілька років. Не так важливо для невеликих проектів, які ви матимете через місяць.
• Чи підходить розмір? Для невеликих проектів це може мати велике значення, чи повинен програвач завантажувати 20 Мб або 200 МБ. Більш масштабні проекти, ймовірно, досить великі, що розмір проміжного програмного забезпечення має незначну роль.

Окрім ігрових особливостей, які коментували люди, слід також розглянути деякі загальні питання.

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

Короткий чіт-лист для оцінки бібліотек, рамок, двигунів і SDK та вибору найкращих

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

Тому перед тим, як розпочати оцінювання, вам слід зрозуміти, який сценарій ви маєте та які вимоги маєте / хочете мати, тому що це питання, на які слід відповісти в оцінці.

Сценарій визначає, звідки беруться вимоги (хто вирішує, що таке вимога, а що ні).

Типовими сценаріями є:

Найбільш хоббі сценарій проекту

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

Невідповідні вимоги полягають у тому, що ви, можливо, захочете вивчити щось конкретне (мову, певну рамку / двигун)

Сценарій студента

Вимоги можуть виходити від вашого вчителя. Типові вимоги до мене в цьому випадку: гра повинна мати деякі фізичні елементи та підтримку багатокористувацької мережі. Або це має бути написано на C ++. Тож оцінювання стає простим. Ви шукаєте ігровий движок, який дозволяє вводити код у c ++ і вже може включати мережевий та фізичний двигун.

Більш зла (реальне життя) вимога: все потрібно писати з нуля (але використання бібліотек дозволено). Тому редактор не дозволений (наприклад, Unity3D). Тож ви шукаєте не двигуни / sdks, а бібліотеки.

Сценарій гри в Інді

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

Чи дозволяє це ігри Java, ігри HTML5, ....)

Чи вимагає від вас включення конкретних бібліотек (якщо так, то якими мовами є ці бібліотеки)

Google Playstore вимагатиме від вас написати свою гру як гру для Android, Apple AppStore вимагатиме від вас написати свою гру як додаток для iOS. Або у вас є вимога вибрати багатоплатформовий двигун.

Професійний сценарій

У вас не тільки магазин, який надає вимоги, але, швидше за все, видавець або клієнт, який має власні зображення вимог. У цьому сценарії ви також матимете більшу команду найманих розробників. Залежно від їх набору навичок виникають нові вимоги (наші програмісти можуть писати лише c ++, тому ми не можемо використовувати чистий ігровий движок Java / Android, не потребуючи в них часу (багато), щоб дізнатися щось нове).

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

Як я вирішую, які є мої вимоги, коли я хобі чи інді, і ніхто більше мені не каже?

Задайте собі питання щодо своїх цілей та своєї гри?

• Якою повинна бути моя гра? мобільний, ПК, веб (html / Js), які контролери я буду використовувати (сенсорний екран, гіроскоп, ігровий майданчик)

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

• Який вимір мого проекту: розлючені птахи чи скайрім? Злі птахи можна зробити майже в кожному інструменті, а skyrim буде обмежений високопродуктивними інструментами з (припускається) роками додаткової настройки (високопродуктивні двигуни на місцевості непрості)

• Моя єдина мета лише зробити гру? так? Ідеально, ви можете використовувати деякі дуже просунуті речі, такі як Unity, Unreal, ... маючи зручний редактор та велике співтовариство, яке надасть вам підручники та відповідає на ваші запитання. Це знімає тягар виконання завдань низького рівня, таких як завантаження сітки, реалізація власних математичних функцій, ....

• Моя мета дізнатися щось конкретне? так? чого ти хочеш навчитися?

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

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

Відповідаючи на подібні запитання, ви підходите до вимог. Оцінка - це пошук списку інструментів та ТЕСТУВАННЯ (не лише читання домашньої сторінки), що інструмент може надавати чи не може.

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

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

Іди сюди .

Незважаючи на кількість ігрових двигунів, у вас насправді не так багато варіантів.

1. ліцензійні обмеження. Деякі двигуни будуть перешкоджати вашій можливості випустити ваш продукт без попередньої сплати великих ліцензійних платежів, наприклад Unity , який використовується для стягнення додаткової плати за компіляцію в iOS, наприклад (це змінилося в 2016 році )
2. платформи. Ви не хочете орієнтуватися на кілька платформ? Котрий?
3. 2D або 3D? Деякі двигуни обслуговують 2D.
4. Потрібна фізика? Деякі двигуни забезпечують фізику
5. FPS, RTS? Можливо, буде розумно використовувати двигун, який спеціалізується на створеному вами ігровому типі.
6. Очевидно, ви хочете працювати на своїй улюбленій мові. Вам не подобається C? Тоді не використовуйте Allegro!
7. Ви величезні шаблони дизайну, вентилятор OOP? Добре відомі OGRE "зловживають" зразками
8. Активний розвиток? Вам слід врахувати компроміс між наявністю функцій крайового кровотоку (DX11 / OGL 4) та стабільністю двигуна, розробка якого скоротилася пару років тому
9. База користувачів? Велика база користувачів зазвичай означає кращі форуми, тому простіше відповідати на ваші запитання