Meanwhile, Half-Life/GoldSrc/Source scripting means placing "entities" in the world space and connecting them. Like a very messy form of visual/block-based programming. On many maps with a lot of scripts there are separate, inaccessible rooms where the mapper stashed all the entities, because placing them where their triggers / effects happen would make editing the level geometry quite difficult.
We had this at another Sony studio I worked at. I asked why. The person who write it said writing the interpeter/compiler for lisp is quite easy. As is understanding the byte code. They did it as an intern project in about 3 months.<p>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.<p>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.<p>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.<p>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.
The title is misleading. Blamscript is only really used in the interactive consoles of the game and its editing kit, and the scripting of encounters, cinematics, and triggers in the campaign[1].<p>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.<p>[1]: <a href="https://github.com/Dwood15/HaloScripts" rel="nofollow">https://github.com/Dwood15/HaloScripts</a>
>Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp<p>I find this quote especially true in games.
Meanwhile, Halo 2600 was written in Atari BASIC (probably) <a href="https://atariage.com/store/index.php?l=product_detail&p=998" rel="nofollow">https://atariage.com/store/index.php?l=product_detail&p=998</a>
This seems like a pretty typical pattern: Back when I did games (mid 90's), it was pretty essential to come up with a tight game engine with components that could be driver from a script: That way someone in design/production could focus on making things interesting and fun without needing to mess with a compiler.<p>In our case, we used tcl, but embeddable lisp would have worked too.
Don’t most engines offer this by default?<p>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).<p>I don’t have much knowledge of Source but afaik they also offered something similar.