Изменение включаемых / объектных файлов в середине программы C ++

Question

Я и некоторые друзья пытаемся создать игровой движок, который может запускать несколько игр на С ++.Игры настолько похожи, что все они имеют одинаковую механику и интерфейсы, которые я хочу сделать для некоторых файлов, применимых к каждой игре.Многие исходные файлы будут такими же, как файлы нашего графического интерфейса или Game Engine.Однако некоторые файлы, относящиеся к индивидуальной игровой механике, будут меняться от игры к игре.Если это расширяется до большой библиотеки, я не хочу просто включать каждый файл из каждой библиотеки, чтобы играть в одну игру.Я также не хочу, чтобы в каждой папке библиотеки были дубликаты файлов графического интерфейса и игрового движка.

В настоящее время я думаю об идее запуска, который изменит теги #include в соответствии с выбором.сделано пусковой установкой, хотя это может потребовать перекомпиляции.Есть ли способ сделать это / это хорошая техника, или это лучший способ?(имейте в виду, я бы предпочел, чтобы int main оставался в игровом движке / общем файле, а не создавал main для каждой игры)

Answer 1

Обобщая ваши требования:

• У вас есть некоторый общий код игрового движка, который достаточно общий для нескольких разных игр;
• Однако движок зависит также от кода, специфичного для конкретной игрыэто специфично для каждой игры;
• В настоящее время вы решаете эту проблему, изменяя поведение игры во время компиляции;
• Вам нужно решение, в котором было бы проще разделить игровой движок между различными играми, например, для объединения нескольких игр, которые пользователь мог выбрать при запуске (через панель запуска).

Если это правильно, вот некоторые мысли, которые помогут вам в дальнейшем:

• Нет способа элегантно изменить элементы времени компиляции (включенные) во время выполнения.
• Создание модуля запуска, который получает доступ ко всему исходному коду для повторной компиляции в потоке, кажется нереальным решением (поскольку пользователю необходимо предварительно установить среду компиляции с установленными всеми библиотеками, зависимостями и цепочками инструментови в любом случае, запуск игры занял бы слишком много времени).
• В таком случае правильным подходом будет более широкое использование полиморфизма и реорганизация игрового движка, чтобы полагаться на инкапсулированные игровые объекты (используя понятный интерфейс и поддерживая связь как можно ниже).например, используя SOLID design).
• Как только достигается такая степень полиморфизма, вы можете при запуске игры вводить в движок определенные элементы игры (например, фабрика абстрактных игр , которая позволяет движку инициировать семейства связанных игровых объектов).без необходимости знать особенности игры).Вы можете выбрать, использовать ли отдельную основную часть для каждой игры (выбор времени компиляции игры) или оставить пользователю выбор из нескольких при запуске (выбор времени выполнения).
• В качестве альтернативы вы также можете построить свою систему на основе чистого API между игровым движком и динамической библиотекой (например, DLL под окнами), которая динамически загружается во время выполнения (и которая затем может загружать вновь доставленныеигры, упакованные как игровые ресурсы DLL + и добавленные к уже установленным играм, когда это необходимо. ( Джон порекомендовал эту замечательную ссылку в комментариях, есть также эта и, конечно, парадругих. Но имейте в виду, что это уровень дополнительной сложности, который должен очень хорошо понимать ограничения DLL - так что, возможно, оставьте это в качестве последующего шага для вашего рефакторинга)