Racket как язык сценариев в игровом движке

Question

Я хотел бы добавить возможности сценариев в свой движок игры на C++.

У меня есть Engine.exe, Physics.dll, Audio.dll и я добавляю Scripting.dll, который ракетка обертки высокого уровня.

Engine.exe загружает Physics.dll и устанавливает физический мир, загружает Audio.dll и устанавливает звуковой мир. Предполагается загрузить Scripting.dll, настроить привязки на Physics.dll, Audio.dll и загрузить игровые скрипты.

AFAIK есть два возможных способа встроить ракетки в программу C++:

• As Extension
• As Foreign Interface

Использование Foreign Interface кажется странным из-за необходимости загружать Physics.dll, Audio.dll два раза: сначала от Engine.exe, а затем от сценария игры.

Письмо Extensions выглядит более привлекательным, поскольку позволяет выполнять привязки скриптов на стороне C++. С другой стороны, вам нужно построить расширение с помощью raco ctool, связать его с объектным файлом mzdyn - что тоже выглядит неудобно: почему бы не сделать mzdyn статической библиотекой?

Я хотел бы реализовать один метод, например. setupScriptBindings(), как в Physics.dll, так и в Audio.dll, и называть его от Engine.exe при запуске.

Есть ли простой способ сделать это?

Answer 1

Используя как расширение, так и методы FFI для подключения кода Racket к C, я должен сказать, что подход FFI - это много приятнее. Связывания в Racket с функциями C хорошо определены и надежны, а работа с типами C в Racket очень приятная. Единственным недостатком использования подхода FFI является то, что AFAIK, ваша программа Racket должна быть приложением драйвера.

С внедрением встраивания ваш исполняемый файл C/C++ является драйвером, но объявление интерфейса с кодом Racket гораздо более ручное и подверженное ошибкам. Не говоря уже о том, что вам нужно либо разобраться в raco ctool, либо воспроизвести его, либо использовать систему сборки ракетки. Для наших целей мы запустили извлечение источников ракетки и построили их сами. Я не рекомендую этот подход.

В конечном счете, для моих целей, когда мое приложение было приложением Racket с иностранным файлом .DLL/.so, который он загрузил для функций C, работал лучше всего, но похоже, что вы можете придерживаться подхода внедрения.