Рефакторинг: Делаем игровой движок более модульным и как

Мой игровой движок состоит из ряда слабо связанных модулей, которые можно загружать и выгружать.

Вот некоторые примеры: базовый модуль, обрабатывающий управление окнами и отвечающий на события ОС, диспетчер сущностей, диспетчер Lua, диспетчер физики.

Прямо сейчас эти модули организованы как пространства имен, и их состояние определяется через локальные переменные в соответствующих исходных файлах. В каждом из пространств имен есть функции Open (), Close () и Update ().

Теперь мне больше не нравится решение с пространствами имен .

  • Оно недостаточно гибкое

  • Даже если это может не понадобиться на самом деле, простая возможность создания нескольких экземпляров модуля кажется правильной

  • Похоже, я не использую здесь ООП - базовый класс модуля с виртуальным обновлением ( ) функция-член будет звучать более разумно

  • Труднее гарантировать, что при закрытии и повторном открытии модуля все переменные тоже будут сброшены (проще использовать класс с конструкторами и деструкторами)

  • Вы не можете правильно управлять модулями без явного вызова Open (), Close () и Update ()

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

Но решение с ООП поднимает проблему того, как модули должны взаимодействовать. Прямо сейчас базовый модуль приказал консольному модулю что-то напечатать через console :: print ()

  • Как я могу обойти эту проблему, не используя что-то вроде g_ModuleManager.GetConsoleModule () -> print () ?

  • Как этот менеджер модулей мог работать в деталях?

И мой последний вопрос:

  • Есть ли у вас какие-либо дополнительные советы по теме написания модульного игрового движка на C ++ с ООП ?

  • Есть ли какие-нибудь шаблоны проектирования, которые могли бы мне помочь в этой ситуации, или, может быть, даже конкретный материал для чтения?

7
задан Jarx 1 March 2011 в 18:14
поделиться