The game engine, no. But the game logic, the code that makes the game engine do the things that make what it's doing Halo as opposed to some-other-game-on-that-engine, is written in blamscript.
"Screenwriting" to me would sort-of imply that this was all just for human consumption during planning, and later implemented in something else.
I first meant to use its synonym, "scriptwriting", but that one of course has a somewhat diverged meaning in the computer world. But actually in interactive fiction the meanings beautifully converge again.
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.
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.
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].
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.
>Any sufficiently complicated program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp
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
The 2600 actually did have a BASIC interpreter cartridge available. It was both an incredible engineering feat (interpreter and IDE in 4K ROM and 64 bytes of RAM) and completely useless (because your program only had the other 64 bytes of RAM).
64 bytes is quite a lot if you use it cleverly enough. Sure, it's not enough for media but it's plenty to implement control loops and algorithms... Unless your code had to share that 64 bytes too, I guess.
>The 2600 didn't have BASIC. Not viable with only 128 bytes of RAM.
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).
Atari Age is a great forum, not just for Atari machines either. There's still a lot of hardware and software development for Ataris. Also you might want to check out:
- ANTIC the Atari 8-bit podcast https://ataripodcast.libsyn.com/ (part of the fun here is when those interviewed find out people still use the machines today!)
Both have a lot of interviews with people that worked on Atari hardware and software for ANTIC and all sorts of vintage machines on Floppy days. Randy Kindig, one of the hosts, leads the Indy Vintage Computer Club here in Indianapolis, hopefully are meeting this weekend doesn't get snowed out!
There's also gobs and gobs of stuff, contributed by one of the hosts for the podcasts above, to Archive.org
Other than the games they wrote entirely in GOAL, all of their PS3+ games use a series of lispy DSLs implemented in Racket that get compiled to C and C++ for defining data to be loaded in the game and dependencies between these data, light scripting, dialogues, stuff like that.
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
IIRC, GOOL was a lisp dialect used for scripting Crash Bandicoot; later ND games were written in GOAL (i.e. not just scripting, but the majority of the game was written in lisp).
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.
In our case, we used tcl, but embeddable lisp would have worked too.
I started writing my own embedded scripting language [0], based on Forth and Lisp rather than Lua. Besides being easy to embed, there's not much in Lua worth keeping if you ask me.
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.
