Sign in to follow this  
RobMaddison

Just how complex are AAA games?

Recommended Posts

RobMaddison    1151

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
ryutenchi    353

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
ryutenchi    353

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
Promit    13246


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
ApochPiQ    23003

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
RobMaddison    1151


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
permian_lizard    134

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
RobMaddison    1151
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
AndyPandyV2    298

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

Share this post


Link to post
Share on other sites
FLeBlanc    3141

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


Go (Also continuing their tradition of naming things to make it difficult to search for on Google).

Share this post


Link to post
Share on other sites
RobMaddison    1151

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


I tried 2013 and didn't like it at all. I've settled on 2008 for now, I've still got a lot of work to do and whilst I've got momentum, I'd rather not use an IDE that, in my opinion, feels like a step backwards from a usability point of view - I'll need to spend time getting familiarised with it which unfortunately I don't have just at the minute.

Share this post


Link to post
Share on other sites
Buster2000    4310

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.
 

Share this post


Link to post
Share on other sites
Buster2000    4310

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.

Share this post


Link to post
Share on other sites
conq    735

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?

Share this post


Link to post
Share on other sites
RobMaddison    1151

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


Might be able to tell you in July... I'm swapping investment banking for games development, starting up my own company

Share this post


Link to post
Share on other sites
Pink Horror    2459

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.

Share this post


Link to post
Share on other sites
kburkhart84    3182

You may be surprised...depending on your point of view, they can be either more OR less complex than you would expect.  Example, the code itself isn't as complicated as some people would think it is.  In older engines, you will indeed find many lower level optimizations and less of that in newer engines, though there still may be some for the lowest of routines that gets constantly used.  On the other hand, AAA games have complexity levels added because they usually attempt to target as many people as possible.  That is for example why the minimum requirements for AAA games are lower than many people would expect.  Indie games don't tend to have the extreme level of scaling that AAA games do.  They require much performance enhancement to be able to work on lower class systems, but then they need all of the eye candy to work on full gaming systems.

 

The thing that can make AAA games much more complex as well is not only the code.  Much of the code itself can be simple, depending on the game. I believe indie gamedevs could duplicate much of the gameplay code, as lots of it has to do with mechanics, like in a platformer the jumping, collision detection, etc...  These things you will see all over indie games as well.  But, some things you won't see in indie games as often are the final polish things, as well as the sheer amount of content.  It varies with the game of course, but in an indie game you are much more likely to see a music track re-used in different levels than in a AAA game.  There are also many more sound effects, including more variance on the same effect, like more variety on a footstep instead of just pitch bending it.  Things like a "demo" mode where when you don't play from the main menu, it goes into a "demo" of the gameplay can be another example you don't see much of in indie games.  Things like in game recording, level editors, character customization, and other similar things are also not as common in indie games.

Share this post


Link to post
Share on other sites
Satharis    2444
I would say if anything the code is just... "out there". A lot of that could be probably contributed to just what the games are, they're huge multi million dollar budget games, basically the Hollywood of interactive technology, they have huge teams of people of varying backgrounds and skill levels piecing together a giant convuluted monstrocity of code that is probably a couple of million lines over a few years.

Ontop of that things are likely constantly getting changed, things get "lost in the dark depths of the code base" and overall it just becomes a large, rushed thing. In a lot of ways that contributes to how scary looking a large codebase tends to be, throw in things like crazy optimization code that was tossed into the middle of a class during profile time and.. yeah.. it's definitely almost never textbook quality code. That said most big games do tend to run pretty well, they're just a logistical and scary nightmare from the coder standpoint.

A good comparison would probably be creating a blockbuster movie vs the kid recording videos in his garage, they're probably doing the same, basic fundamental things, but the big company has hundreds of people to deal with and organize, probably massive collections of digitally recorded footage from multiple cameras and frame rates, multiple cuts, audio and such. Basically they have a giant complex mess that they just stitch together into a movie.

Share this post


Link to post
Share on other sites
StubbornDuck    602

I've seen both incredibly well written AAA game sources and incredibly messy AAA game source. It all depends on the companies' approach to deadlines, software quality, and hiring/managing employees - such differences in practices lead to huge differences in the code base over time.

 

It's pretty interesting to casually view the sources of open sourced AAA games, and something that I can recommend to get an overview.

Share this post


Link to post
Share on other sites
ShadowKGames    339

In essence very difficult especially if you don't have the man power (IF YOU DO IT RIGHT) I'll expand on that later, there's so many sides to the process. Coding is very difficult, you have to understand the maths behind it and have the ability to solve matters and optimise everything, you can and most likely will spend days on one issue plaguing your specific type of game, controller physics, AI, shaders, GUI's, Interactive UI and de-tractable terrain always spring to mind . Raw Mocap can take a long time to look right, lighting is a massive part of the ambience and scenery. Optimisation is a pig to be polite, artwork needs to be beautiful and on top form.. CGI scenes take forever and even the scoring and music can take extensive amounts of time to get right. Even the story concept, some games contain 60K+ worth of voice acting and someone has to keep it seamless, even keeping a character from falling into a pit throughout all your scenes can take ages (not even to mention trying to build your own engine (I don't think I'll attempt that one again any time soon smile.png)... OR!

 

You can copy and paste systems and asset's, not understand much about the simple things like smoothing quaternion rotations,vectors, occlusion / frustum culling, physics, poorly optimise your game, get contractors to do all the artwork, hardly do anything with the mocap, outsource the sounds and music and release it with cows flying off into the distant scenery. What makes a true AAA game difficult in an expansive sense is the attention to detail, fixing all the little quirks, optimising the game to run well on many platforms and making sure every pain staking detail is spot on. 

 

In essence as someone else says, it's the polish.. It'll be like every other company, they'll have elite guru's to tackle the complex bits and people who only know the basics then mesh it all together to get a final product. If your whole team was filled with Guru's the bill would be ridiculously expensive, even more so than it is now. 

Edited by ShadowKGames

Share this post


Link to post
Share on other sites
mychii    898

I think it's getting complex as AAA when you put all efforts to push every single feature you need because you have money.

 

For example, indie devs usually don't have that much budget, so if you want to animate character, you use pixel art because it's easier enough (technically) than creating 3D realistic character as well as it doesn't matter since pixel art has its market as well, and sometimes can be done by the programmers themselves.

For me, it gets "AAA" when you want one 3D super realistic character to live by hiring one of the best 3D modeler, animator, fashion designer, weapon designer, facial expression designer, lighting designer, motion capture device, actor/actress, combat designer, etc just for that.

 

So if it goes to game code, see BioShock's case for example. They have money that they can hire one of the best they could as water programmer to solve complex water equations in a form of efficient code, and then integrate it to an already complex system within a heavily modified Unreal Engine based on the demand.

It is also when you want the best 3D sound ever that you have to make partner with one of the best sound synthesizer out there and code together with their technology (and their internal programmers) which increases the complexity due to integration and different way to deal with that partner's API.

 

So yeah, it's complex on demand.

Edited by mychii

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this