A quote from J. Carmack's QCon 2009 speech

(CmdrRozqrwix) #1

“One of the lines that I’m still not sure whether we crossed though, is script heavy versus code heavy. Because we did go through this with Doom 3, where Doom 3 had a lot of things in script that, by the end of the project, were like, “Oh, this was an awful mistake.” You know, lots of AI and animation, and, unfortunately, we didn’t convey that message well enough to Splash Damage, where Splash Damage went off and did a whole bunch of more stuff in script, and we were like, “Oh, we should’ve told them we figured that was a bad idea by the end of the project.” You know, in terms of performance, debugability, maintainability, and all that.”

So, I take it SD didn’t get the memo yet?

(Nail) #2

and yet most PC players love it, funny huh ?

(CmdrRozqrwix) #3

There’s this saying about millions of flies that couldn’t possibly be wrong.

(Wieke) #4

<insert statement regarding computational power of pc in comparison to consoles here>

Couldn’t they have warned Splash Damage about it? You know a bit of information regarding your own product (they made the damn engine after all). Also scripts are slower than code? [sarcasm] Who would have thought it? [/sarcasm]

(RR2DO2) #5

We definitely knew scripts were being slow before release, but they did provide some benefits too. To aid performance, digibob wrote a script to C++ converter, which is why ETQW was using natively compiled scripts in its release. Co-routines are used to simulate script-like flow behaviour. Performance is not much different from any other native code.

For Brink we went one step further, keeping the co-routines but writing all the ‘script’ code in C++ natively in a separate module. This has all the benefits of debug-ability, script like functionality as well as performance.

(Codine) #6

[QUOTE=Wieke;304272]<insert statement regarding computational power of pc in comparison to consoles here>

Couldn’t they have warned Splash Damage about it? You know a bit of information regarding your own product (they made the damn engine after all). Also scripts are slower than code? [sarcasm] Who would have thought it? [/sarcasm][/QUOTE]

This isnt SD’s first idtech 4 game though so they really don’t have an excuse.

(SockDog) #7

[quote=RR2DO2;304291]We definitely knew scripts were being slow before release, but they did provide some benefits too. To aid performance, digibob wrote a script to C++ converter, which is why ETQW was using natively compiled scripts in its release. Co-routines are used to simulate script-like flow behaviour. Performance is not much different from any other native code.

For Brink we went one step further, keeping the co-routines but writing all the ‘script’ code in C++ natively in a separate module. This has all the benefits of debug-ability, script like functionality as well as performance.[/quote]

If anyone needs me to translate this into layman’s terms I’ll happily take the infraction. :slight_smile:

(SphereCow) #8

Hi. My name is Codine. I don’t read what informed devs say, but I do read what uninformed, quote mining randos say.

(gonintendo) #9

Please. :smiley:

(mortis) #10

[QUOTE=RR2DO2;304291]We definitely knew scripts were being slow before release, but they did provide some benefits too. To aid performance, digibob wrote a script to C++ converter, which is why ETQW was using natively compiled scripts in its release. Co-routines are used to simulate script-like flow behaviour. Performance is not much different from any other native code.

For Brink we went one step further, keeping the co-routines but writing all the ‘script’ code in C++ natively in a separate module. This has all the benefits of debug-ability, script like functionality as well as performance.[/QUOTE]

ownt

PS Digibob really enjoys scripting, according the commented out sections of the goldrush script…heh.

(CmdrRozqrwix) #11

[QUOTE=RR2DO2;304291]We definitely knew scripts were being slow before release, but they did provide some benefits too. To aid performance, digibob wrote a script to C++ converter, which is why ETQW was using natively compiled scripts in its release. Co-routines are used to simulate script-like flow behaviour. Performance is not much different from any other native code.

For Brink we went one step further, keeping the co-routines but writing all the ‘script’ code in C++ natively in a separate module. This has all the benefits of debug-ability, script like functionality as well as performance.[/QUOTE]

And yet the feel of Doom 3 and Quake 4 is entirely different. Unlike ETQW and Brink, they’re not jittery, laggy, and warpy when running at 120FPS with perfect ping and no packet loss; the animations in those games are extremely smooth, everything seems stable, and polished, just as expected from a product deemed ready for release.

I don’t know what it is that you did to your games to make them as jittery and as laggy as they are, and the specifics are of no importance to the paying customers. From a gamer’s perspective, the thing that actually matters is the end result, and the end result in case of both of your latest games is pretty damn poor.

(SphereCow) #12

I actually had really stable gameplay with ETQW, save for the 30 fps anim cap that was a godawful decision.

Dunno what you’re on about.

(gonintendo) #13

[QUOTE=Luddens Desir;304445]I actually had really stable gameplay with ETQW, save for the 30 fps anim cap that was a godawful decision.

Dunno what you’re on about.[/QUOTE]

When the framerate isn’t too low, this game looks and feels great. I don’t see any of the jitter that he’s talking about. As soon as this game is running the way it should, it will be perfect.

(r5ada) #14

[QUOTE=CmdrRozqrwix;304426]And yet the feel of Doom 3 and Quake 4 is entirely different. Unlike ETQW and Brink, they’re not jittery, laggy, and warpy when running at 120FPS with perfect ping and no packet loss; the animations in those games are extremely smooth, everything seems stable, and polished, just as expected from a product deemed ready for release.

I don’t know what it is that you did to your games to make them as jittery and as laggy as they are, and the specifics are of no importance to the paying customers. From a gamer’s perspective, the thing that actually matters is the end result, and the end result in case of both of your latest games is pretty damn poor.[/QUOTE]

Yeah but I would disagree. ETQW is a different story, I wasn’t a big fan, it was just okay. I enjoy Brink, it’s not without it’s flaws but to me it’s a high quality title.

(abjectblitz) #15

[QUOTE=Luddens Desir;304445]I actually had really stable gameplay with ETQW, save for the 30 fps anim cap that was a godawful decision.

Dunno what you’re on about.[/QUOTE]

You know exactly what he’s on about, you just mentioned it. That godawful decision has been plaguing the outcast branch of engines since Q4.

I’m guessing here, but it seems the internal rendering of physics and animations is screwed and makes the whole game jittery. A decision that had plagued the SD developed branch of engines. JC should have stepped in and told them to stop this BS.

The best branch was the D3D version Raven did for Wolf SP.

(Nail) #16

I’m pretty sure sockdog isn’t the only one to understand RR2DO2’s intent with that post

(master[mind]) #17

[QUOTE=RR2DO2;304291]We definitely knew scripts were being slow before release, but they did provide some benefits too. To aid performance, digibob wrote a script to C++ converter, which is why ETQW was using natively compiled scripts in its release. Co-routines are used to simulate script-like flow behaviour. Performance is not much different from any other native code.

For Brink we went one step further, keeping the co-routines but writing all the ‘script’ code in C++ natively in a separate module. This has all the benefits of debug-ability, script like functionality as well as performance.[/QUOTE]

And so Splash Damage makes Carmack look like a n00b with his own engine…

I’m impressed, better performing than Quake C…do you implement script related calls and objects with a library, are they defined on the spot(i.e. in the script file), or do you couple the generic “scripting” calls with the actual object it’s associated with?

(CmdrRozqrwix) #18

I see you’re already quite adept at controlling your gag reflex, but if you want to get chatty with the devs, I’m afraid you’re going to have to try and get it in a little deeper still. :eek:

(engiebenjy) #19

I think they compile the C++ with the reflux capacitor by scripting a generic library call from inside an object, or something of this nature

:tongue:

/me giggles at how funny i am