HN Explorer

24 comments

[ 3.3 ms ] story [ 56.2 ms ] thread
klodolph
QuakeC served its purpose in Quake but there’s a reason it was ditched for Quake 2… it was a bit of a hack and wasn’t really the kind of fully-thought-out system you’d want to build on. Of course that’s fine—Quake shipped and was extremely moddable. I just wouldn’t want to build anything else on QuakeC.
aliswe
Making a VM for a game does sound like overengineering
kgeist
It allowed modders to write mods without having to deal with unsafe DLLs. I was basically just a scripting engine.
klodolph
I believe that QuakeC is also unsafe. It is portable, though.
smcl
Possibly. Nowadays we might look towards existing languages like Lua if we wanted to bolt on a scripting system to our new game engine. But remember that in the mid-90s id and Carmack were breaking new ground and had to figure this out as they went along. It might have been overengineered if the result was simply that they shipped a single game, but we know now that what they built was a very powerful, customisable platform that spawned hundreds of mods and kickstarted possibly hundreds/thousands of people on the path to careers in the games industry.

So it's maybe a bit overengineered for Quake the game, but it turned out to be perfect for Quake the ecosystem (and everything that followed) to emerge :)

srgpqt
Many, many games ran a VM for the game logic to ease porting between vastly different computer/console architectures. See SCUMM VM for example.
bob1029
Making a VM for a game is one way to build an abstraction layer between parts of the business. Having everyone working in the low-level C/C++ codebase all the time can scale poorly.
bowsamic
Back in those days, there were not pre-built solutions for things. It isn't like the option was between a professionally constructed engine and writing your own, whatever you had to do you had to write it yourself. In such an environment it makes sense to spend a lot of effort on custom engineering.
flohofwoe
The implementation is under 750 lines of trivial C code, much less than for instance an embedded Lua interpreter (which just barely existed back then). I would call that the opposite of "overengineering".

Also, this wasn't used for the entire game, only for the parts that are moddable.

jhbadger
Some of the very first computer games such as the Infocom text adventures (Zork, etc) were VM-based. That was because there were like a dozen incompatible home computers in the 1980s and writing their games to target a VM meant they just had to write a VM interpreter for each platform and all of their games were ported.

https://en.wikipedia.org/wiki/Z-machine

miramba
QuakeC always reminds me that Carmack was a genius and I am not. I mean, besides writing a almost fully customizable 3D-engine and a mulitplayer stack, he created a program language for game control, including a compiler. I home-studied it all back in those days, but even today with all my experience I still couldn‘t build any of those things… so congratulations to the author, even if I don‘t quite see the point.
sigjuice
Would have been nice to stop at the last comma.
smcl
Don't sell yourself short, I imagine you could achieve a lot more than you think! It's just a case of breaking the problem down, simplifying accordingly and (probably the most difficult bit) finding the time to sit down and work on it. There are some DIY courses that could even be followed and mashed up to approximate a scriptable "3D" engine with a bit of creativity. You could familiarise yourself with building a simple compiler + VM for a little language by following "Crafting Interpreters" (https://craftinginterpreters.com). For the engine side of things someone recently posted this "DIY Doom" over @ https://github.com/amroibrahim/DIYDoom which looks like a bit of fun.

I mean it's a bit tougher to do it all completely from scratch, but remember John Carmack didn’t just sit down one day, open a blank text editor and say “I’m going to make Quake” - he started with game dev years before, built 2D platformers, built Wolf 3D, then Doom. With the tools and docs we have at our disposal nowadays, I reckon most HNers could get quite a lot of the way towards Quake if they could dedicate the time to the task :)

matttproud
As a former QuakeC hacker and id engine spelunker, I think this is great. A parsimonious codebase here is to be welcomed. The original engine was littered with globals and cruft. Reasoning with the original implementation took considerable effort.

Unless you were playing the game at the time, it’s impossible to comprehend how important QuakeC was. It lit afire an ecosystem of modifications, some of which became full-fledged independent franchise of their own like Team Fortress. If you ever played with DOOM’s Dehacked, QuakeC is absolutely next-level.

For me personally, it amplified my interest in programming in a way nothing before it had. And that’s not counting the number of people who used QuakeC as a way to develop their own skills and create their own names for themselves in the game development industry.

1996-7 represents a golden period of hacker innovation and exploration.

wink
I guess I was simply too young (and not motivated enough), but QuakeC was kinda impenetrable for me and my online research didn't really yield a lot of good resources.

So I guess you're right, and a friend's older brother and his friends did some stuff that looked cool but it was one of those "nope" learning experiences for me.

barryp
I had a huge amount of fun back in those days messing with QuakeWorld and Quake2, learned a ton of stuff.

One project was embedding a Python2 interpeter in QuakeWorld, along with a QuakeC->Python translator. The translator and the resulting Deathmatch and CTF games are here: https://github.com/barryp/qwpython

The other was embedding a JavaVM in Quake2, and instead of trying to translate the C game logic, we recreated the whole thing from scratch in an object-oriented Java fashion: https://github.com/barryp/q2java

Thanks to Carmack for opening up those old engines, that was a real education.