It sounds like the problem might be no clear module structure. Do the classes interact in a spaghetti fashion? Is there any attempt at separating subsystems into logical units?

Instead of looking at the code, try starting from a high level perspective and move down. So maybe figure out how a mouse click gets turned into an object action. Or try to figure out where from main() you get to some actual rendering. Find out what would be involved in adding a new game object. Do you have a full build environment? Play around with the code, actually change some stuff.

That might give you a better view of the "important" types and functions, the ones you are most likely to interact with when you go to work on extending this. You don't need to understand all the classes, there might be too many.

Yeah, the code isn't too complicated, it's just that it's heavily based on the script, and I had zero experience with that. I was playing with the code, and trying to figure out what certain class did (or didn't do...) I kept investigating, placing breakpoints and playing the game, but nothing happened. It seems it was a completely useless class, I commented it all out and no compiler or linker error.

I mean, I don't want to say the code is bad, because I'm a novice and the game works. But dammit...

Yeah, the code isn't too complicated, it's just that it's heavily based on the script, and I had zero experience with that. I was playing with the code, and trying to figure out what certain class did (or didn't do...) I kept investigating, placing breakpoints and playing the game, but nothing happened. It seems it was a completely useless class, I commented it all out and no compiler or linker error.

I mean, I don't want to say the code is bad, because I'm a novice and the game works. But dammit...

On legacy code bases useless code is everywhere. It's just something you have to get used to. It will piss you off, but eventually you'll realize that it's just the way legacy codebases work. You'll probably even end up doing some less than desirable practices because it's easier than rewriting a significant portion of a legacy codebase.

It is a hazard of the job. When you have a 3000 file code base that's had pieces of it used by 20 projects you aren't going to have the manpower to have a perfectly tailored codebase to the last game in the line.

I kept investigating, placing breakpoints and playing the game, but nothing happened. It seems it was a completely useless class, I commented it all out and no compiler or linker error.

I mean, I don't want to say the code is bad, because I'm a novice and the game works. But dammit...

Actually you made good progress. You figured out that the class wasn't needed. If I was in your shoes at that 'aha' moment I would feel some (perverse) satisfaction. Determining what parts of the code aren't used or are not relevant is equally important to your goal.

I kept investigating, placing breakpoints and playing the game, but nothing happened. It seems it was a completely useless class, I commented it all out and no compiler or linker error.

I mean, I don't want to say the code is bad, because I'm a novice and the game works. But dammit...

That's a good start.

Be careful because sometimes code that seems safe to comment out may actually be used by some less-common code cases and code routes. Be sure to look for edge cases and other ways in to the code.

Now use your logic skills to guess at why they might have written it, why it might be unneeded.

Getting started in an unfamiliar code base is a bit like an evil scientist doing a vivisection. You discover that poking here causes a response over there. Pinching this causes that to twitch. Closing off something causes the game to crash.

One good way to learn is to just jump in. Figure out a small change that you want to make, perhaps adjust an existing UI screen, or add a small piece of functionality, or fix a known bug. The first time in you will end up dropping lots of breakpoints to see where to stop the program at various times and places, you will need to search for all instances of a data type or member variable or for everywhere a function is used.

When you discover something that you didn't understand add a comment so you'll immediately recognize it next time. When you have an awkwardly named variable or function then use your tools to help rename it into something more meaningful to you.

Gradually it will grow into something you can work with comfortably.

Thanks everyone for your help!

Beware things that *seem* to be dead code - some scripting systems I've seen use reflection (or some other kind of runtime lookup) when a script is interacting with the engine code. Removal of such engine code will compile, but then mysteriously crash at runtime when the particular script tries to call the associated engine code.