JPthere it is again... the desire for a Quake port with a totally different QuakeC architecture where scripts can be included in any mod pk3 and loaded at runtime, and multiple paks stomp previously loaded ones, allowing a "game -> mod -> mutator"-like architecture, and throw in some basic OO for doing things like entity class replacements... people could make so much good stuff with that. keep everything else the same but uplift the modding tech to zdoom + zscript parity basically.
of course, if one were bothering to do this you'd probably want to fix and improve various things about QC as well, if not replace it entirely with a mature scripting language, or most extravagantly write a multi language backend to allow QC for back compat and eg Lua for future-facing work... so long as we're dreaming and all.
mcc@jplebreton Hypothesis, based on no specific knowledge of this application: QuakeC is probably designed around what was "easy to implement" (e.g.: what carmack could implement with an economy of code; he has a bias toward architectures which are in this sense "elegant") and therefore it might be easier than some other scripting systems to yank out and shove in an entire other system without noticeable changes
@mcc possibly! i actually haven't looked at the code much but it's from 1995 and probably not super complex and relatively easy to follow.
Richard Barrell@jplebreton @mcc I wonder if anyone is putting wasm into games because it's "easy" for 2025?
I'm sure that's one of the reasons why Lua has been being put into games for decades, and not undeservedly.
I'm sure that's one of the reasons why Lua has been being put into games for decades, and not undeservedly.
reimu stallman@jplebreton quakeCpp?