Может быть, стоит над архитектурой всей этой сложной системы поработать. Рефакторинг всё-таки великая вещь. Нам в своё время помог подход с выделением из всей этой нашей кучи-малы максимально независимых кодовых модулей. В результате стало понятнее, проще разрабатывать и тестировать. Более того, за счет устранения каких-то "незыблемых" концепций, пронизывавших всю систему от и до, система стала конфигурабельней, если можно так выразиться. Отсюда и возможность собирать то, что требуется для реализации конкретного проекта, и куча кодовых баз, с которыми нет проблем (ну, почти нет )

Рефакторинг отнимет у наших программистов не мало времени, а у нас нет такого запаса "прочности" по человекоресурсам, чтобы остановить всю(или большую часть) разработки на это время.
Изменений требуют бизнес-процессы, изменений требуют наши партнеры. Даже процесс изъятия из кода костылей потребовал достаточно времени, чтобы сказаться на дате выхода патча, что вызвало не мало негодования

Кроме того, даже если будут нормально собираться разные билды, то без фуллтеста каждого из них мы не обойдемся, т.к. слишком велика стоимость ошибки, а вешать на наш отдел QA фуллтесты 2-4 версий, это слишком жестоко.

Ох, как это всё знакомо... Сколько раз приходилось это наблюдать в чужих проектах, и калёным железом выжигать в нашем. Подход "только вперёд!" не один проект погубил. Хорошо, когда проект небольшой и "одноразовый". Не успевает рухнуть. Но когда кодовой базе несколько лет, всё это проявляется пышным цветом. Никто же не идеален, и не делает сразу идеальных систем. Поэтому и нужен рефакторинг, не мне вам объяснять, что это. И это должно быть в планах на разработку, этим на постоянной основе нужно заниматься. То, что Вы описываете - это другая крайность - "сломать всё до основания и построить заново". На этом этапе тоже куча проектов загибается. В продакшене долгое время ничего, а новый код в результате превращается в "новый старый", только с новыми проблемами, и работать с ним так же сложно, как и со старым, и тестировать тоже...
А бизнес-требования... Они есть, и с ними надо работать. По своему опыту знаю, что лучше отстаивать свою точку зрения в неприятных переговорах, нежели превратить процесс разработки в профанацию и гонку непонятно за чем.

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

То, что вы здесь обсуждаете, это не рефакторинг, а фунционал, который не был заложен. Я не сомневаюсь, что с кодом у нас всё в порядке. Вопрос в том, что будем ли мы менять фундамент в уже построенном доме? Я думаю нет, так как это не стоит тех денег, которые мы на это потратим и никто эту работу не оценит.

А почему внедрение системы сборки приведёт к таймауту в разработке, к примеру, нового функционала? Эти процессы вполне себе могут идти параллельно.
Ну, это уж как использовать будете столь богатую возможность. Могли бы вполне, к примеру, выпилить из русской версии столь нелюбимые банки на ЦП. Или сделать специально для китайцев супер-пупер-нагибаторскую пушку за кучу китайских денег, которая нашим комьюнити была бы воспринята крайне негативно.
Если этот фундамент мешает жить, довлеет какими-то своими костыльными концепциями, расползается по другим модулям своими зависимостями, приводит к написанию т.н. спагетти-кода - надо такой фундамент изолировать и постепенно рефакторить. Он жрёт вашу же производительность труда, за которую вы так печётесь. Опять же, зачем на это время останавливать остальной производственный процесс - решительно не понимаю.

Подожди, ни о какой производительности труда речи не идёт. Мы быстро работаем. Вы же тут обсуждаете разные рожи для разных регионов. И вопрос разных рож вообще не касается кода. Кодом это разрулить не так сложно. Вопрос контента, его создания и поддержания.

Так вот в том и дело. И если уж Вы поставили задачу создать ещё одни рожи, то расфасовать старые и новые рожи в разные клиенты могла бы система сборки. И сделала бы это совершенно бесплатно. Или таки наличие разных рож приведёт к каким-то другим далеко идущим вперед различиям в контенте? Прошу прощения за такой вопрос, я просто далек от этой темы.

Проблема не в том, чтобы собрать билд. Мы и сейчас можем собрать 2-3-5-10 разных версий. Более того, на данный момент у нас есть 3 разных билда для разных площадок и разных целей.
Проблема в том, чтобы постоянно поддерживать актуальность нескольких разных версий и своевременно тестировать их. Цена ошибки за пропущенную текстурку с черепком или красной кровью может стать полный запрет на издание в Китае, или повышение PEGI/ESRB на рынках EU/NA.

Возникает вопрос: а что тестировать? Если речь о коде, то здесь вы ничем не отличаетесь от множества других проектов. Хорошая архитектура и модульность - ключ к автоматизации тестирования. Функциональное тестирование? Нагрузочное тестирование? Всё автоматизируется в той или иной степени. Я вам могу припомнить знаменитые двери на ОБФ, которые не открывались в каждом новом патче. Ошибка в коде же явно. А почему на тестах не выявилась? Потому, что не обратили внимания, или на такие вещи у вас в принципе тесты не пишутся?
Ну, это уже казуистика какая-то. Как вообще такие вопросы могут возникать при наличии QA? Карты выходят нечасто, оружие тоже... Ну, засуньте эти текстуры в отдельный модуль или что-нибудь ещё, соберите один раз такой артефакт во всех вариациях и оттестируйте. И импортируйте в общий билд нужную версию, будучи в полной уверенности, что там всё ок от первой до последней текстурки. Или я что-то не понимаю, или вы на пустом месте проблемы создаёте сами себе...

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