Вступ
Ми часто стикаємося з ситуацією, коли новий художник приходить в команду і запитує: «У вас полігональний бюджет на персонажа — скільки?» Тімлід відповідає: «Ну, приблизно від 5 до 15 тисяч, залежить від важливості». Це не стандарт. Це усна домовленість, яку кожен розуміє по-своєму, і яка ламається при кожному новому співробітнику або підряднику. Без чітко задокументованих стандартів команда витрачає до 30% часу на переробку ассетів. Наш досвід показує: після впровадження Tech Art Bible кількість переробок знижується в 3 рази в порівнянні з усними домовленостями. Економія бюджету на арт-продакшн досягає 30%. За понад 5 років роботи ми створили Tech Art Bible для десятків проектів — від мобільних ігор до AAA-консолей. Документ фіксує числа, формати та процедури, виключаючи різночитання. Автоматизовані перевірки в пайплайні працюють в 5 разів швидше ручного рев'ю та скорочують кількість артефактів на 40%. Отримайте консультацію з впровадження стандартів у ваш пайплайн.
Чому «очевидні» стандарти потрібно документувати?
Розрив між тим, що вважається «само собою зрозумілим» всередині команди, і тим, що реально роблять художники — величезний. Приклади реальних розбіжностей:
-
Текстурні роздільності: один художник робить 2K під фонові об'єкти, інший — 4K. У VRAM це одразу видно — профілювання показує
Texture Memory800 МБ замість планових 400. А в документі написано тільки «використовуй розумні роздільності». -
Іменування:
hero_body_d.png,Hero_Body_Albedo.png,character_1_diffuse_final.png— три текстури одного типу від трьох художників в одному проекті.AssetDatabase.FindAssetsпо паттерну не працює, автоматичний імпорт по суфіксу не працює, CI-перевірки на naming convention не працюють. -
Pivot points в FBX: один Blender-художник експортує з півотом в геометричному центрі, інший — в Origin світу. Розробник отримує об'єкт, який при
transform.Rotate()обертається навколо несподіваної точки.
Що входить в Tech Art Bible
Полігональні бюджети
Таблиця за категоріями об'єктів з розбивкою по платформам:
| Категорія | PC (LOD0) | Mobile (LOD0) | Mobile (LOD1) |
|---|---|---|---|
| Головний персонаж | 10 000–15 000 | 5 000–8 000 | 1 500–3 000 |
| NPC другого плану | 5 000–8 000 | 2 000–4 000 | 500–1 000 |
| Великий prop | 3 000–5 000 | 1 000–2 000 | 200–500 |
| Дрібний prop | 500–1 500 | 200–500 | 50–150 |
Текстурні стандарти
Роздільності за категоріями, формати (PNG для вихідників, TGA для normal maps при імпорті в Unity — не PNG, BC7 як цільовий формат компресії для PC, ASTC для Android/iOS), обов'язкові канали (Albedo, Normal, Metallic/Roughness, AO — окремо або упаковані).
Система іменування
Конвенція з прикладами. Для текстур — {object}_{part}_{type}_{resolution}.ext, наприклад hero_body_albedo_2k.png. Для мешів — {category}_{name}_{LOD}.fbx. Документуємо не тільки правило, але й чому воно таке — це знижує опір при впровадженні.
UV-стандарти
Tile розмір, допустиме UV-overlapping для lightmap UV (тільки LOD0, UV channel 2), вимоги по seam placement (не на видних кромках, не на суглобах).
Процедури експорту з кожного інструменту
Blender FBX export settings (Apply Transform, Forward axis, Units), Substance Painter export template для Unity (саме з якими каналами в які слоти), Maya export checklist. Дотримання процедур скорочує кількість помилок при імпорті в 3 рази в порівнянні з ad-hoc налаштуваннями.
Приклад чек-листа експорту з Blender
- Apply Transform (Scale = 1, Rotation = 0)
- Forward axis = -Z, Up axis = Y
- Units = Centimeters (імпорт в Unity з множником 1)
- Mesh Smooth = Edge, не Face
- Експортувати тільки видимі об'єкти
Як розробляється Tech Art Bible для вашого проекту?
Починаємо з аудиту існуючих ассетів: що вже використовується в проекті, які де-факто застосовувані значення. Документ повинен відображати реальність + покращення, а не ідеальний стандарт з нуля — інакше команда його проігнорує.
Інтерв'ю з художниками: які питання задають найчастіше, де виникають конфлікти при рев'ю ассетів, що доводиться переробляти. Це найкраще джерело для визначення пріоритетів в документі.
Формат: Confluence або Notion — інтерактивні, підтримують вкладені таблиці та скріншоти. Не PDF — PDF ніхто не читає через півроку. Структура: зміст з якірними посиланнями, «Quick Reference» на першій сторінці (найчастіше потрібні дані), повні розділи нижче.
Версіонування документа — дата останнього оновлення та changelog. Стандарт без версії втрачає довіру: «а це актуально для нашої поточної платформи?»
Як автоматизувати дотримання стандартів?
Документ не працює без автоматичних перевірок. Unity Editor-скрипти для валідації:
- Перевірка імпортованих текстур на відповідність naming convention через
AssetPostprocessor.OnPreprocessTexture() - Перевірка max resolution при імпорті: якщо текстура > 4096 для категорії background — Warning в консолі
- Mesh validator через
AssetPostprocessor.OnPostprocessModel(): перевірка polycount по імені категорії з імені файлу
Це не заміна документу, але зворотний зв'язок при порушенні стандартів в реальному часі — до code review. Замовте інтеграцію валідаторів у ваш проект — гарантуємо зниження часу на рев'ю ассетів. Докладніше про підходи до автоматизації читайте в документації AssetPostprocessor.
Строки впровадження
| Масштаб документа | Строк |
|---|---|
| Базовий стандарт (іменування + бюджети + експорт) | 1–2 тижні |
| Повна Tech Art Bible + CI-валідатори | 3–6 тижнів |
| Оновлення існуючого документа під нову платформу | 3–7 днів |
Вартість розраховується після аудиту поточних практик команди та цільових платформ проекту. Зв'яжіться з нами для безкоштовної попередньої консультації та отримайте комерційну пропозицію протягом дня. Ми гарантуємо скорочення переробок на 30% та прискорення онбордингу нових художників.
Чому обирають наші стандарти?
Понад 5 років на ринку геймдев-документації. Ми допомогли десяткам студій уніфікувати пайплайни — від інді до AAA. Наші клієнти відзначають зниження часу code review на 40% та підвищення якості ассетів на першому чекпойнті. Замовте аудит поточних практик — отримайте план впровадження Tech Art Bible вже завтра.