Зміст конструкторського документа [закрито]

Який мінімальний вміст повинен містити ігровий документ?

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

• Список символів
• Список рівнів із кожним списком наборів рівнів (області, які потребують / заслуговують на особливу увагу)
• Підписний список

Кожен список містить аркуші макетів (або макети символів - спереду, збоку, 3/4), нотатки, нотатки механіки для анімації тощо. Все, що вам потрібно або може знадобитися.

Аркуш оповідань / ігор

• Сценарій та X-таблиці для аніматорів, якщо у вас є історія та діалог / VO
• Проведіть сценарій, в якому описується гра як ніби лінійно прогресуюча (якщо гра є достатньо складною для її необхідності і, природно, лінійна за своєю суттю)
• Механіка ігор на гру / рівень / міні-гру з поставленими цілями, перешкодами, винагородами - ви можете це зробити за рівнем списку і лише великою ідеєю для запуску сценарію

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

Щойно розпочавши вивчення проектних документів, я прийшов до висновку, що ніхто насправді не знає, що йде в них.

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

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

Хороший документ про це - " Інженерія вимог" та творчий процес у індустрії відеоігор .

Розмір та масштаб проектної документації повністю залежать від чисельності команди та обсягу проекту.

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

Під час використання Wiki є кілька рекомендацій, які можуть допомогти:

• Одна сторінка Вікі на систему / персонаж / рівень / ...
• Тримайте Wiki високоорганізованою та структурованою, кожен тип вмісту повинен мати визначений шаблон. Вам потрібно принаймні один WikiNazi, щоб зберегти сайт чистим.
• Охарактеризуйте дизайн коротко та з кульовими точками, дизайн-документ не є місцем для розповідного тексту
• Тримайте сторінки короткими та зосередженими, мета не повинна перевищувати висоту екрана 1-2x.
• Зображення дійсно варті 1000 слів, використовуйте схеми, щоб допомогти зрозуміти свою точку зору.

Мінімальних / максимальних немає. Він повинен містити все необхідне для початку роботи над грою. Нічого більше і нічого менше.

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

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

Мені подобається мати заголовки, пов’язані з тим, що "Art, Sound" та "Storyline" мені потрібно буде рухатись вперед, а також основний дизайн кодування, який я можу дотримуватися, коли кодую двигун.

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