Interpreters, inside C++.

[Zageron]

Has anyone here ever used a LUA/Python/etc interpreter to build scripts or AI routines inside an engine which you were working on and compiling yourself?

I am looking at using CINT as my interpreter for my scripting engine, instead of a more common scripting language. Simply because once the AI script is finished, I hope to be able to have a build setup to actually compile the C++ scripts into non-interpreted code.

This would allow for rapid, compile free, development of routines and scripted events, while allowing actual compilation of that code when it was time for the module to release.

I have never used an interpreter before, I really don't know how they perform. However, the game I am designing is quite AI heavy, so I can assume that these routines would be running very frequently.

If anyone has any input they can give me, I'd appreciate it. If you're interested in what I'm talking about, feel free to ask questions. This is not only a way for me to get insight, but also for me to expand my understanding of the topic regardless. :)

Cheers,

[Izzy]

Re: Interpreters, inside C++.

I don't really see how this would make anything run "faster" if you are essentially adding a whole additional layer of abstraction.

How big is this game going to be? Is compile time a real concern here?

[arcnmx]

Re: Interpreters, inside C++.

Scripting languages aren't used to make games faster, they're used to make development of behaviour and game logic faster at the cost of some performance. Usually, the ability to reload scripts dynamically and not have to go through a compile pass / restart the game is very much worth it :P
(especially when a lot of game logic isn't necessarily performance-sensitive, but just needs to be expressive and easy to write. AI doesn't always fall under this category though depending on complexity)

Python, don't do it. It's slow and far from portable. While minimal implementations exist, they're unmaintained and don't give you access to standard libraries... And PyPy isn't really worth embedding.

Lua's usually the solid choice to go with. Good standard VM spec, performant implementations (LuaJIT is very mature and fast), and a pretty solid language overall (if you overlook that goddamn 1-based index quirk) - also very portable. I've looked into various alternatives and you can see a bunch of suggestions here. It's hard to suggest anything besides Lua though, nothing I've seen really beats it from the technical angle.

[Zageron]

Re: Interpreters, inside C++.

What I am looking for is those of you who might have some experience with scripting languages, and what you have found to work the best. :)

I don't really see how this would make anything run "faster" if you are essentially adding a whole additional layer of abstraction.

How big is this game going to be? Is compile time a real concern here?

Pardon my lack of clarity if there was any.
I am looking to use a scripting interpreter which will both allow me to not compile it, for real time editing and testing without the need for recompiling, and compile it when the code is complete, for the fully optimized binary.

The game will be moderately large, and from what I can tell almost entirely built on scripts initially. Development and iteration demands that the game not be compiled/reloaded every single time, especially when building an AI script, event, tweaking a character, etc...

Scripting languages aren't used to make games faster, they're used to make development of behaviour and game logic faster at the cost of some performance. Usually, the ability to reload scripts dynamically and not have to go through a compile pass / restart the game is very much worth it :P
(especially when a lot of game logic isn't necessarily performance-sensitive, but just needs to be expressive and easy to write. AI doesn't always fall under this category though depending on complexity)

Yup! When I was building a game in C++ I grew very weary of the constant recompiling, compared to later building a game in Unity where it allowed for fast changes and testing. (I still do not like unity at all...)

Python, don't do it. It's slow and far from portable. While minimal implementations exist, they're unmaintained and don't give you access to standard libraries... And PyPy isn't really worth embedding.

Lua's usually the solid choice to go with. Good standard VM spec, performance implementations (LuaJIT is very mature and fast), and a pretty solid language overall (if you overlook that goddamn 1-based index quirk) - also very portable. I've looked into various alternatives and you can see a bunch of suggestions here. It's hard to suggest anything besides Lua though, nothing I've seen really beats it from the technical angle.

Hmm, thank you! I will avoid python as my second choice, and I guess fall back on to LuaJIT if CINT fails to work for me. I guess people wouldn't use it if it was slow, and it's safe to say that the majority of game engines use Lua for scripting. I will bookmark LuaJIT, and that other link you gave me, for when I look into it.

---

I intend to make this game open source, to a degree, eventually. I'll be sure to let FFR in on it. ;)