Why are games using interpreted languages instead of compiling code into libraries and calling them at runtime?

Question

Say I want to include a game mechanic where players are invited to code up some algorithm to control robots which would defeat the enemy and protect the tower efficiently. Most games I've seen to implement something like that, support Lua. But what if they accepted a .Net compiled library with implemented in C# (or Java for example) interfaces, essentially doing the same thing? How is it a better or a worse choice?

Code may (not) compile in either case. Some players may (not) be familiar with one of the languages. The computer may not have .Net (or Java) framework installed (but then the game usually comes with at least some redistributable packages, so it may as well include those too). These obvious arguments go either way. Is there some important reason that interpreted languages are the norm, and not compiled which I'm not aware of?

That talks about development, I'm talking about the things you do while already playing the release version. — user1306322, Sep 26 '16 at 15:43
I understand that, however I feel like some, if not most, reasons are the same in both. — , Sep 26 '16 at 15:45
I don't think so. There's no need to "recompile the whole game" in either case, the engine is designed to be decoupled from the user's implementations, either by exposed interfaces, or variables. In both cases coding happens while you're playing the game, so "run-time" essentially, save for negligible compilation time. — user1306322, Sep 26 '16 at 15:47
When asking a question, you'll typically try not to include the answer in it. (C.f. This help center page, "your answer is provided along..."). — Vaillancourt, Sep 26 '16 at 16:12
Otherwise I'd be at risk of not showing prior effort. It's a double-edged sword and this edge seemed less sharp. — user1306322, Sep 26 '16 at 16:35

score 5 · Answer 1 · edited Apr 13 '17 at 12:18

Generally compiled languages are avoided as scripting languages because of the overhead of compiling them. Many of the points in the answers to Why do we use scripts in development? are relevant (even though I agree your question isn't a duplicate).

Primarily the choice comes down to iteration speed: it is (often) way faster to omit the compilation step entirely to achieve quicker turnaround times for testing new features or tweaking existing ones during development. When it comes to then exposing that scripting mechanism to players as a core gameplay feature, why switch to a different language?

The overhead of the interpretation or JIT-compilation or whatever used by the scripting language is usually not sufficient enough to warrant switching out the entire scripting technology stack to one that is pre-compiled when ship time rolls around. Particularly since that new technology stack probably hasn't been battle-tested and stressed during development nearly as much as the "interpreted" option everybody was using up until ship time.

As an extreme over-generalization, languages designed to be compiled offline tend to be heavier-weight and more cumbersome to integrate (and lock down) as scripting languages as well, including when it comes to debugging tools. When that generalization holds, that often contributes against that language in the cost/benefit analysis.

I'd add onto this to say that in games where "players are invited to code," they're usually writing one-off gameplay logic or event handling. The type of thing that runs only a handful of times in any frame - not millions of times like particle systems or rendering or physics simulations. So, even if it's executed with less-than-optimal efficiency, it's rarely the determining factor in game performance. Time spent making user scripts compile to native code might be more productively spent tuning core game & engine systems instead, for more performance payoff. — DMGregory, Sep 26 '16 at 20:23

Why are games using interpreted languages instead of compiling code into libraries and calling them at runtime?

1 Answers1