Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Thanks for the response.  It's reassuring to know I have some idea of it should work over all.

I guess how you expand the project depends on the focus you want to take.  I get your initial goal was to make your own high level scripting language, and it looks like you've succeeded.

I like how you tried to push it to its limits as well.

I'm not aware myself of a scripting language flexible enough to be performant without a VM or similar set up, but it would definitely be interesting if there are other ways of doing this.

It also sounds like you made your own console application?  Would there be a way increasing the capability of the console to run more like a VM for scripts read from file over using command line input?  This could maybe include more instructions, more variety or more granularity for loaded scripts, vs simpler instructions from direct input to try to manage process times between the 2 approaches?

(1 edit) (+1)

You're welcome and thank you for your appreciation!

Yes, I definitely succeeded in making a scripting language that fits its purpose. But yeah, at some point one wants to expand even more. :D

For performance, you cannot really avoid a VM. For games I think the so called phenomenon of amortization solves it. You trade one cost of just-in-time compilation to byte code for your VM, but gain large performance improvements for scripts that run for a longer period of time, which applies to games. The cost of compilation is amortized by the runtime performance improvements. If you want to even go further, you can use ahead-of-time compilation, however this goes with the development cost, as you would always need to recompile before testing. Or you support both ways, JIT for dev/debug and AOT for release builds. :D 

The console application is basically just a REPL, which means you can interactively execute script code or enter commands, similar to cmd.exe. It's basically just a user interface. The heavy work happens mostly behind curtains, so to speak. The host application however can also be launched with providing a path to a script to be executed. If that's the case, the REPL is hidden and the host application exits once the script has finished. So, if you want to type in some script commands, you just launch the shell. If you just want to execute a script, you launch the shell with the path to the script - and optionally arguments that can be provided to a script.