Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Brief rant:

Quake 1 ran a virtual machine, which QuakeC compiled down to. Quake 2 ran native code via DLLs. Quake 3 ran either VM code or native code--depending on how clever you wanted to be, you might need to break into the native code.

There wasn't some "mistake" about using scripts-vs-code, because they would actually compile down to executable bytecode. This made it much easier to load mods over the network if you needed to, and to port their tech to different architectures.

idTech 1-3 internally were a lot more like VR operating systems than scriptable game engines.

and the limitations of scripts, outweighs any gains from being "easier to edit"

Wrong, wrong, and wrong. The mod scene flourished back in the day specifically because it was so easy to bodge together mods in these friendlier environments--especially in the Unreal series.

The place where scripting falls apart is in modern AAA games where way too much stuff is expected of/exposed to designers, and then you end up with gigantic sprawling piles of poor performance. A friend worked with a licensee of the Unreal engine for a few games, and their script dispatch switch went on for...well, let's just say that many good programmers lost many good hours in those mines.

Scripting is a perfectly good tool, and one that makes sense until you start doing crazy AAA stuff with it.



As a Doom 3 modder myself, I experienced considerable headaches juggling the interplay between scripts and code, especially since so much stuff (like firing a gun or moving around) spanned the two systems so inelegantly.


I think it was handled somewhat better in older engines.

Doom3 seemed a bit of an odd duck.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: