_Sloppy code vs. "slow" code are vastly different._
Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues.
While you can optimize them after the fact, it's more time you're spending.
_CPU speed has not been the limiting factor in games for a LONG time_
Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage.
_There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_
Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En...
And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well.
But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top.
The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world.
So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.)
If you look at modern games,
I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)
Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues.
While you can optimize them after the fact, it's more time you're spending.
_CPU speed has not been the limiting factor in games for a LONG time_
Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage.
_There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_
Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En...
And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well.
But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top.
The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world.
So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.)
If you look at modern games,
I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)