Советы по присоединению движка и GUI

Question

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

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

Есть ли у кого-нибудь какие-либо советы или предложения, чтобы минимизировать риск глюков в этом процессе. Можно ли как-нибудь проверить во время выполнения / во время компиляции, чтобы убедиться, что все параметры компиляции и ссылки соответствуют ожидаемым?

РЕДАКТИРОВАТЬ: Только что заметил этот вопрос о записи флагов компилятора в GCC. Кажется, что GNU позволяет это. Есть ли эквивалентная команда для visual studio?

Answer 1

Я бы сказал, что на самом деле несколько удивительно, насколько чувствителен весь этот код к настройкам компилятора. Знаете ли вы, если ваш издатель в Японии компилирует ваш код в библиотеку или напрямую компилирует его в основной графический интерфейс? Они, конечно, не должны компилировать два в одном проекте в Visual Studio, если им требуются разные флаги компилятора.

Если это C ++, вы можете использовать static assert boost, чтобы гарантировать, что определенные вещи установлены, и вам, вероятно, также следует поместить несколько макросов #error в местах, если вещи не установлены.

Сказав это, я отправлю им DLL и заголовочные файлы. Это должно работать независимо от того, как они устанавливают свои флаги компилятора.

Редактировать: кроме того, в зависимости от вашей игры, вам, вероятно, будет лучше заменить глубокие вызовы в вашем движке протоколом, который вы можете определить с помощью JSON, XML, ASN.1 или ваша собственная грамматика - если ваша игра не имеет жестких требований графического интерфейса реального времени, то есть. В этом случае интерфейс становится тривиальным, и его будет сложно порвать с такими вещами, как неправильные флаги связывания.

Answer 2

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

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

В Windows идеальным решением было бы разделить графический интерфейс таким образом, чтобы замена DLL изменила сам графический интерфейс.См. OGRE , для примеров использования библиотек DLL для обеспечения модульных подсистем.