Для дійсного детального пояснення рекомендую прочитати одну і єдину біблійну архітектуру Game Engine від Джейсона Грегорі. Я думаю, це найповніша робота з цієї теми з моменту її опублікування. Він не тільки обробляє частину C ++, але також і важливий для кожного програміста ігрового двигуна теорія / архітектура, що стоїть позаду. Це хороша відправна точка незалежно від мови. Щоб отримати огляд, про що ми говоримо, це зображення з книги
Дозвольте спробувати відповісти на питання.
Що б ви не написали, це буде код :-) після багаторічного досвіду напишіть, що вам потрібно і як вам це потрібно, або використовуйте те, що забезпечує вам те, що вам потрібно.
Термін " двигун" і " фреймворк" походять від архітектури програмного забезпечення разом з іншими термінами. Тож почнемо з основних термінів, і не дозволяє рухатися вгору.
Бібліотека
Типові приклади: математична бібліотека, що забезпечує всі основні типи та функції для математичних обчислень (вектор, матриця, ...) або бібліотека зображень (jpeg або png), що забезпечує функціональність для запису jpeg або png зображень
У Unity 3D Math - це математична бібліотека.
Теорія: бібліотека надає спеціальні функції навколо теми (наприклад, математика) І викликається програмістом на вимогу .
Деякий попередній перегляд: можуть бути бібліотеки, що мають рамки, які також є бібліотекою фреймворків.
Рамка
Теорія: Рамка вводить інверсію управління . Це означає, що розробник більшість часу не викликає рамкові методи, але фреймворк називає код розробника. Винятки становлять те, коли вам доведеться інтегрувати бібліотеку фреймворків у свій код і запускати рамку. Рамкова бібліотека забезпечує всі методи та функції та інтерфейси для фреймворку із спеціальним використанням. Тож рамки можуть бути в бібліотеці.
Типовий приклад: MonoBehaviour Unity 3D надає такі методи, як Awake, Start, OnUpdate. Розробник реалізує ці методи, а потім ці методи викликаються рамкою (управління об'єктом ігор) (це інверсія управління) . Те саме з методами OnCollisionEnter, OnCollisionExit. Вони є тим самим монобієвіром, але, сподіваюся, їх називають фізичні рамки.
Попередній перегляд: Engine, Runtime, Editor, SDK
Оскільки термін "двигун" завжди був неясним і все ще є (і це не стає кращим з подальшими технологічними розробками), деякі попередні пояснення.
Термін "двигун" використовується для кількох речей, і не можна однозначно сказати, який з них правильний. Ще в 2004 році, коли я вперше зіткнувся з написанням ігрових двигунів, теж було невиразно. У вас був ігровий движок в сенсі якогось коду, завантажуючи заздалегідь задані дані, і дозволяв вам грати в гру. Оскільки він завантажує заздалегідь задані дані, їх називали двигунами, керованими даними. Ви збираєте їх один раз, і зовнішні дані могли бути різними іграми без їх перекомпіляції. У якийсь момент це було так само, як і час виконання.
Редактор зрозумілий. Це дозволяє визначити заздалегідь задані дані, завантажені двигуном / час виконання.
Двигун з редактором називався SDK (наприклад, Hammer SDK).
Тоді були / присвячені двигуни. Двигун phyiscs, рендеринг, звуковий двигун, двигун управління ігровими об'єктами, мережевий двигун, ....
На мою особисту думку, це не двигуни (особливо рендерінг НЕ ігровий движок, оскільки він робить лише рендерінг). Коли я переглядаю ігровий движок google, результати містять 90% чистого візуалізації, які не є ігровими двигунами. Я б назвав усі бібліотеки, але оскільки вони можуть завантажувати заздалегідь задані дані, вони б відповідали терміну, керованому даними.
Остання коротка зауваження, перш ніж ми розберемося в деталях: я успішно закінчила ступінь магістра з інформатики. Моя магістерська робота розглядала тему "як розробити ядро ігрового двигуна". Значить частину коду, яка поєднує всі інші двигуни, чи керує ігровим об'єктом, ігровим циклом тощо.
Я опублікував магістерську роботу як (коротку) книгу. Єдиний коментар Amazon від покупця / читача (через кілька років): це не про ігровий движок. Оскільки я закінчив успішно і тому захистив дисертацію проти 3 досвідчених програмістів (2 з них присвячені іграм та інтерактивним програмам), я думаю, що я написав ігровий движок.
Редактор
Легко: дозволяє визначати дані у форматі, який потребують інші частини, і тому виключає вимогу писати ці файли вручну або використовувати зовнішні інструменти для їх створення.
Це те, що робить редактор Unity 3D.
Час виконання
Цей термін часто використовується однаково з двигуном (що може бути правильним чи неправильним).
Виконання виконує згенеровані дані та робить те, що має відношення до даних. Наприклад, показати вам гру і дозволити вам грати. Він не створює жодних даних (за винятком можливо збереження ігор) у тому сенсі, що ви не можете змінювати саму гру.
Веб-програвач Unity є / був під час виконання дозволу грати в ігри Unity у веб-браузері.
Ви можете завантажувати та виконувати декілька різних ігор за однаковий час виконання.
У випадку з сценарієм API Unity 3D існує розріз між функціональністю, яка буде працювати в грі, та функціоналом, який працюватиме лише в редакторі.
SDK
Цей термін часто також називають рамковим .
Тоді SDK представляв собою набір інструментів, таких як редактор, IDE (інтегрована середовище для розробників) для програмістів, експортерів форматів даних та часу виконання / двигуна.
Таким чином, SDK / фреймворк надає вам заздалегідь заданий робочий процес та утиліти та показує вам (добре розроблений) спосіб, як ви можете (легко) створити гру.
В основному, двигун Unity 3D був би невірним, оскільки він більше підходив би до напрямку SDK. Але оскільки Єдність - ще більше, потрібне нове слово / визначення, щоб відповідати тому, що воно є.
У будь-якому випадку, щоб ввести інший термін, SDK / фреймворк надає вам заздалегідь визначений конвеєр розвитку ігор (не тільки конвеєр активів, але, можливо, як Unity, конвеєр для активів, логіки, побудови, розгортання тощо).
Двигун
сарказм на Використовується для всього, оскільки всі хочуть бути крутими, пишучи не лише бібліотеку, рамки чи ігри, але краще писати повноцінний механізм. сарказм вимкнений
Давайте спустимо це:
Двигун
- це фрагмент коду / програмного забезпечення
- він спрямований на повторне використання в декількох проектах (ви також можете написати ігровий движок лише для однієї гри)
- для повторного використання ігровий движок відокремлює частину багаторазового використання від конкретної ігрової частини
- для повторного використання (залежно від способу повторного використання) існують різні смаки, такі як двигун, керований даними, що завантажує зовнішні дані
Двигун може складатися з декількох інших двигунів (оскільки все сьогодні називається двигуном). Ігровий двигун може включати
- движок візуалізації, що робить рендерінг (ПРОТИ: бог, чорт, пекло: код робить лише рендерінг НЕ ігровий движок)
- фізичний двигун, що займається фізикою (це фізичний двигун, а не ігровий двигун)
- AI двигун, що обробляє речі AI (це AI двигун, а не ігровий двигун)
- мережевий двигун (наприклад, RakNet), що робить мережеві речі (це мережевий движок, а не ігровий движок)
- аудіо-двигун, який робить аудіо речі (це аудіо-движок, а не ігровий движок)
Приклад програми, що базується на основному двигуні, що забезпечує модуль, що базується на плагінах, щоб чіпляти все разом у моделі управління об'єктом ігрових об'єктів. Кожен піддінжейн (візуалізація аудіо) - це модуль, який додається до ігрового двигуна в якості підключення. Кожен компонент може бути частиною піддінжету / модуля. А управління (ігровий об'єкт на основі компонентів) є сполучною ланкою між відокремленими модулями.
Найближчий визначення для Game Engine
Двигун гри є частиною вихідного коду вашої гри , що забезпечує всю функціональність , яка призначена для повторного використання accross декількох ігор , і нехай вам код і виконати свою гру. Тому він чітко поєднує всі інші частини коду (візуалізація, аудіо, фізика, управління ігровими об'єктами, мережа), які є або бібліотеками, рамками або спеціальними двигунами (візуалізація, фізика, ...).
Ігровий двигун - безлад посередині.