Саундтрек до The Banner Saga

Так склалось, що в The Banner Saga я грав на телефоні 📱 і можу сказати із впевненістю - це єдина гра на телефоні де я не просто не вимикав звук, а насолоджувався ним. Я не грав, якщо забув навушники або якщо не було змоги грати зі звуком.

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

Так от, сьогодні я поділюсь із вами історією створення саундтрека. Просто не можу її не зберегти в Конспект.

Інтерв’ю-блог
Відео №1 (11:09): https://www.youtube.com/watch?v=d81QR1-4tas

GDC виступ композитора 2014
Відео №2 (1:01:32): https://www.youtube.com/watch?v=msHGWd1y-yg

GDC виступ композитора 2019
Відео №3 (1:03:52): https://www.youtube.com/watch?v=H41jWHvCn90

Інтерв’ю для Полігона: https://www.polygon.com/2014/1/20/5311492/from-epic-to-album-behind-the-scenes-with-the-soundtrack-of-the

Короткий переказ (загалом дуже короткий, але якщо у вас немає часу/змоги дивитись - цього буде достатньо щоб надихнутись): https://dtf.ru/gamedev/105302-kak-ostin-uintori-sozdaval-muzyku-dlya-the-banner-saga

І ще, під шумок, тримайте статтю про роботу із саунд дизайнерами: http://zacharyquarles.com/blog/?p=518

Та список того, що варто вказувати в ТЗ для саунд дизайнерів (однак пам’ятайте, що робота із творчими людьми дуже індивідуальна, для кожного митця треба відпрацьовувати унікальний підхід до співпраці, саме так народжуються шедеври, а не із слідування чіткому і сухому ТЗ)

1. Тип звуку. Чи є звуковий файл ефектом (SFX) або музичним треком (Music).
2. Опис вимог до звуку, його властивостей:
2.1. Тривалість.
2.2. Циклічність (закінчення треку відповідає його початку).
2.3. Додаткові ефекти (згасання, наростання).
2.4. Застосування звуку - в UI, фонова музика, звук пострілу і т.д.
2.5. Опис події, коли звук повинен відтворюватися.
3. Референси. Посилання на звуки, відео та зображення для передачі атмосфери та настрою.
4. Назва файлу. Важливий атрибут, що спростить роботу над грою в подальшому.
5. Пріоритет звуку. Опис того, які звуки будуть програватися в грі найчастіше, і над якими файлами потрібно буде попрацювати в першу чергу.
6. Вартість. Заповнюється саунд дизайнером/композитором. *(взято із телеграм канала “Кодзима гений”, куди в свою чергу це надіслав підписник)

#gamedesign #sounddesign #inspiration #video #saved #GDD #documentation

Написання документації

Знання в статті викладені на основі того, що автор вивчав у вищому навчальному закладі. Мені не довелось навчатись в ВНЗ на геймдизайнера, тому мені було дуже цікаво почитати.
* Спойлер: в більшості тут зрозумілі та очевидні речі, хоча інколи ми про них і забуваємо

Стаття частина №1: https://gamasutra.com/blogs/SimoneCicchetti/20200508/362611/Practical_tips_on_technical_Game_Design_Documentation_Part_1.php

3олоті правила документації:
1. Показуй, а не пиши
Картинка, гіфка, відео, графіки, макети і багато іншого. Це все спростить розуміння документації, дасть більш чітке уявлення і прискорить прочитання
2. Пиши коротко
В документації треба писати короткими реченнями та використовувати загальнозрозумілі слова. Терміни мають бути зрозумілими для всіх в команді
3. Документація не потрібна
Тут автор зазначає, що документація не приносить жодного % до готовності гри.
Я додам свою думку до цього пункта: так, я згоден, якщо взяти всю гру за 100% і старт за 0% то документація дасть +0% до готовності гри. Однак, на мою думку, спираючись на власний досвід, при відсутності правильно написаної документації 100% роботи над грою перетвориться на 150%. Але це лише моя думка і моє спостереження, в геймдеві для всіх працюють різні поради.
4. Ніхто не прочитає 100% вашої документації
Це правило про те, що треба мінімізувати розмір ГДД і привести його в такий формат, щоб він зручно читався і навігація в нього була зрозумілою. В ГДД люди приходять за конкретними відповідями, а це означає, що вони їх мають отримати швидко і в кількох реченнях, а не розмазаними у величезній стіні тексту.

Стаття частина №2: https://gamasutra.com/blogs/SimoneCicchetti/20200528/363643/Practical_tips_on_technical_Game_Design_Documentation_Part_2.php

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

Що тут можна винести для будь-якого інструмента:
1. Bullet points
Завжди наглядно виділяйте ключові пункти, це потім буде прискорювати роботу із докуентацією. Ієрархія, виділення та короткі тези - ідеальне поєднання для легкого читання тексту
2. Таблиці
Якщо текст можна розумно розмістити в таблиці - зробіть це.

#gamedesign #GDD #documentation #general_tips

GDD до гри Dirty Bomb

Це FPS випущений в 2015 році.
Чесно кажучи, я не грав в цю гру, але тепер я маю піти і спробувати.
Не часто можна зустріти у відкритому доступі гдд до випущеної гри (яку все ще підтримують), а особливо такий великий і ґрунтовний гдд (300+ сторінок)
Тепер мені цікаво пограти, оцінити ігрові механіки, їх реалізацію і потім почитати відповідні розділи в гдд

Лінк на гдд: http://db-design.splashdamage.com.s3-eu-west-1.amazonaws.com/dirty_bomb-game_design_document.pdf

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

#gamedesign #GDD #documentation #FPS #saved #F2P #PC #shooter #dirty_bomb

#gamedesign #GDD #documentation #FPS #saved #F2P #PC #shooter #dirty_bomb

Односторінковий дизайн

Стоун Лібранд про односторінковий дизайн (one-page design).
🎥 Відео (1:10:29): https://www.youtube.com/watch?v=exaIF7tqdOE

Які типи дизайн-документації автор намагається замінити:

"Дизайн-біблія" (design Bibles) — великі документи, іноді на сотні сторінок, що містять детальний опис усього в грі: від основної концепції до кожного значка, спрайта чи звукового ефекту.
Плюси:
- Документ містить усю інформацію в одному місці
- Вимагає ретельного мислення, змушує дизайнера глибоко продумувати кожне речення
Мінуси:
- Не масштабується
- Важко постійно оновлювати
- Важко шукати інформацію
- Ніхто не читає (особливо коли це сотні сторінок)

"Дизайн-вікі" (design wiki) — внутрішня вікі, подібна до Wikipedia, з посиланнями, кожне з яких веде на окрему сторінку з параграфом тексту, що описує певний аспект. Особисто я часто використовував Confluence в такому форматі.
Плюси:
- Легкий доступ
- Легше оновлювати, ніж “дизайн-біблію”
- Поділ на частини
- Відстеження змін
Мінуси:
- Потрібна постійна підтримка актуальності всіх посилань
- Приховує зв’язки між елементами дизайну
- Обмежує формат подачі
- Ніхто не читає (знову)

Що ж пропонує автор?
Односторінковий дизайн — зведення дизайну до однієї сторінки, яку можна надрукувати за потреби. Ідея в тому, що немає куди перегортати, прокручувати чи масштабувати. Автор наголошує, що іноді сторінки будуть дуже великими, але суть у тому, щоби включити не весь дизайн, а весь актуальний дизайн для конкретної аудиторії.
Натхнення:
Архітектура та креслення — подібно до креслення будинку, односторінковий дизайн може містити всю інформацію, необхідну для "будівництва".
Створюючи документацію, визначте, хто її читатиме і з якою метою. Різні аудиторії потребують різної інформації.
❗ВАЖЛИВО: Завжди додавайте дату. Це критично важливо, коли документи друкуються — щоб уникнути використання застарілих версій.

Візуальне оформлення:
1. Багато білого простору — не набивайте сторінку текстом. Дозвольте дизайну "дихати", зробіть його привабливим
2. Головна ілюстрація — велике центральне зображення, що є фокусом уваги
3. Виноски (call-outs), вставки, примітки — для надання деталей
4. Опис внизу — загальне пояснення зображеного
5. Маркери (bullet points) — люди читають маркери охочіше, ніж суцільний текст
6. Мінімальне використання зображень — не додавайте зображення "просто так"
7. Колір — використовуйте обережно, можливо лише для акцентів

Типи діаграм, які використовує автор:
- Каркасні діаграми (Wireframes) — показують флоу користувача через екрани чи діалогові вікна
- Схеми рівнів (Level Maps) — візуальне представлення структури рівня або акту гри
- Модульні діаграми (Module Diagrams) — візуалізація окремої системи або міні-гри
- Карти з накладаннями (Map Overlays) — карта як основа для відображення різної інформації
- Діаграми часу і простору (Time and Space Diagrams) — для візуалізації прогресу гравця
- Діаграми зв’язків (Relationship Diagrams) — показують, як різні системи гри пов’язані між собою
- Матриці (Matrixes) — сітки для організації елементів дизайну, що дозволяють бачити всі можливі комбінації
- Блок-схеми (Flowcharts) — допомагають зрозуміти основний цикл гри та взаємодії
- Сторіборди (Storyboards) — показують основні етапи чи модулі гри та їх тривалість

Переваги односторінкового дизайну:
- Легко поширювати в команді
- Синхронізує уявлення
- Документація створена для роботи та ітерацій
- Вимагає розуміння проєкту
- Сприяє лаконічності
- Допомагає побачити зв’язки
- Підсилює вирішення проблем
- Покращує комунікацію
- Люди з більшою ймовірністю прочитають

Проблеми односторінкового дизайну:
- Важко підтримувати актуальність
- Є ризик, що виросте в “дизайн-біблію”
- Підходить не всім: не кожен дизайн можна представити у вигляді однієї сторінки
- Не замінює повноцінну письмову документацію

#gamedesign #documentation #gdd #one_page