Live data from Hacker News

Embedding Scheme for a game mission scripting DSL

carloscarrasco.com

11–20 of 26 posts

Re: Embedding Scheme for a game mission scripting DSL

#11

> "The "small Lisps" are truly small, unlike, say, Lua." Well tinyscheme seems to be about half the size of Lua, which is not that different. Lua really is pretty small.

Indeed. TinyScheme being a single file of C code hides this fact at a first glance. I didn't want to diminish Lua, which I find quite good too (I wish LuaJIT was usable on iOS), but I was really looking forward to dive into Lisp.

Re: Embedding Scheme for a game mission scripting DSL

#12
s9fes is another small Scheme that runs on Unixes, OS X, Plan9 & Windows. The code is in public domain and fully described in a very nice book "Scheme 9 From Empty Space: a guide to implementing Scheme in C". It weighs in at roughly 25% more lines than tinyscheme for *.{h,c,scm}.

http://www.t3x.org/s9fes/

Re: Embedding Scheme for a game mission scripting DSL

#13
My kneejerk reaction was "oh my god don't dump a general-purpose language into the runtime just to write mission scripts," but this is actually a good example of how to do it: The DSL defines some data structures that the C++ code uses, and has a direct handoff of the emitted results from Lisp into C++. Lisp doesn't have to interact with every frame of the game.

If you start exposing the engine in arbitrary fashion, things go south rather quickly; the scripting language will never stop finding more things it happens to need to get access to, and then you have an inner platform with boilerplate abstractions that make for worse tooling than whatever you started with.

Re: Embedding Scheme for a game mission scripting DSL

#14
post #7

Earlier quoted context omitted.

Guile LGPL makes it incompatible with commercial games on iOS (because exes are required to be statically linked). However, I think it's one of the best choices on other "more permissive" platforms.

The LGPL doesn't prohibit static linking. You are free to use static linking with the LGPL as long as you make the (potentially modified) LGPL source code and any other components of the linking process available. See section 4 d) 0) of the LGPL: http://www.gnu.org/licenses/lgpl.html In particular, iOS WebKit has been distributed in this fashion. You can download a source tarball from Apple that includes static binar…

Indeed, however, according to the following :

| ... Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work ...

This is practically impossible to do with under Apple Store forcing digital signing of applications (forbidding combined work), even if the developer provides modified source code.

Re: Embedding Scheme for a game mission scripting DSL

#15

Earlier quoted context omitted.

The LGPL doesn't prohibit static linking. You are free to use static linking with the LGPL as long as you make the (potentially modified) LGPL source code and any other components of the linking process available. See section 4 d) 0) of the LGPL: http://www.gnu.org/licenses/lgpl.html In particular, iOS WebKit has been distributed in this fashion. You can download a source tarball from Apple that includes static binar…

Indeed, however, according to the following : | ... Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work ... This is practically impossible to do with under Apple Store forcing digital signing of applications (forbidding combined work), even if the developer…

[deleted]

Re: Embedding Scheme for a game mission scripting DSL

#17
post #13

My kneejerk reaction was "oh my god don't dump a general-purpose language into the runtime just to write mission scripts," but this is actually a good example of how to do it: The DSL defines some data structures that the C++ code uses, and has a direct handoff of the emitted results from Lisp into C++. Lisp doesn't have to interact with every frame of the game. If you start exposing the engine in arbitrary fashion,…

This is completely bog standard in gamedev these days. The embedded language is usually lua, occasionally python.

Re: Embedding Scheme for a game mission scripting DSL

#18
post #3

Embedded programming languages are really cool. Lua's still ruling the roost, as far as I've seen, but there are some nice options out there. I'm currently using mruby for a project and have been quite happy with it so far. The community around it is still somewhat thin, but the code quality is good and development is quite active. https://github.com/mruby/mruby

I read that Io is frequently used as an embedded language. It's really nice, OO and prototype-based little language, definitely worth a look.

Out of interesting Lisp dialects, there's also PicoLisp (http://picolisp.com/wiki/?home) which looks like it should be well suited for embedding, but I didn't find any docs for how to do this with a quick search.

Re: Embedding Scheme for a game mission scripting DSL

#19

> "The "small Lisps" are truly small, unlike, say, Lua." Well tinyscheme seems to be about half the size of Lua, which is not that different. Lua really is pretty small.

Indeed. TinyScheme being a single file of C code hides this fact at a first glance. I didn't want to diminish Lua, which I find quite good too (I wish LuaJIT was usable on iOS), but I was really looking forward to dive into Lisp.

LuaJIT is usable as an interpreter on iOS, just not a jit compiler. It is a very fast interpreter, but obviously this is not ideal (and the ffi is slower without jit).

Android L is also going to kill jit compilers as well alas, see [1]

[1] http://lwn.net/SubscriberLink/609511/53f3d97eed238d55/

Re: Embedding Scheme for a game mission scripting DSL

#20

Earlier quoted context omitted.

Indeed. TinyScheme being a single file of C code hides this fact at a first glance. I didn't want to diminish Lua, which I find quite good too (I wish LuaJIT was usable on iOS), but I was really looking forward to dive into Lisp.

LuaJIT is usable as an interpreter on iOS, just not a jit compiler. It is a very fast interpreter, but obviously this is not ideal (and the ffi is slower without jit). Android L is also going to kill jit compilers as well alas, see [1] [1] http://lwn.net/SubscriberLink/609511/53f3d97eed238d55/

Yeah I liked LuaJIT for the amazing JIT performance and the super fast FFI it enables. Exactly the two things that wouldn't work in iOS. I had no idea Android L was killing JITs. It's a terrible precedent seeing how many dynamic languages depend on a JIT to perform decently.
Post reply on HN