Implementing A Scripting Engine | Hacker News Reader

Implementing A Scripting Engine

flipcode.com

15 pointsfogus9 comments

Blast from the past. Flipcode used to be my favorite site on the web. Note that this article is more then a decade old.

I found the site just recently, after getting interested in demoscene and 3D graphics. Excellent site.

Nice article. It would make sense though, to talk a bit about using existing systems like Lua or Tcl that might meet people's needs better than some one-off system. Explain that it's only a learning exercise.

Also, people might find this interesting: http://www.welton.it/articles/hecl_implementation

Hecl is very simple in some ways, so it's easy to see what's going on.

Well, considering the article is from 1999 (hell, I didn't know FlipCode was still even around these days), "back in the day" scripting game engines was an emerging idea. It was a very rare project that talked about scripting, in most cases they were completely custom scripting languages, and often not Turing complete. Lua gained popularity, but it was slow, the game industry suffers from a lot of NIH.

Ousterhout's ideas and papers had already been out for a while, and Tcl itself had been around for 10 years at that point. So it's definitely a case of NIH.

IIRC, lua was pretty much the first embeddable interpreter that had a memory footprint acceptable in games - both in absolute size (esp. not linking the compiler), and in terms of allocation patterns, as consoles tended to have small direct caches.

I remember several attempts to ship with an existing language (eg: Python, Java). A couple did succeed, but at a large cost.

It was however, pretty easy to sit down with a copy of Kernighan&Pike "The UNIX Programming Environment" and bang out a lightweight compiler/bytecode interpreter that did everything the game needed - keeping precious RAM for gameplay.

It's not. General-purpose scripting isn't necessarily the best choice if the scripting is used only for designer tasks like directing cinematics, movement patterns, simple event-trigger relationships, etc. Between that, the soft real-time requirements, and the historically tiny memory space of consoles, something simplistic and custom is preferable..

Something simplistic: maybe, something custom... probably not. There's nearly always more value in using something that other people use too due to the positive network externalities. Granted, they may be weaker in cases like this where there is not a great deal of code sharing, but one-off languages tend to end up being a burden.

Which is why they seem to have ended up with Lua, which is probably the best fit for that problem domain. Cut down versions of Tcl probably would have been ok, and have been successfully used for things like embedded systems, but probably are more work than Lua, which is 'cut down' by default.

A big part of me feels that it's too bad that integrating a scripting engine todat means linking a library, whereas a decade ago it meant thinking op syntax and building an interpreter. More efficient, of course, but where's the soul? :-)

Reply on news.ycombinator.com