4
\$\begingroup\$

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?

\$\endgroup\$

closed as off-topic by Seth Battin, Patrick Hughes, msell, bummzack, Anko Aug 12 '13 at 23:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Patrick Hughes, msell, bummzack, Anko
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    \$\begingroup\$ Though your particular question is somewhat interesting, it's still a how-to-start question, which does not suit this site's format. And obviously, wishing to watch someone code a game is a request that any website can't fulfill. The closest you can get would be to read an authoritative and comprehensive text written by an experienced programmer. For example: gamedev.stackexchange.com/questions/497/good-game-design-books \$\endgroup\$ – Seth Battin Aug 10 '13 at 22:55
  • 2
    \$\begingroup\$ It's also a very general programming question and has nothing to do with games, per se. \$\endgroup\$ – Patrick Hughes Aug 11 '13 at 0:03
  • 2
    \$\begingroup\$ @PatrickHughes Pretty true. Case in point: programmers.stackexchange.com/questions/6395/… \$\endgroup\$ – MichaelHouse Aug 11 '13 at 0:16
  • \$\begingroup\$ It can be a challenge, especially with OOP. Sometimes I wish there was a tool that would flatten all the OOP in order to simplify reading large code bases. \$\endgroup\$ – Inisheer Aug 11 '13 at 4:19
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ In your "high level" analysis, do you use a debugger? If not I can not imagine how I could analyze the game loop by just running the game. Your answer is very interesting. \$\endgroup\$ – Senkaku Aug 11 '13 at 8:41
  • \$\begingroup\$ Yes, I use a debugger so I can step into functions that look interesting, as well as stepping over functions that aren't relevant to what I'm looking for. I'm glad you found this helpful. \$\endgroup\$ – Daniel Rowe Aug 11 '13 at 16:40
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I hoped that someone made a walkthrough to make the gathering of experience more easy for beginners, something like an explanation from a developer of how they have written the code in retrospect. What classes they have written first, and why (what led them to writing these files first and not others), but I see it still seems the hard way by reading till the bulb lights up with the occasionally asking in the IRC or forum of the game developers. Thanks for your tip on picking one topic after another and trace the elements of that topic through the code. \$\endgroup\$ – Senkaku Aug 10 '13 at 23:23
1
\$\begingroup\$

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!

\$\endgroup\$
  • \$\begingroup\$ These flow charts must be of incredible size how do you manage them? Do you still have a copy of your flow chart on Box2D lying around and if so, would you share it to me? It would be very interesting to see how you made it in detail. \$\endgroup\$ – Senkaku Aug 10 '13 at 23:14
  • \$\begingroup\$ I would love to share it, but I lost it when I reformatted my hard drive :( \$\endgroup\$ – RandyGaul Aug 10 '13 at 23:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.