Jump to content
  • Advertisement
Sign in to follow this  
RobMaddison

Just how complex are AAA games?

This topic is 1671 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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...?

Share this post


Link to post
Share on other sites
Advertisement

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)

Edited by ryutenchi

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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^^

Share this post


Link to post
Share on other sites


I think he's talking about the internals not the surface level interface that your normally interact with^^
I don't remember seeing anything unusual about the internals either. We dig through them all the time and it's actually fairly nice code all told. Very large, and a somewhat wonky design in some ways (at least at first glance). It takes a while to wrap your head around how the library actually glues itself together, as there's a lot of pieces that can be dropped out and replaced (broad phase and narrow phase solvers for example, collision detection, lots of things).

Share this post


Link to post
Share on other sites

Agreed with Promit.

 

I dug into the guts of Bullet at one point and remember being pretty OK with how it was written. That's also true of many other libs I've used over the years.

 

 

 

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

Share this post


Link to post
Share on other sites


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 :)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
I've just been familiarising myself with SSE and I can mostly see what's going on now. I can think of a couple of areas where my code might benefit from it too, so that's good.

I'd love to have a look at the code of some of the AAA games out at the moment, especially the likes of COD. I guess part of the fun of game development for me is trying to work out how how things are done and how to do my own interpretation, I generally only buy a game if I want to see how it works - I spend most of my time in corners looking at detail or how they've done shadows, etc. I bought the PC version of Crysis a while back and I've never actually played the game, I spent all my time in the sandbox

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!