
Show HN: ArkScript, a small and fast language for scripting video games - jackrabbit_
https://github.com/ArkScript-lang/Ark
======
jackrabbit_
A while ago, I was using Lua as a scripting language for my games but wanted
something between Lisp and Python, a language which would run on a VM to be
able to export only the bytecode, and to be able to code in a lisp like
syntax.

And ArkScript was born. I wanted to keep it tiny, under a megabyte, with a few
keywords to do everything.

I think I can say I achieve what I wanted to do, now we are working with a
small team to improve the code, the documentation, and the standard library.
The language is indeed small and fast (even if we can do better, and I'm still
seeking for more speed), with immutability (with 'let'), and closures (note
that we can read the data captured by a closure easily, as a small object,
through for notation: object.field).

~~~
nonbirithm
Interesting project. By chance have you heard of fennel[0]? It is a compile to
Lua language with s-expression syntax. Also I believe you can export LuaJIT's
bytecode with string.dump and it would be portable across platforms. Not
trying to diminish your work, however. This could be useful for having a
"real" Lisp embedded in-game. I don't think I've seen a scripting language
with immutability either.

Would it be possible to write a REPL using ArkScript or use the compiler from
within the language?

Also, I'm really curious how you got so many people to work on the language.
How did you accomplish this?

[0] [https://github.com/bakpakin/Fennel](https://github.com/bakpakin/Fennel)

~~~
jackrabbit_
I've never heard of fennel before, looks interesting!

Yes it's possible to launch a REPL by using the `-r` or `--repl` option when
launching ArkScript executable.

A few people contributing on the language are people I know from some
programming discord servers, and the others came to work on the project after
discovering it thanks to the hacktoberfest tags I put on the issue.

------
gridlockd
Exactly how can a language that's 4x slower than _CPython_ , on the only
benchmark posted, be considered "fast"?

~~~
jackrabbit_
This is a very heavy test of non optimizable recursion, and (benchmark not
published yet) ArkScript is only 2 times slower than JavaScript. It sounds a
lot, but please note that I'm actively working on improving those numbers, and
I'll add other benchmarks (fast allocations of lists and more) to have a
better idea of what the language is capable of in term of speed.

~~~
gridlockd
> This is a very heavy test of non optimizable recursion, and (benchmark not
> published yet) ArkScript is only 2 times slower than JavaScript

That statement does not help. Which implementation of Javascript and what kind
of benchmark is only 2x faster?

For starters, here is a good overview of Javascript interpreter performance:

[https://bellard.org/quickjs/bench.html](https://bellard.org/quickjs/bench.html)

~~~
jackrabbit_
Woops sorry

I used the Ackermann Péter fucntion, still the same parameters (3, 6), on
spidermoney (js engine for Firefox 74.0, windows 10, i7 8k)

Thanks for the link, I'll definitely dig down into that!

------
hardwaresofton
I'll be very surprised if game scripting languages don't all devolve to
whatever-compiles-to-webassembly. Not only will choices be more plentiful but
the ecosystem will be stronger and safer than what any individual author could
built before long.

~~~
gridlockd
I'd predict the opposite. Game developers tend to be hostile towards web
technology. _Not_ having that ecosystem in your pipeline is a bonus. Safety
isn't something game developers value highly.

WASM would just make everything more complicated for no good reason. You can't
do JIT-compilation on the consoles or iOS, so it's not going be performing any
better than a simple interpreter.

If you go the interpreter scripting route, what you really want is trivial and
comfortable binding to native (engine) code. You likely want your engine
functions to be intrinsics in the VM.

Otherwise, you'll want to go the AOT compiled scripting route, which offers
better performance. Then you just do the "scripting" in C++ (UE4) or C#
(Unity).

~~~
WorldMaker
Slightly tangentially, as someone that worked on games entirely in C# more
than a decade or so again, it still sometimes makes me sad that most C# work
in games is just Unity scripting today.

C# is a very performant and efficient language that I thought a lot more games
would be written in top-to-bottom today, at least in indie circles. (Sure,
performance tuning C# is a different art to C++ performance tuning, but it is
a very similar art [know your data structures, keep an eye on your
allocations, pool memory where you can].)

That "Safety isn't something game developers value highly" says a lot about
why that C# bubble popped and C# right now is "merely" that weird scripting
language choice for Unity.

------
bullen
You can script in C:
[https://www.youtube.com/watch?v=WMSBRk5WG58](https://www.youtube.com/watch?v=WMSBRk5WG58)

------
Kiro
OT but why do you need a separate language for scripting? Why not just use the
same language as you use for the rest of your game?

~~~
mhh__
Game logic can then be implemented in a safe, "clean" language where game
designers can't break the underlying game engine.

It's also partly due to C++ being the Lingua Franca of game development - if
it were a slightly less complicated/difficult to deploy language you could use
both (I have built a toy GUI app that live compiles D code into an object
file, and calls an entry point with a nice OOP interface into a made up data
structure, it worked pretty well but I don't know much about games so I don't
have much use for it). C++ is also ridiculously slow to compile (at it's
beautiful worst) so having AI logic (say) in the main codebase is a bit of an
issue for designers.

~~~
k__
I also saw a Rust game engine using a scriping language that leans heavily on
Rust concepts.

I think the scripting language was called Dyon.

