Блог Ноэля Ллописа «Игры изнутри» затронул эту тему недавно в посте «Удаленное редактирование игр» . Первый абзац:
Я давно был поклонником минимального времени выполнения игр. Все, что может быть сделано в автономном режиме или в отдельном инструменте, должно быть вне времени выполнения. Это делает игровую архитектуру и код очень простыми и понятными .
(Очень рекомендуется прочитать статью, как и большинство материалов Ноэля, согласны ли вы на 100% или нет.)
Я считаю, что ключом здесь является сохранение сложности вне двигателя. Вы все еще можете иметь гибкость, но это гибкость в конвейере контента. И вы получите лучшую производительность, не тратя время на преобразование и перемещение данных.
Как ни странно, лучшая производительность может привести к меньшему времени итерации, несмотря на потерю некоторых возможностей редактирования в движке: легче попробовать что-то, если вы можете загрузить игру за секунду.
Принятие некоторых принципов « философии Unix » поможет вам сохранить гибкость вашей цепочки инструментов: небольшой модульный конвейер.
Моя личная философия: выпекать как можно больше данных в автономном режиме, но обеспечить поддержку движка для получения новых запеченных данных в любое время. (Обратите внимание, что эти новые данные не нужно вводить в игру, пока не появится удобная точка: кнопка «обновить» нажата, начинается следующий уровень, вы переходите в новую область, что угодно. Ключ находится в том месте, которое минимизирует время итерации с минимальной сложностью кода и усилиями по кодированию.)
В нашей компании большинство инструментов, предназначенных для художников / дизайнеров, сосредоточены на вопросах пользовательского интерфейса: простоте манипулирования отдельными активами или их партиями и т. Д. Иногда они являются инструментами сторонних производителей, такими как Photoshop или 3DS Max. Эти инструменты экспортируют в промежуточный формат (часто xml, который ссылается на двоичные данные источника, но не всегда). Промежуточный формат выбирается внутренним инструментом «создания данных», который превращает его в нечто полезное и быстро загружаемое для целевой платформы.
Переносимость достигается путем добавления дополнительных инструментов создания данных бэкэнда или расширения существующих инструментов создания данных бэкэнда, что дает дополнительное преимущество в том, что они невидимы для создателей контента.
Теперь, при правильном создании добавочных данных, вы можете вносить изменения в запеченный формат в течение нескольких секунд; ваш двигатель может «паучить» или инструмент может «паучить», и тогда они появятся в вашей системе ресурсов, готовые к перезагрузке, когда это будет удобно.
Инструменты - особенно инструменты создания внутренних данных - часто работают медленнее и медленнее, чем код движка. Это нормально, потому что их проще реорганизовать / переписать, расширить и протестировать; у вас есть спецификации для их поведения, и их довольно легко протестировать по сравнению с некоторым кодом двигателя.
Мои мнения по вашим вопросам:
Должен ли движок загружать различные форматы изображений? Загрузчик только TGA довольно прост в написании кода.
(Кроме того: даже если вы используете встроенный TGA-декодер, не кодируйте его вручную. Вы просто напрашиваетесь на неприятности - в большинстве форматов изображений есть много тонкостей, и множество инструментов, которые не придерживаются точно в недостаточно указанном формате. Лучше всего найти существующий хорошо проверенный библиотечный код для обработки изображений.)
Мне бы хотелось, чтобы здесь был инструмент для преобразования из TGA в любой формат внутренней текстуры, плюс метаданные.
Как насчет аудио форматов? Возможно ли поддерживать только загрузку файлов WAV? Как насчет фоновых музыкальных файлов, которые часто бывают огромными.
Мы используем три формата: отслеживаемая музыка (.xm), ADPCM (.wav) и Speex (.spx). Это в основном потому, что мы используем портативные устройства, и эти форматы очень легки для декодирования.
Должен ли двигатель быть в состоянии динамически разбирать TTF и генерировать атлас? Упаковка текстур.
Atlasing - сложная проблема: посмотрите ответы на свои недавние вопросы . Это почти всегда стоит делать в автономном режиме.
Кроме того, вы можете превратить метаданные для каждого символа в запеченную структуру с кодом, близким к нулю.
В заключение вы можете очистить и упаковать этот конвейер в свою игру для сообщества модов. Вы всегда можете добавить больше исходных форматов. И ничто не мешает вам устранить разрыв между инструментами создания контента и движком в конкретных случаях; Надеемся, что ваш код выпечки данных и код паука / передачи могут быть реорганизованы в библиотеки, которые в некоторых случаях могут быть использованы непосредственно инструментами создания контента. Но я бы не стал делать это своей первой целью, обязательно ... Просто знайте, что это будет конечной целью, и пусть это немного повлияет на ваш дизайн, и сначала доберитесь до низко висящих фруктов.
В качестве обновления вы можете рассмотреть возможность использования формата файлов KTX для текстур. Преимущество этого structподхода заключается в том, что он в большинстве случаев «читается и работает» для большинства сценариев использования GL (и, судя по вашим комментариям, вы нацеливались на GL), оставаясь при этом гибким и четко определенным.
Издержки заголовка KTX могут быть немного высоки для полностью запеченных данных, в зависимости от вашей цели, и вы можете отказаться от поддержки подстановки с обратным порядком байтов, в зависимости от вашего сценария использования ... но это определенно, по крайней мере, стоит из соображений дизайна.