Ігри Ноеля Льопіса з блогу зачіпали це нещодавно у публікації "Віддалене редагування ігор" . Вступний параграф:
Я давно прихильник мінімальних тривалостей гри. Все, що можна зробити в автономному режимі або окремим інструментом, має бути поза часом виконання. Це залишає ігрову архітектуру та код дуже худими та простими .
(Стаття настійно рекомендується прочитати, як і більшість матеріалів Ноеля, будь то на 100% чи згоден.)
Я вважаю, що ключовим тут є збереження складності поза двигуном. Ви все ще можете мати гнучкість, але це гнучкість у контентному конвеєрі. А ви отримуєте кращі показники, не витрачаючи часу на перетворення та переміщення даних.
Більш висока продуктивність може перетворитись на менший час ітерації, дивно, незважаючи на те, що втрачаються деякі з можливостей редагування двигуна: легше спробувати щось, якщо ви зможете завантажити гру за секунду.
Прийняття деяких положень " філософії Unix " допоможе вам зберегти вашу інструментальну мережу гнучкими: невеликий модульний конвеєр.
Моя особиста філософія: запишіть якомога більше даних у режимі офлайн, але надайте підтримку двигуна, щоб отримувати нові запечені дані в будь-який час. (Зверніть увагу, що ці нові дані не повинні вступати в гру до зручного моменту: натискається кнопка "оновити", починається наступний рівень, ви переходите до нової області, що б там не було. Ключ - пошук солодкої плями, яка мінімізує час ітерації з мінімальною складністю коду та зусиллям кодування.)
У нашій компанії більшість наших інструментів, що стикаються з виконавцями / дизайнерами, орієнтовані на проблеми інтерфейсу: простота маніпулювання окремими активами або їх партіями тощо. Іноді вони є лише сторонніми інструментами, як Photoshop або 3DS Max. Ці інструменти експортують у проміжний формат (часто xml, який посилається на вихідні двійкові дані, але не завжди). Проміжний формат підбирається за допомогою інструменту «data make», який дає змогу перетворити його на щось корисне та швидке завантаження для цільової платформи.
Переносність досягається додаванням додаткових інструментів створення резервних даних або розширенням наявних інструментів створення резервних даних, що має додаткову перевагу - невидимість для творців вмісту.
Тепер, за допомогою належних додаткових даних, ви можете змінити формат запеченого протягом декількох секунд; ваш двигун може павук або інструмент може павукувати, і тоді вони з’являться у вашій ресурсній системі, готові до перезавантаження, коли це зручно.
Інструменти - особливо дані, що роблять резервні, - це інструменти, які часто корінніші та гнучкіші, ніж код двигуна. Це нормально, оскільки їх простіше перефактувати / переписати, розширити та перевірити; у вас є специфікації для їх поведінки, і досить легко перевірити їх тестування порівняно з деяким кодом двигуна.
Моя думка щодо ваших питань:
Чи повинен двигун вміти завантажувати різні формати зображень? Навантажувач лише для TGA - це досить простий код.
(Окрім цього: навіть якщо ви використовуєте декодер TGA в двигуні, не вводите його в коди. Ви просто задаєте собі проблеми - є багато тонкощів з більшістю форматів зображень і безліч інструментів, які не дотримуються в точно визначеному форматі, напевно, не вказано. Вам найкраще знайти існуючий добре перевірений код бібліотеки для обробки зображень.)
Я мав би тут інструмент конвертувати з TGA у будь-який ваш внутрішній формат текстури, а також метадані.
Що з аудіоформатами? Чи можливо підтримувати лише завантаження файлів WAV? А що з музичними файлами навколишнього середовища, які часто величезні.
Тут ми використовуємо три формати: відслідковувана музика (.xm), ADPCM (.wav) та Speex (.spx). Це здебільшого тому, що ми знаходимось на портативних комп'ютерах, і ці формати дуже легкі для розшифровки.
Чи повинен двигун бути здатним до динамічного розбору TTF та генерації атласу? Упаковка текстур
Атласування - це важка проблема: дивіться відповіді свого останнього запитання . Це майже завжди варто робити офлайн.
Крім того, ви можете перетворити метадані на кожного персонажа в структуру, запечатану майже нульовим навантаженням.
На завершення ви можете прибрати та упакувати цей конвеєр разом із грою для спільноти мод. Ви завжди можете додати більше вихідних форматів. І ніщо не заважає вам усунути розрив між інструментами створення вмісту та двигуном у конкретних випадках; сподіваємось, ваш код випічки даних та павук / код передачі можуть бути відновлені до бібліотек, які з часом можуть використовуватися безпосередньо інструментами для створення вмісту в деяких випадках. Але я б не ставив це своєю першою метою обов'язково ... Просто пам’ятайте, що це буде кінцевою метою, і нехай це трохи вплине на ваш дизайн, і спершу перейдіть до низько висячих фруктів.
В якості оновлення ви можете розглянути можливість використання формату файлів KTX для текстур. Він має перевагу в тому, що він здебільшого "читає structі переходить" для більшості випадків використання GL (і з ваших коментарів це здається, що ви націлили на GL), залишаючись гнучким і чітким.
Накладні накладні заголовки KTX можуть бути трохи високими для повністю випечених даних, залежно від вашої цілі, і ви, можливо, захочете відмовитися від підтримки ендіанського обміну, залежно від вашої користувальної скриньки ... але це, принаймні, варто, щоб розглянути питання щодо дизайну.