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?
Question about a complicated AAA game source file
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.
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.
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.
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 
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
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
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.
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.
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 linesI 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.
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.
