When to use scripting languages?

[TheCreator]

You only need to write the interface to use a script once while you may need to rewrite the script's code any number of times.  Writing an interface is obviously not twice the work, and if you're getting a lot of practice it becomes easier and easier to the point where it's just completely natural to tack on the interface at the end.

Okay, but doing so with 100% of your game logic completely distorts the main idea of scripting, which is getting rid of mundane, repetitive tasks (eliminating the need for recompilation is another thing, not so important actually, at least not if you write in Java or C#). Now if 100% of your logic is in the scripts, you suddenly have twice as much code. You will have to maintain that code. You will have to debug, profile, refactor and so on. And guess what? You will have to use a different set of tools for your "low-level" language and for the scripting language. Different debugger, different profiler, different syntax parser, etc. Does that make life any easier for you? Just imagine that you need to fix a bug and you don't know whether it is in the script or in the "low-level" code. What would you do? Run the debugger for the scripting language (assuming that it exists, which is not so obvious) and the "low-level" debugger at the same time? That must be fun.

[SomeGuy]

My main motivation is I find programming java tedious. Not as tedious as most other C-likes but still painful a lot of the time. However, it's fast, portable, has excellent tooling, and great profilers.

I guess tbh compilation speed is not a huge issue with java, it's pretty good at compiling only part of a project.

Anyway, I tore my hair out trying to embed jruby. The documentation is really shoddy. I'll leave it for now until it comes time for quests and complex AI. Just java and yaml.

You may be interested in Lua Programming Language with LÖVE engine, allowing you to create any kind of 2D or 2.5D game and freely redistribute it, with great API documentation and very active and helpful community.

[kraflab]

You only need to write the interface to use a script once while you may need to rewrite the script's code any number of times.  Writing an interface is obviously not twice the work, and if you're getting a lot of practice it becomes easier and easier to the point where it's just completely natural to tack on the interface at the end.

Okay, but doing so with 100% of your game logic completely distorts the main idea of scripting, which is getting rid of mundane, repetitive tasks (eliminating the need for recompilation is another thing, not so important actually, at least not if you write in Java or C#). Now if 100% of your logic is in the scripts, you suddenly have twice as much code. You will have to maintain that code. You will have to debug, profile, refactor and so on. And guess what? You will have to use a different set of tools for your "low-level" language and for the scripting language. Different debugger, different profiler, different syntax parser, etc. Does that make life any easier for you? Just imagine that you need to fix a bug and you don't know whether it is in the script or in the "low-level" code. What would you do? Run the debugger for the scripting language (assuming that it exists, which is not so obvious) and the "low-level" debugger at the same time? That must be fun.

Sounds like you didn't read my original post completely.  Anyway, there are no mundane/repetitive tasks in coding, only bad programmers You may write a single 'interface' that works with any number of scripts, so you really need to get away from this 'double code' idea.

[TheCreator]

Sounds like you didn't read my original post completely.  Anyway, there are no mundane/repetitive tasks in coding, only bad programmers You may write a single 'interface' that works with any number of scripts, so you really need to get away from this 'double code' idea.

Let's make it clear: I'm not speaking about code duplication here. Duplication is an issue in itself, but only a minor one. All I wanted to say is that by moving all your logic into scripts you make the maintenance process a lot more complicated, and that's everything but speeding up the development.

[TSMI]

My main motivation is I find programming java tedious. Not as tedious as most other C-likes but still painful a lot of the time. However, it's fast, portable, has excellent tooling, and great profilers.

I guess tbh compilation speed is not a huge issue with java, it's pretty good at compiling only part of a project.

Anyway, I tore my hair out trying to embed jruby. The documentation is really shoddy. I'll leave it for now until it comes time for quests and complex AI. Just java and yaml.

You may be interested in Lua Programming Language with LÖVE engine, allowing you to create any kind of 2D or 2.5D game and freely redistribute it, with great API documentation and very active and helpful community.

While I do like the lua language, I don't want to abandon the jvm, or the great IDE support for java. Netbeans is a boon for someone like me who constantly changes variable names lol

[MorleyDev]

Well an important question in coding, one of if not the most important, is 'where does this functionality belong?'. When a piece of code (be it function or class or even application) starts developing an awareness of the world beyond it's very discrete purpose, that is a flashing neon sign that it is time to refactor.

So similar to how you refactor to introduce a configuration when it becomes clear a piece of information doesn't belong in the code, you will introduce scripting when it becomes clear that behaviour has no place in the code.

Where that line lies will depend on a lot of factors so is mostly a judgement call. Experience or requirements for a project can allow or force you to make that call early on. But in the absence of those, it simply becomes a matter of 'when it becomes appropriate'.