On the other side of this, I see a lot of discussion in the gaming community lately about taking up languages other then C++. You should go read up on some of John Carmack's thoughts, or even take a look at the guys who wrote Go, and why google is dumping a lot of their C++ code.

IMO large complicated C++ programs are not something humans can reason about effectively. Bullet is pretty clean, it's complexity is just par for the course for a large C++ library that's been around a while.

In my experience AAA games get more complicated then they need to be, because of the timelines that have to be met and the shortcuts that get taken. It's almost impossible to not have some really crazy stuff after 2-3 years of tight deadlines. That leads to code that is complicated to reason about when it really shouldn't be. Not because of bad developers, but because you just can't crank out good abstractions around C++ code at that pace. The number of C++ codebases in the game industry that people look at and say 'that's really good code' is tiny, I could probably count it on half a hand. But on the other side it got a lot of games to production and satisfied millions of users, so who's to say what the best approach is?

Chris

I found Bullets code pretty easy to read, it is fairly basic C++.

Most AAA game engine code is garbage. Hacked together under deadlines and generally using outdated or overly simplistic standards.

Lots of people would love a better C++, but there isn't one yet. Go = garbage. D = not ready. Haskell = not ready.

snacktime - what language would google be dumping C++ for?

Also Rob there is no reason to be using an old compiler like 2005, grab 2013 RC, it is free, has at least moderate C++11 support, a better/faster IDE, and of course produces much more optimal code(especially when dealing with SSE, where older compilers like 2005/2008/2010 were utter trash).

snacktime - what language would google be dumping C++ for?

Also Rob there is no reason to be using an old compiler like 2005, grab 2013 RC, it is free, has at least moderate C++11 support, a better/faster IDE, and of course produces much more optimal code(especially when dealing with SSE, where older compilers like 2005/2008/2010 were utter trash).

When I worked on AAA games the actual engine code is usually pretty stright forward. The diffcult to understand hacky stuff was usually in the AI and Gameplay code because it was considered as throwaway code.

If you think game code is obscure try working on a high frequency trading platform for a large bank that is a polygot mish mash of at least 11 different languages (not including where the odd developer has used some obscure domain specific language) with 500 programmers working on various bit of it at any one time.

If you think game code is obscure try working on a high frequency trading platform for a large bank that is a polygot mish mash of at least 11 different languages (not including where the odd developer has used some obscure domain specific language) with 500 programmers working on various bit of it at any one time.

Imagine being the lead of the performance lab and being told to improve transaction speed by 15% to meet the SLA within 1 week, which includes creating the load tests from scratch.

Or, Imagine being a senior role in a medical billing processor and make it HIPAA compliant while supporting multiple brandings in different languages, while also trying to speed it up to get an EMR certification that would cost the company millions if it's not done.

Honestly though, it's a pay thing. Is being a business developer 2-3 times as hard as being a game dev? Of course not. But with the whole corporate poaching environment, companies that need business developers will pay more for talent. Also the skill sets required between business devs and game devs aren't really the same, so spaghetti code between game devs/business devs are very different. I don't think I've ever had to use extensive math as a business dev, if I was a game dev I'd had to live by math. In fact, that requirement alone would probably drop me from a senior level developer to an intermediate level one.

Has anyone done a study on how well horizontal transfers go from the business programming environment to the game dev environment?

Has anyone done a study on how well horizontal transfers go from the business programming environment to the game dev environment?

Phrases such as "horizontal transfers" don't go down well with games developers. Smells like BS Bingo.

Yeah, you're right, nonsense like that will just get in the way of work. For example, tomorrow I'll probably spend most of my day looking at a soft lock, that we're worried might be a show-stopper or a cert issue at 1st-party. I can repro the lock in debug on the dev server, but the trace looks different from release on prod, even configed for logging to be full debug. If it's going in a patch I'll have to get another depot synced down and push a build out to a few kits, to regress my fix on that branch. All this is delaying the TDD I need to write about refactoring some data into server-side replication. If I don't get on that soon my burn-down won't look good and I'll have to talk with my scrum master.