Дизайн ігрових механізмів та даних, керованих даними

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

Однією із статей є дизайн, керований даними, написаний Кайлом Вілсоном. Як він описав, мені здається, що код програми (тобто код для керування ресурсами, такими як пам'ять, мережа ...), і логічний код гри повинні бути розділені, а логічний код гри повинен керуватися зовнішніми джерелами даних. На даний момент я можу уявити, що розробник написав би якийсь редактор ігор, який приймає зовнішні дані про ігрові об'єкти (такі як інформація про персонажів, інформацію про зброю, інформацію про карту ...). Сценарій проектуватиметься за спеціальною мовою / інструментом, написаним програмістом, щоб дизайнер ігор створив взаємодію між ігровими об'єктами. Дизайнер ігор буде або використовувати існуючу / власну мову сценаріїв для написання сценарію для гри, або інструмент перетягування для створення ігрового світу. Прикладом інструментального підходу, про який я можу придумати, є «World Editor», який зазвичай постачається разом із іграми Bliizard.

Однак інша стаття проти використання дизайну, керованого даними, «Справа проти даних» . Автор пропонує не допускати ігрового дизайну, керованого даними, оскільки на розробку гри знадобиться більше часу, оскільки дизайнер ігор несе тягар програмування. Натомість з'явиться ігровий програміст, який програмує гру вільно з ескізного дизайну, і перевіряється ігровим дизайнером після закінчення ігрового програмування. Він називає це керованим програмістом. Те, що я вважаю цим методом, схоже на те, як я раніше робив: Логіка гри - це саме додаток, як і призначене до вищезгаданої ідеї, додаток є редактором ігор, а власне гра розроблена на основі цього інструменту.

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

Отже, після всього цього я просто хочу перевірити, чи є якісь недоліки в моєму розумінні щодо цих ідей (керовані даними, привід програміста, сценарії тощо)?

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

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

Вам не доведеться будувати складні "архітектури, що керуються компонентами" (як це дивно в наші дні). Введення констант для підстроювання фізики (сила тяжіння, коефіцієнти відновлення) у текстовому файлі керується даними. Сценарії (в Луа або щось інше) керуються даними. Опис даних про рівень у XML. Що-небудь подібне.

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

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

Для ваших конкретних питань:

Це правда, яким повинен бути ігровий движок?

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

Отже, після всього цього я просто хочу перевірити, чи є якісь недоліки в моєму розумінні щодо цих ідей (керовані даними, привід програміста, сценарії тощо)?

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

Як автор другого допису, я хотів би уточнити кілька моментів.

1. Як запропонував Джош Петрі, структурування вашого коду для використання даних замість просто жорсткого кодування все завжди виграє. Я не пропонував іншого. Я вказував, що натискати на дизайнера все - це не дуже гарна ідея. Термін "дизайн, керований даними" означає різні речі для різних людей, тому, певно, я мав би бути більш конкретним, коли писав оригінальну статтю.
2. У кожному місці, де я працював, ми створюємо структури даних, які можна налаштувати в двигуні. Щоб внести зміни, нам не доведеться перекомпілювати гру. Ми можемо динамічно змінювати номер під час виконання. Структури даних часто зберігаються в коді, але залежно від того, хто їх змінює, вони легко завантажуються з "файлу даних".
3. Більшість середовищ розробки підтримують певну форму редагування та продовження або перезавантаження модулів для C / C ++.
4. У більшості студій розвитку ігор є геймплейні програмісти. Їх роботою часто є робота з дизайнером у створенні веселого досвіду. Їх головне питання - це не технічні проблеми, а швидше майстерність із коду. Я багато років працював геймплейним програмістом, і мені здається, що це цікавіше, ніж просто намагатися вирішити технічні завдання. Мої обов'язки різноманітні, але я вважаю, що моя робота є найбільш повною, коли я відповідаю за впровадження і працюю з дизайнерами над тим, щоб зробити щось круте. Проблема дизайнерів, що кодують чи сценаріїв, полягає в тому, що програмістам часто доводиться розбирати помилки, що є однією з найменш цікавих речей, яку ви можете зробити як програміст.
5. Те, що найкраще працює для студії, залежить від гри. Якщо вам давно потрібно грати, і ви хочете подарувати свої ігрові ноги модному співтовариству та створити щось величезне за обсягом, то робити гру, повністю керовану даними, має сенс. Багато ігор не мають цієї мети. Їм доведеться за два роки викрити нову гру, і якщо у них не буде хіт-франшиза, це, мабуть, інший тип гри, ніж їхня попередня робота
6. Те, що робить "дизайнер", може змінюватись від студії до студії. Я чув про студію розробки, яка наймає геймплейних програмістів з інших студій, називає їх дизайнерами та пропонує їм сценарій ігрової поведінки. Це вирішує проблему наявності людей, які не навчаються програмуванню кодування / сценаріїв.
7. Завжди має бути розмежування між логічним кодом гри та кодом двигуна. Крім того, ви зазвичай хочете мати якийсь візуальний редактор для розміщення об'єктів. Я ніколи не працював у студії, де ворожі місця жорстко закодовані. Вони розміщуються в редакторі. Дозвольте запропонувати приклад того, про що я говорю. Скажімо, дизайнер придумує ворога. Чи дизайнер, ніж сценарій поведінки цього нового типу ворога? Це я вважаю дизайном, керованим даними (з точки зору того, що про нього писав Тім Мосс). У тому, як я пропоную, програміст працює з дизайнером, вони роблять веселого ворога, можливо, з налаштованими параметрами, і тоді вони розміщуються на рівні.
8. Рідний код, написаний програмістом, виконуватиметься швидше під час виконання, ніж сценарій, написаний програмістом, який виконуватиметься швидше, ніж сценарій, написаний кимось з менш технічними кмітливістю. Ця ефективність може бути або не важливою, залежно від того, який тип гри ви робите та чим займаєтесь, але варто щось врахувати.
9. Ви можете ділитися ігровим кодом між іграми незалежно від обраного способу. Я не дуже впевнений, що ти досягаєш з цього моменту. Навіть якщо ви не використовуєте мову сценаріїв або візуальний інструмент, щоб визначити деяку поведінку, вам слід створити свій ігровий код на багаторазові компоненти. Завжди знайдуться речі, непридатні до вашої наступної гри, але кожне місце, де я коли-небудь працював, коли ми починаємо наступну гру, ми починаємо з кодової бази з попередньої - навіть якщо це не продовження. Потім ми зберігаємо речі, які мають сенс, і видаляємо конкретні ігри.

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

Також в якості побічної записки мій запис у блозі - 5 років. Здається, що набагато більше студій рухається до мов написання сценаріїв і нічого такого в наші дні, але створюють зрілі інструменти для налагодження їх, що було моєю основною скаргою. Коли я писав це, я не думаю, що існував Unreal Kismet, який я не використовував, але, схоже, вони намагаються спростити сценарій, і, мабуть, він має налагоджувач. (Не маю уявлення, наскільки добре це працює)

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

Ви повинні подивитися BitSquid Tech Engine . Він будується за допомогою концепцій DOD. Блог Нікласа Фрікгольма дуже цікавий. Існує багато статей про те, як розроблений цей двигун.

На GDC 2011 компанія Niklas виступила з доповіддю про Data Driven Renderer .