🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Three questions regarding integrating a scripting language to a custom engine

Started by
4 comments, last by Gnollrunner 5 years, 2 months ago

 I'm very interested in integrating a scripting language (that's not LUA) to my little engine but had a few doubts:

  • Is one of the purposes of scripting languages in an engine to avoid compile time and update game logic without recompiling the engine/game? At least that's the reason I want one.
     
  • I sometimes read about performance hits when using a scripting language in an engine. Are they talking about performance hits every time I try to reload a script, or while the game is updating? I was hoping that once the script is interpreted there wouldn't be any performance issues aside from reloading the script.
     
  • Aside from Lua, what scripting languages would you all recommend? I'm trying to focus on something like Javascript or Dart. So far I've found Ducktape, but not sure if it's good for games.

       Thanks!

Advertisement

Yes, avoiding recompilation is a large benefit. Scripts can be hot reloaded at runtime without even exiting the game.

After a script is loaded, there is typically some amount of overhead added by the virtual machine that executes the script, just as any other abstraction layer. The amount varies from language to language. Some languages live closer to the metal than others, some languages provide garbage collection which can bring it's own set of penalties, etc.

You might take a look at angelscript which has a home of sorts on this very forum. It is one of the language options integrated into the engine I use (Urho3D) and is a pretty decent choice.

8 hours ago, JTippetts said:

Yes, avoiding recompilation is a large benefit. Scripts can be hot reloaded at runtime without even exiting the game.

After a script is loaded, there is typically some amount of overhead added by the virtual machine that executes the script, just as any other abstraction layer. The amount varies from language to language. Some languages live closer to the metal than others, some languages provide garbage collection which can bring it's own set of penalties, etc.

You might take a look at angelscript which has a home of sorts on this very forum. It is one of the language options integrated into the engine I use (Urho3D) and is a pretty decent choice.

Angelscript looks great and it seems well documented. I also love how they use c++ style syntax. Thanks a lot JTipetts!

I dont know if this is still actively being developed, but you could look into Runtime Compiled C++...

http://runtimecompiledcplusplus.blogspot.com/

 

In my old job I ended up writing a couple of scripting languages which we hooked into our design tools.  Scripting generally provides a command line interface to tools and of course lets you change things on the fly without a recompile.  Memory management and how it interacts with the core language is a key aspect of scripting language design.  This often means implementing a garbage collector or some kind or reference counting.  I'm a big proponent of reference counting, however for scripting languages quite often GCs are preferred because you don't encounter the circular reference problem.  With core level code you have a choice of when to use strong and weak pointers (at least in some languages like C/C++) so this is less of a problem.  Of course you can implement the same thing in a scripting language but generally people don't, because they don't want to force the script writer to understand memory management details. Also there is some extra stuff you need to take care of when doing reference counting in scripts, because you don't want memory leaks if the script writer makes some programming errors.  Ideally you don't want a script to be able to cause a hard crash in your application.

As for performance issues, scripting languages generally use some sort of byte code complication so of course they are going to run slower.  However if you are using a scripting language properly, you are only coding non CPU intensive code with them.  Anything that ends up running too slow you want to code in the core language and call in your scripting language.

I'm eventually going to have to start using a scripting language myself.  I haven't really looked into them for a while. I used to use an implementation of Scheme. I added an alternate parser to it, which made it look more like C. This worked well. This was many years ago however.  I later programmed in JavaScript and noticed it was damned close to a dialect of Scheme with just a different syntax. They nearly did he same thing we had done years earlier.  For this reason I really like JavaScript and I'll probably end up looking for a light-weight JavaScript implementation I can do scripting with.  Of course JavaScript is also very popular so I won't end up with some strange language nobody knows. Keep in mind you don't have to use all the OOP stuff they tacked on. You can program it like a functional language if you want.

The alternative solution which I was considering was to throw together my own scripting language with reference counting and supporting strong and weak pointers.  However I'm not really sure it's worth the effort.

This topic is closed to new replies.

Advertisement