
Implementing A Scripting Engine - fogus
http://www.flipcode.com/archives/Implementing_A_Scripting_Engine-Part_1_Overview.shtml
======
xal
Blast from the past. Flipcode used to be my favorite site on the web. Note
that this article is more then a decade old.

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

------
davidw
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.

~~~
moron4hire
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.

~~~
davidw
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.

~~~
chipsy
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..

~~~
davidw
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.

------
wlievens
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? :-)

