Another thing that might help is asking yourself what are the important events in the game and finding where they are handled (where is the score updated, where is damage worked out, spawn/death events handled). Sometimes games use global event handlers/listeners so different parts of the code can hook into the important stuff. Find where these events are handled or callbacks registered and it should give you a quick insight into the more interesting parts of the code;)
From the description it sounds like you are trying to understand how the program works (as you have the source code), rather than 'reverse engineering' which the usual meaning assumes you don't.
So my suggestion is start by getting it compiled, up and running;) You can then use the debugger to breakpoint the code and follow it through. You say you have most of the source code. Is the rest available as libararies to link to? Otherwise you could create 'fake' libraries just to get it compiling and running.
Probably best to start with a top down approach. Games invariably have a 'game loop', so locate it and start there. It'll be something along the lines of
InitStuff();
while(running)
{
DoStuff();
}
CloseStuffDown();
Whilst games are many and varied in their complexity they more often than not follow the same kind of pattern. During DoStuff() they will update the user input, update the world state (objects in the world), and finally render stuff on the screen. Once you've got a basic handle on which bits, try changing or commenting out things to see what effect that has.
You could try mapping out all the source code with various software tools and the like, but the best way I've found to understand the code is just to dive in and have a play around. You'll probably find there are one or two files that do most of the interesting stuff anyway. If you have the change information from source control (eg if it's including at the top of the file) then look for the ones with the most changes;)
Slashdot Mirror
Found this a while ago, tend to agree with most of it ;)
http://gwaredd.blogspot.com/2005/08/good-code.html
Another thing that might help is asking yourself what are the important events in the game and finding where they are handled (where is the score updated, where is damage worked out, spawn/death events handled). Sometimes games use global event handlers/listeners so different parts of the code can hook into the important stuff. Find where these events are handled or callbacks registered and it should give you a quick insight into the more interesting parts of the code ;)
So my suggestion is start by getting it compiled, up and running ;) You can then use the debugger to breakpoint the code and follow it through. You say you have most of the source code. Is the rest available as libararies to link to? Otherwise you could create 'fake' libraries just to get it compiling and running.
Probably best to start with a top down approach. Games invariably have a 'game loop', so locate it and start there. It'll be something along the lines of
InitStuff();
while(running)
{
DoStuff();
}
CloseStuffDown();
Whilst games are many and varied in their complexity they more often than not follow the same kind of pattern. During DoStuff() they will update the user input, update the world state (objects in the world), and finally render stuff on the screen. Once you've got a basic handle on which bits, try changing or commenting out things to see what effect that has.
You could try mapping out all the source code with various software tools and the like, but the best way I've found to understand the code is just to dive in and have a play around. You'll probably find there are one or two files that do most of the interesting stuff anyway. If you have the change information from source control (eg if it's including at the top of the file) then look for the ones with the most changes ;)
Also - grep is your friend ;)
HTH & Good luck