Why not an embedded script interpreter rather than C# assemblies ???

News & General Discussion
1

I keep asking me the same question and I would like to understand what is going on…

Unity’s core is written in C++, and users have the possibility to add functionalities which are coded in C#, compiled and then loaded in the engine.

C# is a very good language in terms of productivity, there is not arguing about that…

But why, god why, using compiled libraries rather and just embed an interpreter in the C++, such as python, lua, javascript V8, go, or whatever ?

It would make so much more sense, one would not need to care about portability of the added functionalities because the script would be interpreted directly in the compiled C++ app…
As long as the core app runs on the platform the script would run too, there would be no need for il2cpp insanity…

Also it would be much easier to reload changes, since no assemblies would have to be reloaded, just the scripts would have to be reloaded…which means that we could make changes in games that are already compiled…

I understand that performance might be an issue, but where to we stand for with old mono performance compared to lets say last generation V8 javascript engine…

So the only reason to use C# instead, except for performance reasons (that would need to be benchmarked), would be the extensive support for third party libraries, however due to the outdated .NET profile most of the interesting libraries that I’d like to use are not available anyways…

Could somebody explain me what happened in their mind for making such decision ?

This is not a hate message, I am actually interested in game engine development, and I would like to know what would have been the best approach if they had a chance to start over again.

2

It would be much slower and some platforms do not allow it.

6 Likes
3

mat_muze, I read your post twice, looking for a reason why an embedded interpreter would be preferable, but I can’t find it. What exactly would be the point? Embedding python would limit portability to those platforms where python is supported, so no improvement there.

4

Hi guys it looks like you might missing a bit of technical knowledge, here is a explanation how and embedded interpreter works:

An embedded interpreter is a C++ program that read “text” instructions and execute them internally.
It also allows to expose function in the scripting language to functions that are coded in C++ and would be executed in the host program (like a pointer to a function for instance)…

Usually the interpreter is shipped as a C++ compiled library and is therefore very portable, as long as the library can be compiled on your platform you are good to go (much easier to port than C#)

So the python instruction print(“hello”) would be a string which would interpreted directly in the C++ program.

More details here: 5. Embedding Python in Another Application — Python 2.7.18 documentation

But python is just an example, there are also other C++ interpreters which offer better performances such as JavaScript interpreters…

5

That still doesn’t explain why you think it is an advantage. Sure it works differently, how does that make life better for us?

I can think of positives for both approaches, by the way. I’m not knocking interpreted languages. It’s just that you’re citing differences rather than benefits.

They made that decision over 10 years ago, so the “outdated” nature which you cite against it simply wasn’t the case at the time. Similarly, plenty of the alternatives you mention as potentially being superior didn’t exist at the time, so they weren’t options at all.

6

The main advantage is that you do not need to compile C# at all.

C# —> must be compiled (problem for supporting multiple platforms)
Script —> simply interpreted (no problem)

Scripts that are written will work seamlessly on any platform, no need to rely on Mono/.NET/IL2CPP for compiling the code since it is interpreted…

Which would also mean that performances would only depend on how fast the native core app runs, while right now there are some discrepancies between the technologies that one is using to compile C#.

This would make a lot of sense for UT, because it does look like that one of the major issue/challenge that Unity Tech. is facing is making sure that the code written in C# should run seamlessly on any platform.

That’s why they decided to develop IL2CPP, however this technology is still not very mature, add extra build steps which make the development/debugging more cumbersome and also increase building times…

Well using an interpreter this would guaranty portability out of the box… even for WebGL.

tl;dr:

Advantage would be better portability, no need to develop and maintain complex programs such as IL2CPP.

The only problem I could think of, could be in terms of performance, but without proper benchmarks it is hard to say what would actually runs faster, and it seems like modern JavaScript engines like V8 have became very fast these days.

7

I suspect that they went with it because of things like the following:

  • Performance compared to scripting systems available at the time
  • Cross-platform availability
  • When in the Editor it still has many of the benefits of an interpreted language, eg: not requiring an explicit recompilation step when changing the code
  • Access to C# as a programming language
  • Ability to create their own languages for it. I suspect JavaScript was important for their marketing, for instance (otherwise why call it “JavaScript” at all, when it is not actually JavaScript?).
  • For C# in particular, they could take advantage of the excellent C# development tools already available. I’m not aware of any similarly good IDEs available for interpreted languages. (Probably they do exist today? But, again, the decision was made over a decade ago.)

I understand that you think this. I don’t understand why that is an advantage. As in, how would that make my day to day life as a programmer better? Significantly better?

As it is, if I want to change code I hit alt-tab, change my code, hit alt-tab again, and hit the Play button. How would the use of an interpreted language change that?

One thing that I would see as an advantage is if we wanted to change code in live applications in our development. I’ve seen people show that with Lua developing for games consoles and it’s sweet. With C# we don’t have quite that level of flexibility, in that we have to stop and re-start our game to see the changes.

Also this. I’m not sure about right now, but I believe Apple’s agreements ruled out the use of exactly the type of system you’re talking about. (Makes sense given how far they go to QA software deployed to their devices. Not much point doing that then giving people the ability to easily change it after the fact.)

Except where they don’t. I mean, it’s great that one thing can compile for all platforms, but compiling isn’t the whole story. There still needs to be per-platform support for the areas where the platforms are different.

Check out something as simple and common as saving a file. The code might compile for all supported platforms, but that doesn’t mean it’ll work.

Edit: Also, just want to say, pretty decent discussion.

1 Like
8

Forgive my lack of familiarity with JavaScript… does it support multi-threading yet?

9

It would not affect your experience much expect the that you would need to use another language. (btw, IDE are improving greatly these days mostly due to the large catalogue which is offered by JetBrains, check it out)

The main advantage would be for UT which would not have to struggle to make their game engine portable.

Again, embedding an interpreter is a very simple operation which does not really depend on the system that you are using, please read more information about it before commenting on this thread.

If the scripts is calling a functionality which is coded is the C++, and works for any platform/system, it will work not matter what platform/system. In essence, the script is just a way to make calls to C++ functions, just like when you press a GUI button and a function get called for that action…

10

A standalone JavaScript engine embedded in a C++ application, can be different from the JavaScript engine which you get in a Web Browser and which you might probably be familiar with. It would resemble more to what you would get with Python, and would therefore offer similar functionalities, multi-threading included.

11

So… the main effects are making me do extra work in changing language, and losing access to the incredible amounts of my prior work and work available from others (eg: the Asset Store)?

Hmm… you don’t seem to have read what I wrote, on this or some of the other points.

Have you ever written file IO code for, say, PC + Web Browser + iOS? If you had it would be very clear that what you’re saying here simply isn’t correct. Sure, the code might interpret correctly for each system (as it already compiles correctly for each system) but it won’t actually work on them all. One of them will run as expected, the others will simply return a bunch of errors and fail unless you write platform-specific code that adheres to the appropriate rules.

12

I’m also confused as to why this would be a benefit. Here are some thoughts to consider:

  • Anything resembling building code at runtime (compiling or interpreting) is specifically disallowed on apples systems. That portion of the market would still require precompiled code.
  • Compile time errors are a developers friend. Eliminating a compile step eliminates an opportunity to catch errors
  • Interpreted languages are typically slower
1 Like
13

Oh the days before web standards, when IE 6 had to be supported.

1 Like
14

No idea, why would anyone want their code to run 10-100 times slower and getting no benefits in return.

2 Likes
15

What make you say that, have you bench-marked the execution of instructions for interpreted languages vs Mono ?

Do you have any numbers that would be helpful for that discussion ?

16

An interpreter is precompiled… sigh…the parsing of the script just trigger functions that are precompiled…

Just imagine a script as an list of command/function calls that are executed on the C++ side sequentially, just like batched commands

True that, however Mono/IL2CPP are still not the super duper fast either, I would be curious to see the execution speed of modern interpreted languages vs IL2CPP/Mono, just curious…

17

On the one hand, the script would call C++ functions, which you exposed manually, and that are guaranteed to work on any machine because that’s how the core of the engine in built.

On the other hand, the script would call functions from the script engine’s (I/O functionalities for instance) which are usually multi-platform, see python for instance.

Those instructions would then be broken down to low-level calls by the interpreter directly inside the core C++ application.

But the main problem would be that you would also need to include those scripts or libraries as well (I/O scripts, etc…) just like how you need to include a VM

18

My guess is that you’re coming from some sort of modding background and not a serious programming background. No serious programmer would ever want an interpreted language over a compile language. The benefits of compilation are far too numerous to list. There are plenty of engines that use LUA or Python or Lisp, go use those. I only use unity because of its C# integration.

3 Likes
19

That hurts a little :slight_smile: I do have a solid background in programming tho…

Is that just a matter of taste or have you witnessed significant performance discrepancies between using scripting-based engines and C# ?

Have you ever used panda3D for instance ? Where you disappointed with how fast your game logic code was executed from the interpreted scripts ?

20

A serious programmer would never even get started with a VM like Mono anyways… since we are already doing a huge compromise in performance using Mono, why not envisaging a more comfortable scenario in terms of multi-platform capabilities…

I am not here to attack Unity at all I am rather trying to get insights on how a game engine should be built in the best scenario, knowing how technology has evolved nowadays…