Hacker News new | past | comments | ask | show | jobs | submit login

There is an interesting catch in the C/C++ part of that comment.

Why is the game industry using C/C++?

"Because they need the highest possible performance."

Why do they need that performance?

"To look better than the competition."

Why is looking better than the competition important?

"It sells better."

Why not do other things to sell better and get a better time-to-market with a slower language?

"Too risky."

And the entirety of console gaming has bought into ideologies of low risk, top-to-bottom. The systems are either underpowered or just plain difficult to develop for, the publishers impose boneheaded ideas, and the additional manufacturer requirements increase the costs, but the perceived benefits of a system with low piracy and high retail impact make everyone buy in, again and again. The burden always falls on the developer to suck up the worst excesses and ship something workable. And this in turn encourages a dogmatic developer ideology where one accepts "nobody ever got fired for buying IBM" type stuff because of perceived risk. C/C++ is just one of those things.

I'm inside this system now... and while I like the company and am satisfied with the job, I would love to see it all break apart. It's a nasty system and we get the short end of it.




It's less of a performance thing than a toolchain thing. Especially for 3D games. Right now most libraries are written in c++ so you either develop your own set of libraries or you go with the flow.

There are some chances that this will change in the future:

One is that web-games and games for mobile phones are already written in other languages and maybe the tools from there find their way back into the rest of the game industry. That's probably the best chance for Java. Probably also for Javascript and Flash.

Another is that games use already more and more scriptlanguages on top of C++. And that's a trend that will most likely further increase so C++ get's replaced from the top. Python and LUA are used here a lot.

And a change could also arrives from the bottom up. Smaller games are done in other languages all the time. If those games start growing - and even more important - get done faster, or are bigger than the c++ counterparts then they can eat into the c++ market from below. C# seems to be a big candidate for a language coming from that direction.

The hardware could enforce some change. Most likely concurrent programming will influence the gameindustry as much as it will influence the rest of the programming world within the next decade. Thought I see some chance that c++ might even survive that. Erlang is probably too esoteric for this industry (even though I heard already a few people using it for game servers). And so far I don't know of another language offering there enough features to really lure game developers to switch. Maybe D has some chance, or maybe a new language creeps up.

But certainly there's still the point that c++ is proven to work even for large game projects. You can discuss how good or bad it works, but so far there's simply not many examples for large games done in other languages, so the "too risky" is still a valid point.


Tim Sweeney (Epic/UnrealEngine) did a great presentation a while ago about what his ideal game engine programming language would be like.

http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/doc... (PDF)

It's almost a cry for help, but he explains why they're not using e.g. Haskell.




Applications are open for YC Winter 2022

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

Search: