Replies: 1 comment 1 reply
-
I assume that for the best support you'll have to design the C++ engine around the scripting languages you plan on supporting. A generic external interface might work for scripting languages supporting a foreign function interface, but that'd work better for a C engine rather than C++. This is what I'd go with if you wanted to support everything, but you can't take full advantage of any scripting languages this way. If you have to design a DLL for each language you support then they'll only be as good as the effort you're willing to put into each of them. It's a bad idea to write support for a language you don't plan on using yourself. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Since I'm planning to add scripting to manipulate the engine without touching the C++ code, I'm thinking of making a generic scripting API, which could be used in DLL, loaded at runtime by the engine, thus given the possibility to expose any scripting language.
I already have a robust DLL loader for Windows / Linux / OSX, the question is: is this something worth investing time into? Would you be interested of being able to quickly add any scripting language / change the scripting language by swapping DLLs and modifiying a configuration file?
Nota: I'm not planning on working on this right now since the project still lacks a lot of functionnalities
Beta Was this translation helpful? Give feedback.
All reactions