So I've been merrily chipping away at my game engine and my eventual game for the last I don't know how many years, hitting some areas pretty well I've thought. My terrain looks nice, my character skinning looks nice, my shadows look half-decent and at the moment I'm happy with my fps budgets, my component entity system, etc. I'm not far away from getting some sort of prototype going.

And then I thought about implementing a physics engine for my character's behaviour and I chose Bullet. Lovely, pull in a couple of libs, a few header files, add some rigid body objects, call 'frameStep' and off you go. Then I looked at their code...

I knew a physics engine would probably be complex but they have used c++ code the likes of which I've never seen before and it's kind of stopped me in my tracks a bit. I may be setting my sights quite high for my game (I've written several in the past) but I do have almost everything mapped out either in my mind or on paper for parts of it which I think may raise concerns. I've been developing for the best part of 32 years (I'm 42) over dozens of different languages (including 68k assembly) and I thought I knew a fair amount about c++ having used it at home and at work for the last 15 or so years but I've never written any code that resembles that physics library code.

So, if anyone here has worked on a AAA full works game, is it all as complicated as the sort of code you see in Bullet? Or are there parts of it that look like the sort of stuff us lowly home game engineers can write...?

Well, thanks to id and others you can see for your self: https://github.com/omcfadde/dante

or

https://github.com/id-Software/DOOM-3-BFG

That said C++ fu is always a good thing to brush up on^^ At the same time a lot of times though you don't need all the templates etc. The thing you have to remember about Bullet is that it's a lib, so it has to do it's best to fit as many needs as possible. However if you are writing your own engine you only have to make it as flexible as you need it^^ Make sense?

EDIT: Do keep in mind that that is the DOOM3 engine... so it's a bit dated at this point, but I think it's a good example^^ (added original repo as well)

Define "complicated."



I've worked with Bullet (and a few other physics libs) and don't particularly remember anything egregiously scary about any of them.

I think he's talking about the internals not the surface level interface that your normally interact with^^

So I re-ask my original question: what metrics are we using for defining "complicated"?

I spent a good half an hour or so trying to work out why it wasn't building out of the box in 2005 and some of the files I found myself in were heavy in asm and used lots of SSE (I guess) or SIMD stuff I've never come across.

I've just had another good look through and I guess along with the asm, they use very short variable names which, to me, always makes things look more complicated. I guess the question I was asking was are AAA games flooded with asm and things like that?

Things under BT_USE_NEON appear to use lots of calls I've never heard of, I guess it was just unfamiliarity that phased me. I'm back to being unphased for my own project :)

Third party libraries like Bullet, especially mature ones that have been well-used and much-iterated, tend to be fairly complex to look at because the iteration tends to follow along the lines of a) making it more general-purpose, and accounting for as many use cases as possible and b) making it as performant as possible. General usefulness can add a lot of complexity, since the library authors have to code in such a manner so as not to exclude use cases. Bullet wouldn't be as useful if it could only be used for Angry Birds, for example. And highly performant code tends to be hard to read because often the code that reads the easiest isn't necessarily the code that executes the fastest. Once you start dipping into the more esoteric forms of optimization (you mentioned ASM and SSE) then it gets even more difficult to read, especially if you have little or no familiarity with them.

Don't worry too much if your own code isn't as seemingly complex. Worry more that it does what you need it to. Upper level code that uses these underlying frameworks will typically be less complex than the framework code itself, since the whole point of framework code is to abstract away a lot of messy detail.

I imagine that writing a game solo, you start to realize that refining any one part of your game could months of your dedicated attention. And games that have huge teams behind them are obviously the only ones that have the opportunity to do exactly that so it shouldn't be surprising that their code-bases might start to look extremely arcane.