Управління активами, база даних або система версій?

Під час розробки активів для гри (сітки, текстури, звуки, відео) хо ти ними керуєш?

1. Чи зберігає їх разом із вихідним кодом всередині системи версій? (perforce, git тощо)
2. Або мати центральну резервну базу даних, присвячену активам, і редактори завжди працюють так, як їй подобається? (PostgreSQL, MySQL тощо)
3. Інший?

Які плюси і мінуси кожного, і чому слід обирати його над іншими?

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

Припущення про те, що активи належать до окремого сховища, має сенс лише для дуже великих наборів активів або для дещо великих наборів активів, коли чітко визначена межа двигуна / даних. Якщо немає конкретної технічної причини для цього - це погана порада!

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

Наприклад: Ваш код може сподіватися, що він зможе встановити параметр на шейдері, і цей шейдер може залежати від текстури, що там знаходиться. А може формат даних ваших рівнів може залежати від конкретної версії коду гри.

Це майже напевно стане безладним. І у вас є кращі справи, ніж намагатися тримати це в порядку.

Тепер, як прокоментував Майк Вагнер ( на цю відповідь ) - ви не хочете або не потребуєте всіх «триваючих» версій своїх активів під контролем версій! Так само буде зроблена остаточна / робоча версія, використовувана вашим кодом - часто саме це ви експортуєте зі свого інструмента.

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

При цьому - іноді приємно мати можливість просто активувати активізовані активи під контролем версій. Зазвичай це передбачає наявність контентного конвеєра, який може обробляти будь-які кроки "експорту" для вас - наприклад: вирівнювання багатошарового зображення до однієї текстури.

Система версій.

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

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

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

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

Все в одному сховищі, якщо ви можете собі це дозволити за розміром. Я чув про сховища Subversion поблизу 1 ТБ. Наразі ми трохи нижче 400 ГБ.

Також художники багато перевіряють у всьому, включаючи 30 грубих контурів концепції; ми використовуємо окремі дерева папок для "вихідних активів" та для "експортованих" - тих, що входять до сценарію збирання активів. Якщо вашого художника завтра вдарить автобус, вам потрібно мати можливість, щоб хтось продовжував працювати над його активами на наступний день, лише переглядаючи сховище (археології немає на його особистому автоматі). Колись ігри були двовимірними і спрайти були створені зі складних анімованих сцен Макса, нам довелося відправляти купу одиниць у грі з RTS з трохи хитрим і дуже непослідовним виглядом (проти решти підрозділів), навіть хоча це було справою рендерінга з дещо іншими налаштуваннями освітлення та антиаліанти - тому що оригінальний художник вийшов, а у нас не було його оригінальних сцен Макса. Дон '