Racket as scripting language in a game engine

Question

I would like to add scripting capabilities to my C++ game engine.

I have Engine.exe, Physics.dll, Audio.dll and I'm adding Scripting.dll which is a high-level Racket wrapper.

Engine.exe loads Physics.dll and sets up physics world, loads Audio.dll and sets up audio world. It is supposed to load Scripting.dll, to set up bindings to Physics.dll, Audio.dll and to load game scripts.

AFAIK there are two possible ways to embed Racket into a C++ program:

• As Extension
• As Foreign Interface

Using Foreign Interface seems bizarre due to necessity to load Physics.dll, Audio.dll two times: first from Engine.exe and then from the game script.

Writing Extensions looks more appealing, because it allows doing script bindings on C++ side. On the other hand you have to build your extension with raco ctool, link it with mzdyn object file — which looks awkward as well: why not make mzdyn a static library?

I would like to implement a single method, e.g. setupScriptBindings(), both in Physics.dll and in Audio.dll, and to call it from Engine.exe at the startup.

Is there a straightforward way to do it?

Answer 1

Having used both the extension and FFI methods of connecting Racket to C code, I have to say the FFI approach is much nicer. The bindings in Racket to the C functions are well specified and robust and dealing with C types in Racket is very nice. The only drawback to using the FFI approach is that, AFAIK, your Racket program must be the driver application.

With the embedding approach your C/C++ executable is the driver, but declaring the interface with the Racket code is much more manual and error prone. Not to mention that you have to either figure out raco ctool and replicate it or have racket's build system take over yours. For our purposes we wound up extracting the Racket sources and building it ourselves. I don't really recommend that approach.

Ultimately for my purposes having my application be a Racket application with a foreign .DLL/.so file that it loaded for C functions worked best, but it sounds like you may be stuck with the embedding approach.