Dynamic vs. pregenerated content

Вот что странно. За всю свою историю путешествий по интернету я НИ РАЗУ не встречал рассказа о том, как организована система сборки в том или ином игровом проекте (мультимедиа проекте; проекте, связанном с 3D графикой - нужное подчеркнуть).
А интересных тем там будет немало:

• как храним код и файлы ресурсов?
• какую make систему использовать?
• как копируем файлы?
• как делаем препроцессинг ресурсов? много утилит или одна со множеством плагинов?
• должны ли все утилиты быть отправлены в систему контроля версий или каждый разработчик самостоятельно ставит себе, все, что надо?
• как, в конце концов, интегрируем эту систему с нашим любимым супер навороченным редактором/IDE?

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

В следующем посте я постараюсь рассказать о том, как это все сделано у нас, а пока что...

Я до сих пор очень люблю pre-generated content(PreGC), то есть все данные, которые генерируется до запуска приложения. Это, по сути дела, чем-то похоже на конфиг файлы, куда можно все записать заранее, проверить(что очень важно!) отдельно, а потом использовать. В результате получаем отдельный модуль, который не нужно доводить до 100% оптимального состояния: алгоритмы в офлайне можно использовать самые простые и быстрые для написания.

У динамического контента(DynGC)  те же недостатки, что и преимущества у заранее сгенерированного: 

• код приложения усложняется, могут понадобиться различные изощренные оптимизации;
• модульность куда как сложнее организовать;
• данные проверить становится уже сложно, потому что не всякий разработчик DynGC озаботится модульностью (к сожалению, это так!).

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

Хотя вообще  спор на эту тему напоминает некий холивар, в котором побеждает тот, у кого больше звездочек на погонах. :)