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