I read about game loops, read tutorials of simple games like Asteroids and programmed them by myself. Nevertheless if I try to start reading code of a game with many many thousand lines of code, I have no clue at all where to start, what files to open first and which next to understand how it all work together.
My question is, are there any projects/tutorials out there, that gives a rookie some guidance (by example) how to start reading code of large open source game projects?
This question appears to be off-topic. The users who voted to close gave this specific reason:
When I approach a new code base I use a technique I call "tunneling". I start at the highest level, then I jump to the lowest level, and repeat until my knowledge meets in the middle, like two tunnels being dug in opposite directions and eventually meeting.
I start by using the software like an end-user would to familiarize myself with the basic concepts. This might seem obvious, but a lot of people jump straight into the code base, sometimes without a clear idea of what the software actually does. While I do this, I think of how I would implement each feature.
Then I open a few source files of a key system to try to get a feel for what the code looks like. What are the most common data structures? How are objects created and destroyed? What design patterns and idioms do they use? At this point it's crucial that you don't overanalyze any one particular system, especially if the software is mature and heavily optimized, because you could spend days figuring out one system without getting a feel of how the major components of the engine interact.
Going back to the high level, I would run the engine again and step over the game loop, making sure not to stop and think too hard about any given chunk of code. The point is to get a feel for what general operations happen in what order, not to become an expert on every single line of code in the engine. You should be able to look at an engine's update loop and say "There's a lot of minor details in here, but the basic flow is that they run the garbage collector, update all objects, update the physics simulation, and draw all objects".
I developed this technique after struggling with Unreal 3's labyrinthine code base early in my career. I made the mistake of tunnel-visioning the rendering code without trying to use the engine first. I think I spent an entire day trying to figure out how their post-processing system worked, when I never actually bothered to pull up the editor and play with the post-process chain first. It's easy to get caught up in the details and spin your wheels without actually learning anything, especially if the engine uses a lot of macros and uncommon idioms like UE3 does.
There's not really a standard procedure for this. It's just something experience gives you. You're not going to immediately understand a large code base. Everyone has their own coding style and strategies for structuring their code.
Likely what's happening is you're trying to understand too much, too fast. Start slow. Pick something you want to learn more about, like what the character class looks like or how the mouse picking works. Find one thing and focus on it. Trace the usage of those classes throughout the code, see where they're used and how.
Build your knowledge of the code base little by little. Soon you'll be understanding how the designer likes to structure things, and finding features and examining the code will get easier.
Reading that source code won't help you too much unless you spend a huge amount of time reading it. Reading anything large for educational value takes some organization.
If you want to understand an open source project in its entirety you need to do your best to take a huge scan of what each large section of code does. It's best to make a visual flow chart describing the engine. This is what I did when I first studied Box2D's code in order to make my own physics engine.
Once you have a rough flow chart of what each section does you can start delving into the implementation of one at a time.
It's just about organizing the information in a way that is consumable by one piece at a time. Make sure you have a lot of time and are capable of putting out a lot of hard work. Additionally, if you have previous project experience understanding what and why things do and are becomes more natural. Again, it takes time to get this experience in the first place!
