• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ram090

Question about a complicated AAA game source file

9 posts in this topic

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?

0

Share this post


Link to post
Share on other sites

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. 

1

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
2

Share this post


Link to post
Share on other sites


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

1

Share this post


Link to post
Share on other sites

 


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

0

Share this post


Link to post
Share on other sites


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.

0

Share this post


Link to post
Share on other sites

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.

1

Share this post


Link to post
Share on other sites

 


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.

0

Share this post


Link to post
Share on other sites

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.

1

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  
Followers 0