"Screenwriting" to me would sort-of imply that this was all just for human consumption during planning, and later implemented in something else.
It was written in assembler: http://atariage.com/forums/topic/185693-halo-2600-source/
BASIC Programming, Model# CX2620. I have 5 or 6 of the carts (not sure off the top of my head, I never touch my 2600 stuff, only my 8-bit computer stuff. My daily driver is one of my 800xl's with s-video out and a Rambo 256k).
>It was written in assembler
I stand corrected.
There's a talk by one of the engine devs at RacketCon from a few years ago on youtube about how they use these DSLs and how they came to be: https://youtube.com/watch?v=oSmqbnhHp1c
Certainly my favorite Lisp game.
I find this quote especially true in games.
I call BS on that one. I have worked on very large scale C++ software (games etc.) and have never seen or needed anything like Common Lisp to get the job done. And I actually know how to program in Common Lisp (and Scheme) and have implemented my own Lisp variations for fun.
That's not the point. It's not half a Common Lisp, but half of (the features) of Common Lisp: code generation/macros, runtime scripting language, loading of code, interactive error handling, a console to interact with the program, dynamic objects, exchanging data in a textual format, a configuration language, etc. etc
It wasn't the most friendly language and ended up with many c like additions. At the end of the day it was all about cost to work on and efficiency of using.
Many would have been super happy to slap a "real" language in there but they would have spent years putting the real time esque controls they needed on it. Not the normal real time but bound to game engine execution phases which is different. It also needed to very easily work with cpp and the art tree.
I doubt any of the fp folks here would have loved the language and would have spent much of their kvetching time on why it wasn't more lispy and therefore more productive.
Thing is most of what it needed to do was atomic thread and mutex/semaphore joins, branching parallel green threads and parallel wait conditions and goto. The scripts were all written by non programmers and when slow converted to c++ which was about 20kx faster.
Modders also use it in custom multiplayer maps for things like doors. Since Halo PC's netcode doesn't synchronize the state of such scenery to players, some map makers came up with the clever idea of hidden "biped crusher" rooms which repeatedly dropped vehicles on NPCs depending on the state of doors. Their respawns _were_ synchronized across the network, so this system could be used to trigger doors opening/closing on clients.
In our case, we used tcl, but embeddable lisp would have worked too.
I know Unreal Tournament 99 and especially 2004 was very extensible because they offered uScript (very C++ like) which made it easy to make all sorts of mutators and mods. They even had a specific feature for making in-game cutscenes (I thought it was named Kino but apparently not).
I don’t have much knowledge of Source but afaik they also offered something similar.