Racket as a scripting language in the 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 shell.

Engine.exe downloads Physics.dll and sets up the physical world, loads Audio.dll and sets up the world of audio. It is supposed to download Scripting.dll , establish bindings to Physics.dll , Audio.dll and load game scripts.

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

• Like an extension
• As an external interface

Using the external interface seems strange due to the need to download Physics.dll , Audio.dll two times: first from Engine.exe , and then from the game script.

Writing Extensions looks more attractive because it allows you to do script bindings on the C ++ side. On the other hand, you need to build the extension using raco ctool , link it with the mzdyn object file, which also looks inconvenient: why not make the mzdyn static library?

I would like to implement one method, for example. setupScriptBindings() , both in Physics.dll and in Audio.dll , and call it from Engine.exe at startup.

Is there an easy way to do this?

Answer 1

Using extension methods and FFI to connect Racket code to C, I have to say that the FFI approach is much nicer. The bindings in Racket to C functions are well defined and reliable, and working with C types in Racket is very enjoyable. The only drawback to using the FFI approach is that AFAIK, your Racket program, must be a driver application.

With an implementation approach, your C / C ++ executable is a driver, but declaring an interface with Racket code is much more manual and error prone. Not to mention the fact that you need to either understand raco ctool, or play it, or use the racket assembly system. For our purposes, we launched the extraction of racket sources and built them ourselves. I do not recommend this approach.

Ultimately, for my purposes, when my application was a Racket application with a foreign .DLL / .so file that it downloaded for C functions, it worked best, but it looks like you can depend on the implementation approach.