Должны ли инструменты конвейера контента внедряться в движок?

Насколько минимальным должен быть игровой движок? Какая часть конвейера контента должна быть встроена в двигатель?

Некоторые примеры использования супермодуля:

  • При загрузке пользовательского контента пользователю не требуется упаковывать свои текстуры, двигатель будет делать это во время загрузки.

  • Скрипт запрашивает шрифт гораздо большего размера, чем был предварительно сгенерирован, двигатель может анализировать объявление файла ttf, создавая новый атлас текстуры.

  • Halo forge .

Все это бесплатно. Это требует, чтобы ваши инструменты конвейера контента были написаны на C ++. Библиотеки поддержки, которые вы используете в конвейере, необходимо скомпилировать для использования на устройстве. Это требует, чтобы генерация контента не была ошибкой. И это обычно делает ваш двигатель более крупным и громоздким.
Какие еще плюсы и минусы?
Разве плюсы перевешивают минусы?

Некоторые конкретные вопросы:

  • Может ли двигатель быть в состоянии загружать различные форматы изображений? Только загрузчик TGA довольно легко передает код.

  • Как насчет аудиоформатов? Возможно ли поддерживать только загрузку wav-файлов? Что относительно обычных музыкальных файлов, которые часто огромны.

  • Должен ли двигатель быть способен к динамическому анализу TTF и созданию атласа?

  • Упаковка текстур.

10 голосов | спросил deft_code 21 PM00000060000000831 2010, 18:53:08

2 ответа


11

Noel Llopis's Games from Within blog затронул это недавно в пост «Удаленная редакция игры» . Начальный абзац:

  

Я уже давно поклонник минимальной игры   Время автономной работы. Все, что можно сделать   автономно или в отдельном инструменте, следует   быть вне времени выполнения. Это оставляет   игровая архитектура и код очень скудные   и простой .

(Статья очень рекомендуется прочитать, как и в большинстве материалов Ноэля, согласны ли вы на 100% или нет.)

Я считаю, что ключевым моментом является сохранение сложности вне двигателя. У вас все еще есть гибкость, но это гибкость в контенте контента. И вы получаете лучшую производительность, не тратя время на конвертирование и перемещение данных.

Лучшая производительность может перевести на более низкое время итерации, как ни странно, несмотря на то, что утеряны некоторые возможности редактирования в двигателе: проще попробовать что-то, если вы можете загрузить игру за секунду.

Принятие некоторых принципов « философии unix » поможет вы держите свою инструментальную цепочку гибкой: небольшой модульный трубопровод.

Моя личная философия: испечь столько данных как можно больше в автономном режиме, но предоставить поддержку двигателя для получения новых выпеченных данных в любое время. (Обратите внимание, что эти новые данные не нужно вводить в игру до тех пор, пока не будет удобной точка: нажата кнопка «Обновить», начнется следующий уровень, вы перейдете на новую область, что угодно. Ключ - найти сладкое пятно, которое минимизирует время итерации с минимальной сложностью кода и усилием кодирования.)

В нашей компании большинство наших инструментов для художников /дизайнеров ориентированы на проблемы пользовательского интерфейса: простота манипулирования отдельными активами или их партиями и т. д. Иногда это просто сторонние инструменты, такие как Photoshop или 3DS Max. Эти инструменты экспортируются в промежуточный формат (часто xml, который ссылается на исходные двоичные данные, но не всегда). Промежуточный формат подбирается с помощью бэкэнда «data make», который превращает его в что-то полезное и быстро загружаемое для целевой платформы.

Переносимость достигается за счет добавления дополнительных инструментов создания бэкэнд-данных или расширения существующих инструментов создания бэкэнд-данных, которые имеют дополнительное преимущество в том, что они невидимы для создателей контента.

Теперь, при правильной инкрементной обработке данных, вы можете иметь изменения в выпеченном формате в течение нескольких секунд; ваш двигатель может паук или инструмент может паук, а затем они появятся в вашей ресурсной системе, готовые к перезагрузке, когда это будет удобно.

Инструменты, особенно данные бэкэнда, делают инструменты - часто sloppier и buggier чем код двигателя. Это нормально, потому что им проще реорганизовать /переписать, расширить и протестировать; у вас есть спецификации для их поведения, и довольно легко их протестировать по сравнению с некоторым кодом двигателя.

Мои мнения по вашим вопросам:

  

Может ли двигатель быть в состоянии загружать различные форматы изображений? TGA   только загрузчик довольно прост в использовании   код.

(Помимо этого: даже если вы используете декодер TGA в двигателе, не делайте его вручную. Вы просто просите о проблемах - есть много тонкостей с большинством графических форматов и множество инструментов, которые 't придерживайтесь точно к возможно-underspecified формате. Лучше всего искать существующий хорошо протестированный библиотечный код для обработки изображений.)

У меня есть инструмент для преобразования из TGA в любой формат внутренней текстуры, плюс метаданные.

  

Как насчет аудиоформатов? Это   возможно поддерживать только загрузку wav   файлы? Как насчет эмбиентных музыкальных файлов   которые часто огромны.

Здесь мы используем три формата: отслеживаемая музыка (.xm), ADPCM (.wav) иSpeex (.spx). Это в основном потому, что мы на КПК, и эти форматы очень легки для декодирования.

  

Если двигатель способен   динамический анализ TTF и атлас   поколение?   Упаковка текстур.

Atlasing - сложная проблема: см. ваши последние вопросы . Почти всегда стоит делать офлайн.

Кроме того, вы можете превратить метаданные каждого персонажа в кучную структуру с нулевой загрузкой.

В заключение вы можете очистить и скомпоновать этот конвейер своей игрой для сообщества мод. Вы всегда можете добавить больше форматов источников. И ничто не мешает вам преодолеть разрыв между инструментами создания контента и движком в конкретных случаях; надеюсь, что ваш код для выпечки данных и код паука /передачи могут быть реорганизованы в библиотеки, которые в некоторых случаях могут быть использованы непосредственно инструментами создания контента. Но я бы не сделал это своей первой целью, обязательно ... Просто имейте в виду, что это будет конечная цель, и пусть это немного повлияет на ваш дизайн и сначала начнет использовать низко висящие фрукты.


В качестве обновления вы можете захотеть использовать Формат файла KTX для текстур. Преимущество этого заключается в том, что в большинстве случаев «читать в struct и идти» для большинства GL-уставов (и из ваших комментариев это похоже на то, GL), все еще будучи гибкими и четко определенными.

Накладные расходы заголовка KTX могут быть немного высоки для полностью испеченных данных, в зависимости от вашей цели, и вы можете отказаться от поддержки подкачки под управлением, в зависимости от вашей учетной записи ... но это определенно, по крайней мере, стоит того, соображения.

ответил leander 21 PM00000090000005531 2010, 21:52:55
3

Ваши вопросы звучат очень субъективно и сильно зависят от того, кем является ваша целевая аудитория.

Возьмем вопрос о выборе шрифта /ttf. Если вы планируете создавать модемы, добавляя свой собственный шрифт, вы, вероятно, захотите сделать процесс импорта как можно более быстрым. Если вы добавляете большое количество шрифтов /шрифтов в игру внутри, возможно, вам нужен несколько сложный инструмент, который художник может использовать с небольшой подготовкой. Если вы собираетесь делать это один раз внутренне, то время, затрачиваемое на создание надлежащего импортера, вероятно, будет меньше, чем потратить время на создание инструментов для предыдущих случаев.

Это действительно вопрос масштаба со всем остальным. Встроенные инструменты стоят усилий, когда вы делаете что-то много раз и хотите уменьшить сложность /ошибки, возникающие из-за этого. Каждый добавочный дополнительный определитель (т. Е. Текстуры TGA только вместо импорта, скажем, PSD) приводит к увеличению времени, затрачиваемого конечным пользователем.

Помните, что инструменты содержания обычно используются менее технически настроенными (читайте: художники). Лично мне очень нравится, как работает Unity, где вы можете просто перетащить исходный файл (psd, 3ds, ttf, mp3, jpg, mov, whatever), и он автоматически преобразует его во внутренний формат. Внутренний формат в основном скрыт от конечного пользователя. Он также автоматически переконвертируется, когда он обнаруживает изменение исходного файла. Но это большая работа.

ответил Tetrad 21 PM00000080000001531 2010, 20:45:15

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132