Зауважимо: коли арт-директор перевантажений, а художники інтерпретують стиль по-своєму, одна помилка в текстурі може розійтися по сотні асетів. Без єдиного документа кожен приймає рішення на око — результат: розбіжність у якості, переробки, зриви термінів. На одному проєкті ми бачили, як художники використовували три різні texel density для пропсів однієї локації — довелося перетекстурувати 40% асетів. Це коштувало двох тижнів роботи та $8 000 бюджету.
Style bible — не просто набір правил, а живий документ, який замінює арт-директора в його відсутність. Він включає не лише технічні параметри (PBR-діапазони, полігонаж, naming convention), але й історію рішень, антиприклади та інструкції з оновлення. Такий документ скорочує час онбордингу нових художників на 50% (у 2 рази швидше порівняно з відсутністю style bible) і знижує відсоток браку в аутсорс-поставках до 5%. Замовте консультацію, якщо хочете оцінити ефективність для свого проєкту.
Як зрозуміти, що проєкту потрібна біблія стилю?
Якщо асети з одного набору виглядають як із різних ігор, або художники ставлять одні й ті ж питання арт-директору — пора. Інша ознака: аутсорс-студії надсилають текстури з невірними PBR-значеннями, і їх доводиться переробляти. У таких випадках style bible окупається після першого ж онбордингу нового співробітника або поставки від підрядника. Економія на аутсорс-переробках може досягати 150 000–300 000 ₽ на одному проєкті.
Чому біблія стилю економить бюджет?
Одна помилка в texel density може призвести до перетекстурування 100+ асетів. При середній вартості переробки 4 000 ₽ за асет — це 400 000 ₽ тільки на одній помилці. Style bible виключає такі ситуації. Наші замовники відзначають, що економія на аутсорс-переробках досягає 60%, а час узгодження арт-асетів скорочується на 70%.
Типові проблеми, які вирішує style bible
Перша проблема — розкид PBR-параметрів. Художники часто використовують невірні діапазони Roughness і Metalness — наприклад, металева деталь виходить матовою, а дерево — блискучим. У bible прописується таблиця PBR Value Guide:
| Матеріал | Albedo HSV (Hue) | Roughness | Metalness |
|---|---|---|---|
| Іржавий метал | 20–40, 0.2–0.5, 0.3–0.6 | 0.6–0.9 | 0.0–0.3 |
| Гладкий пластик | 0–360, 0.1–0.3, 0.7–1.0 | 0.1–0.3 | 0.0 |
| Шкіра | 10–30, 0.3–0.5, 0.3–0.5 | 0.5–0.8 | 0.0 |
Друга проблема — неузгоджений texel density. Якщо один художник робить пропси з щільністю 1024 px/m, а інший — 512 px/m, загальна сцена виглядає нерівно. Bible фіксує єдину щільність для кожної категорії: персонажі 2048 px/m, пропси 1024 px/m, оточення 512 px/m.
Третя проблема — некоректний naming convention. Файли виду model_v2_final_2.fbx не дозволяють швидко знайти асет. Bible задає шаблон: AssetType_Category_Variant_Version, наприклад Prop_Chair_Wooden_v01.fbx.
Що входить у структуру повноцінної style bible
Vision statement
Один-два абзаци — як виглядає гра, якщо описати її візуальний образ для людини, яка її не бачила. Не жанр, не настрій — конкретні образи. «Постапокаліпсис через 200 років: природа повернула міста, іржа вкрита мохом, метал матовий з темним оксидом, світло завжди крізь листя або пил». Це якір, до якого повертаються при будь-якому спірному рішенні.
Колірна система з правилами застосування
Не просто hex-коди — ієрархія: домінантні кольори (60%), додаткові (30%), акцентні (10%). Для 3D — таблиця допустимих діапазонів Albedo для кожного матеріального класу. Це виключає фізично некоректні текстури, які ламають освітлення.
Типографіка та шрифтова система
Primary/secondary шрифти, правила масштабування, відступи. Для ігор — окремо правила для дієгетичних написів (написи у світі гри) та UI-типографіки.
Правила для кожної арт-дисципліни
3D-моделювання (naming convention для мешів, UV layout правила, максимальний полігонаж за категоріями), текстурування (texel density за категоріями асетів, роздільна здатність текстурних атласів, обов'язкові карти — BaseColor, Normal, ORM або окремі R/M/AO), ригінг (naming convention кісток, IK/FK стратегія, BlendShape імена), анімація (стиль кривих, правила timing та spacing під візуальний стиль).
VFX правила
Particle system: діапазони size, lifetime, швидкостей — все під візуальний стиль. Якщо гра стилізована — VFX не повинен бути реалістичним, навіть якщо технічно це можливо.
Антиприклади
Це найцінніше. Показуємо готові асети, які були зроблені «не так», і пояснюємо чому. Це навчає краще за будь-яке правило. Приклад: Metalness = 1.0 для іржавого металу — фізично некоректно, як пояснює документація Physically Based Rendering. Правильно: використовувати градієнтну маску Metalness від 1.0 (чистий метал) до 0.0 (іржа).
Як часто оновлювати style bible?
Style bible не повинна бути статичною. Найкраща практика — версіонування документа (v1.0, v1.1 і т.д.) з changelog: що змінилося, чому, які асети потрібно оновити відповідно до нових правил. Документ без changelog — це документ, який буде суперечити сам собі через півроку. Процес оновлення: хто має право вносити зміни, як це узгоджується, як повідомляється команда — це теж частина документа. Ми рекомендуємо переглядати bible після кожного великого спринту. Типова помилка новачків — відсутність vision statement. Без нього анімація може суперечити настрою. Рішення: включіть 1-2 абзаци з образами. Чисті PBR-діапазони без антиприкладів змушують художників повторювати старі помилки — додайте 3-5 антиприкладів із пілоту. Якщо немає changelog, через півроку документ стає неактуальним — версіонуйте та ведіть журнал змін.
Як ми створюємо біблію стилю
- Аналіз поточних матеріалів. Пілотуємо 3-5 асетів із проєкту, фіксуємо розбіжності з очікуваним стилем.
- Проєктування структури. Визначаємо список дисциплін, глибину опрацювання, формат документа.
- Наповнення технічної частини. Прописуємо параметри для кожної дисципліни: полігонаж, texel density, PBR-діапазони, naming convention.
- Створення антиприкладів. Розбираємо типові помилки з нашого досвіду або з проєкту замовника.
- Тестування на пілотних асетах. Передаємо документ художнику, він створює асет за bible — перевіряємо, що результат відповідає очікуванням.
- Фіналізація та деплой. Збираємо документ в обраному інструменті (Figma, Notion або веб), налаштовуємо навігацію та пошук.
Орієнтовні терміни
| Масштаб проєкту | Склад | Терміни |
|---|---|---|
| Indie / невелика команда | 15–25 сторінок, основні дисципліни | 2–3 тижні |
| AA-проєкт / 15–30 осіб | 40–70 сторінок, всі дисципліни + антиприклади | 5–8 тижнів |
| Великий проєкт / аутсорс-орієнтований | 80–120+ сторінок, повна система + оновлювана версія | 3–5 місяців |
Вартість розраховується індивідуально. Якщо у проєкту вже є часткова документація — починаємо з аудиту наявних матеріалів. Ми маємо понад 5 років досвіду в геймдеві, реалізували 30+ проєктів, і гарантуємо якість документації. Замовте створення біблії стилю для вашого проєкту — ми допоможемо визначити обсяг робіт. Отримайте консультацію щодо структури документа: надішліть поточні арт-асети та опис стилю — оцінимо, що потрібно додати або виправити.