andrewj
Senior Member
Posts: 1380
Registered: 04-02 |
RjY said:
I'm pretty curious about this COAL thing, motivations for inventing yet another script language, why it's better than lua, etc.
Major reason #1 : It is hard to save/restore the VM state with Lua (to implement savegames). It is not part of the standard Lua code (which kinda proves that it is not easy), and at the time I made the switch the best Lua library for doing this, Pluto, was years out of date, though funnily enough a major update of Pluto came out some months later. I was also doubtful that if something was wrong with that serialization library, I wouldn't have the expertise to fix it myself, especially regarding stuff like Lua's closures and co-routines.
Major reason #2 : Lua scripts can use a lot of memory without any limit placed on you. Tables can be trivially created in the syntax with {}. I think this is bad in the context of a game engine, for one thing this can potentially lead to really huge savegames (and hence slow to load and save). Plus I think limits are generally needed in a game engine to ensure some level of consistency between two different computers or even two different maps.
Major reason #3 : I wanted a scripting language for the game sim which would be a good fit for client/server networking. QuakeC and entities are a system proven to work for that, whereas I had trouble envisioning how Lua could be used to do the same thing. COAL ended up being just for HUD drawing, though it was planned for the game sim too.
Minor reason : concern about the garbage collector causing pauses in gameplay. I have a feeling this would not be an issue, but the risk was always there.
|
12-28-10 09:01 
