У Discord'і Ігроварів можна часто побачити заявки на співпрацю чи пости про прогрес різних команд у створенні гри. Тому, ми попросили розробників поділитись своїм, як позитивним так і негативним, досвідом участі у різних проєктах. Ми зібрали ці відгуки та оформили їх цьому пості у вигляді гайду.
В результаті, вийшов непоганий широкий огляд того, що може чекати розробника у цьому захопливому світі розробки інді-ігор. Можливо, це допоможе іншим не наступити на чергові граблі чи уникнути підводних каменів.
1. Роздутий масштаб (Scope Creep)
Менше дає більше. Дизайн методом відрізання
По факту, менше фіч - вища якість. Це не означає, що не потрібно придумувати нові ідеї чи покращувати існуючі. Але потрібно знати, коли варто зупинитись. І чим раніше - тим краще. Дуже часто гра стає кращою, якщо подумати не в напрямку розширення, а в напрямі полішингу, перенаправленні ресурсів та часу на те, що працює чи навіть відрізання механік цілком. Scope creep: хто винен і що робити?
"Досконалість досягається не тоді, коли вже нічого додати, а тоді, коли вже нічого відняти" - Антуан де Сент-Екзюпері.
2. Закон Брукса або Міфічний Людино-Місяць
Більше людей не завжди означає швидшу розробку, а іноді навіть і повільнішу
Про цю проблему написано багато статей та книжок Закон Брукса — Вікіпедія. Найчастіше основною причиною, що призводить до такого результату є саме недооцінка "людського фактору" у процесі. Кожен новий член команди - це:
- складніша комунікація та складніший менеджмент - комбінаторний вибух кількості соціальних зв'язків;
- додавання нової людини потребує часу на ознайомлення з вже існуючими напрацюваннями (може витрачати час інших членів команди)
- синхронізація роботи, особливо якщо пересікається відповідальність
3. Ваша гра нікому не цікава... Окрім тих, кому вона цікава
Зрозумійте вашу цільову аудиторію
Часто концепція гри виглядає класно для розробника і він починає розробку "під себе". Але чи означає це, що ця гра ще комусь сподобається? Або чи розуміє він кому ця гра буде цікава? Тому, тут важливо, на етапі прототипування (а може і ще раніше) провести аналіз цільової аудиторії. Можна відштовхуватись від жанру, віку, аудиторії схожих ігор, країни, проблематики гри. Насправді, чим більше показників - тим точніший аналіз. Також, не варто нехтувати play testing`ом на різних етапах розробки, оскільки концепція, і відповідно аудиторія, може змінюватись протягом розробки.
4. Документація та порядок
Документація потрібна, але пам'ятайте про основні аспекти:
- Дотримуйтесь прийнятного масштабу документації для гри. Більше букв та документів - більше неоднозначностей та помилок
- Очевидність та однозначність. Документація повинна бути зрозумілою для всіх учасників проєкту
- Гнучкість. Один документ повинен фокусуватись на конкретному домені/аспекті гри і не вилазити за зону своєї відповідальності. Наприклад, ГДД не має обмежувати технічні рішення, а технічна документація не має вказувати на арт стиль.
- Зручність перегляду, редагування та поширення.
Коментар від TitleChanQWERTY
Ми на Daisen загалом маємо 8 документів: ГДД, Сценарій, Персонажі, Вороги, Зброя, Термінологія, Локація, How-To (3Д). Не пишіть величезний ГДД у якому буде вся гра, а лише основа проєкту. Що в ГДД справді варто розписати - так це геймлуп і механіки гри. Усі інші аспекти рекомендую писати в окремих документах. Також рекомендую мати технічну документацію, особливо, якщо маєте більше ніж 2 людей в команді. У нас в LOYAL Studio є технічна документація для 3д артістів, що містить опис пайлпайна, методів, порад, тощо. Таку ж документацію можна писати для програмістів, аніматорів, левел-дизайнерів тощо. Документи я рекомендую тримати у google docs або схожому клауді. Бачив проєкт, в якому усю документацію запхали у Miro і коли масштаби зросли, то дошка стала занадто масивна і перегружена: лор та історія змішувались з персонажами і концептами. Мінус документації - це підтримка. Потрібно завжди оновлювати інормацію про проєкт та перевіряти відповідність між документами.
5. Управління складністю
Уникайте зайвих ускладнень там, де можна обійтись простішими рішеннями на цьому етапі розробки
Управління складністю - це одне з найскладніших завдань розробки проєкту (якийсь каламбур "простота - не проста"). Не переживайте, з часом слкданісіть сама буде рости і їй не треба допомагати рости швидше. Пам'ятайте - ви робите гру, а не технічнологічне ноу-хау чи ідеальне портфоліо
6. "Правильна" команда
Тут універсального рішення немає, бо для кожної гри/жанру потрібні різні спеціалісти. Але до цього питання не можна підходити безвідповідально. Тобто, просто наявність людини з вільним часом, яка хоче щось поробити - не означає, що її участь буде корисна. В гіршому випадку, ви просто витратите свій та її час намарне. Якщо ж ви дуже хочете разом попрацювати, то вже краще придумати концепцію гри, у якій ваші навички проявляться якнайркаще. Також зважайте на те, що не всі завдання потребують саме учасника команди, оскільки їх можна віддати на фріланс.
7. "Го зробимо проєктик за місяць-два"
Цінуйте свій час
За чашкою кави ваш друг розповідає, що йому наснилась геніальна ідея і втілити її дуже легко та просто. На цьому моменті врубаємо "скепсис" щодо потенціалу ідеї. Ні, я не кажу, що нічого не вийде, але важливо тверезо оцінити ситуацію перед тим, як казати "Поїхали". Дайте цій ідеї час на кристалізацію та аналіз:
- обговоріть потенційні проблеми з дизайном, технічною реалізацію, артом
- проаналізуйте схожі ігри та цільову аудторію (див. 3)
- дайте власну приблизну оцінку необхідного часу на реалізацію (і помножте її на 3 😄)
Коментар від Pan_Enot
Порада: коли ви аплаїтесь до тіми і вам кажуть, що "го зробимо проектик за місяць-два" - не вірте! Розраховуйте що ви робите (якщо вже вписались) свою частину роботи для портфоліо або ассет стору. Навіть якщо на перший погляд тіма має досвід. Прислухайтеся уважніше до редфлагів:
🚩 тіма має багато одночасних проектів,
🚩 з гдд або прописаних тасків "так осьо проект, робим тупо клон"
🚩 особисті "некомфортності", бо можливо (якщо недай боже все вистрілить) вам ще не один рік комунікувати!!
8. Спільне бачення фінального продукту
Зібралися якось геймдзайнер, програміст та артіст робити гру. Геймдзайнер каже: "а давайте зробимо рогалик, вигляд зверху, а ще там є скіли, прокачка і все це у космосі". Програміст відповідає: "та ні, давайте краще ця гра буде у Древньому Римі, і це буде шутер". Ну а артіст тут: "оо, точно - хочу водоспади і щоб ти пересувався за допомогою гаку-кішки". Ви ще трохи поговорили і пішли додому "створювати гру". Але кожен почав робити "свою гру".
Звісно, невеликий шанс того, що ви зробите спільну гру є, але найчастіше невирішені розбіжності приведуть до поступової втрати натхнення і в результаті нічого не вийде. Тому, спробуйте якракраще уявити, яку спільну гру ви разом робите. До того ж, перевіряйте та синхронізйте це бачення час від часу.
До речі, тестуйте "спільну хвилю" на джемах та коротких проєктах, щоб якомога раніше зрозуміти чи вийде вам зробити "спільну гру"
Коментар від Aсhilles Олександр
Я бував у різних командах і головну пролему для себе можу виділити чітко. Не починаєйте робити проєкт, якщо у вас немає конкретного бачення, що повинно бути в грі, а чого ні. Простіше кажучи - всі думки щодо бачення гри повинні бути розписані. Будь-яка деталь може стати дуже важливою. Бо ви уявляєте щось одне - але, потім виявляється інші думають інакше (було в мене таке). Загалом, якщо ви взялись за якийсь проєкт, то розпишіть до нюансів все що повинно бути.
Також, у вас може бути план максимум і план мінімум. План максимум включає всі можливі приколи, необов'язкові механіки, дрім-гейм фічі, які ви зробити краще за цих "геніальних" гейМдизайнерів. Але, не все так просто як може задаватись. Тому пишіть, щоб не прогоріть.
Додам ще, що за скілом треба йти в команди, де є люди, яка хоча б знають як бути не повинно. А хороші ментори, взагалі, на вагу золота.
9. Краще покажи, а не розкажи
Cпочатку зроби щось сам. Щось, що можна показати і тоді, люди охочіше долучаться до чогось вже матеріального, а не просто до ідеї. Особливо ті люди, які щось вміють.
