Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Question about a complicated AAA game source file


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 ram090   Members   -  Reputation: 129

Like
0Likes
Like

Posted 14 November 2013 - 04:07 PM

I was looking through some available AAA source for ET WOLF, Jedi Academy and DOOM 3. So the wp_saber.cpp file in Jedi Academy is something else. 1000's of lines of code and almost 0.5Mb in size. Which raised a few questions.

1) How long roughly, would it take a pro dev to write this saber source(I am assuming from the comments in the source that a few devs were working on it, or at least fixing bugs etc).

2) How do these devs actually know 'where they are going' with such a large a complex source. It's quite incredible to look at. Do they plan everything out in advance what is needed or is it more a case of laying some foundations and then just keep adding/tweaking/trial and erroring[sic] from there.

3) I realise Jedi Academy is dated now, but this code must still be relevant in the present day?

To sum up, this saber source(in particular) file is pretty mind boggling. It's hard to see how they come up with this code, any thoughts or words of wisdom here?



Sponsor:

#2 Winfield   Members   -  Reputation: 179

Like
1Likes
Like

Posted 14 November 2013 - 05:03 PM

In programming, the secret is to break a complex problem down into many small problems. Just like with a smaller game a team might split up with one guy coding audio, one guy coding NPCs, one guy coding physics, etc: the problems are just more low-level. Maybe one guy was responsible for coding the lens effects, another guy was responsible for the saber's interfaces, another guy was responsible for making the saber "widen" when swung quickly like they do in the movies, etc etc.

 

Given that many of the saber's code requirements are extrapolatable (what kind of effects it will need, what the collision detection will be like, its effects on physics) it's likely that they began with a set of dummy methods and specced out their behavior on paper ahead of time - what data each method accepts, what data each method emits, a graph of what methods call (and are called by) which other methods. 



#3 NightCreature83   Crossbones+   -  Reputation: 3906

Like
0Likes
Like

Posted 14 November 2013 - 05:18 PM

Writing a class that is a 1000 lines long takes a bout a week or two to do. Generally when a class starts reaching a 1000 lines though it might be time to look at what it is doing and seeing if your not mixing concerns. I have seen source files go over 5K lines easily and still being reasonable manageable. This things start from simple beginnings and grow from there to be honest, I have written some of these massive classes, and sometimes felt dirty whilst doing it. Especially when you start to see that the dyanmic editing part of the class is actually becoming far bigger than the actual behaviour :(.

 

Knowing where you are gonging is generally not the hard part, once you understand what the source is doing(through lots of reading and debugging, this is the slow part) modifying it becomes easy.

 

A lot of that saber code file is pure state management and checking those states, this grows over time with complexity of the game object being created. I found the whole source tree not too hard to figure out what is where. Lots of the things in the lib though are external libraries that they use and that source is also included.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#4 Nypyren   Crossbones+   -  Reputation: 7491

Like
2Likes
Like

Posted 14 November 2013 - 05:22 PM

Frankly, this looks like code you would see from an old, established console game developer who is used to their existing programming paradigms and has not adopted any recent innovations.  Likely their programmers are skilled in C and haven't kept up to date with newer languages.

 

Notice they are using C style, not C++, despite the file extension being .cpp.  That's their choice, but is honestly making their code more verbose than it needs to be.

 

The large amount of externs they use are intended to dramatically speed up compile times.

 

They use global variables and fixed-size arrays with reasonable limits to avoid memory fragmentation (this is something you will see VERY commonly in console game code but which is generally frowned upon elsewhere).

 

Lots of hardcoded values.  Some game studios have game designers who design features AND do their own data entry, and other studios offload data entry to the programmers who are allowed to hardcode values (like you see here).  Some studios, the designers ARE programmers and make tweaks to the code themselves.  The trend where I work is to make everything data-driven instead of hardcoded (this has been true for the past decade).

 

Their functions are too large, but the compiled code doesn't care.  Productivity suffers, but not much else is different.

 

 

1) That file was probably developed and tweaked contiuously over the entire development period for the project.  It's not like they just sat down and wrote it all from start to finish.  They started from an initial spec, implemented the core functionality and then added on as they needed.

 

2) The devs who wrote or fixed bugs in any given section of code will remember the function names or variables for other things that they can search for to quickly get to where they need to.  This is somewhat dependent on the IDE(s) they use.  At bare minimum, they will search for the function name.  Ideally, they also have "find all references", "go to definition", and "navigate back" functionality in their IDE to speed up navigation within large projects.  Code folding also helps a lot.

 

3) No, the code is not relevant whatsoever in the present day.  It's entirely special-case for the lightsaber in that game, with a particular set of playable characters, animations, etc hardcoded right into the switch statements and would not be directly applicable for any other games, even ones that have lightsabers.  It would be relevant for direct sequels to that particular game which use the same engine with minor tweaks.


Edited by Nypyren, 14 November 2013 - 05:25 PM.


#5 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
1Likes
Like

Posted 14 November 2013 - 08:23 PM


Writing a class that is a 1000 lines long takes about a week or two to do.

You must work somewhere with a very relaxed pace blink.png


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#6 Kaptein   Prime Members   -  Reputation: 2208

Like
0Likes
Like

Posted 14 November 2013 - 08:44 PM

 


Writing a class that is a 1000 lines long takes about a week or two to do.

You must work somewhere with a very relaxed pace blink.png

 

well, the question was about a specific class, and they tend to grow from nothing over spans of time

i wouldn't be shocked if it started out as maybe 500 lines, then over a few months grew to 1000 lines



#7 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
0Likes
Like

Posted 14 November 2013 - 08:51 PM


well, the question was about a specific class, and they tend to grow from nothing over spans of time. I wouldn't be shocked if it started out as maybe 500 lines, then over a few months grew to 1000 lines

I meant that we tend to produce multiple 1,000 line classes in the course of a day.

 

Mind you, a lot of our code is written in Java, and a more verbose language is hard to imagine.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#8 Samith   Members   -  Reputation: 2396

Like
1Likes
Like

Posted 14 November 2013 - 09:03 PM

This file looks like really gameplay specific code. In my experience gameplay code (as opposed to core-engine code) can get absolutely nuts. This code file probably started out small and grew organically over a long period of time. New features and changing design requirements and likely tons of weird bugs and edge cases all probably contributed to this massive file. In some of the projects I've worked on there have been similarly large files for gameplay specific functions. Typically they're written and maintained by a member or couple members of the team who aren't particularly technical, and the code itself usually isn't in any performance critical path, so the code can sort of grow unchecked for a long time.



#9 NightCreature83   Crossbones+   -  Reputation: 3906

Like
0Likes
Like

Posted 15 November 2013 - 07:12 AM

 


well, the question was about a specific class, and they tend to grow from nothing over spans of time. I wouldn't be shocked if it started out as maybe 500 lines, then over a few months grew to 1000 lines

I meant that we tend to produce multiple 1,000 line classes in the course of a day.

 

Mind you, a lot of our code is written in Java, and a more verbose language is hard to imagine.

 

C/C++ doen't really allow that too fast, besides I was abusing one of the Debug widgets to do something it was not designed for, which caused the delay as it needed to function like an artist wanted.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#10 TheChubu   Crossbones+   -  Reputation: 6979

Like
1Likes
Like

Posted 15 November 2013 - 10:43 AM

Lets give it some context...

 

Jedi Academy was released in 2003, was based on a pure C engine, IdTech 3. So whatever C++ Raven did, it was literally just shoved in since they were already sitting on (aprox) 350 thousand lines of pure C (and some assembly!).

 

Not even that but that game was done in the course of a single year (!) after the release of Jedi Knight 2, and in a very "interesting" way: Single player and multi player teams worked separately, so there is a renderer just for SP and another different one just for MP. Talk about code duplication.


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS