Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
There was a PC game released in 2001 called Black & White by Lionhead studios in which there was a lengthy statistics page which updated in real-time. There were stats such as how many people killed, how much money you've earned, etc... but the really puzzling one was Total lines of code executed, which was into the billions and counting.
How would they have known this, how would they have calculated this at runtime? Did they make it up?
There were a lot of tongue in cheek statistics in black and white. It's also possible that the statistic is just some semi-random number based on some function that is not actually linked to any real code execution statistic.
I suppose:
(how-long-you-played-for) / (average-execution-time-for-80x86-instruction)
would get you a ballpark figure.
Actually, I just came across my old copy of Black & White at the back of a cupboard I was emptying - maybe I'll give it anther go, although I remember not thinking much of it at the time.
timePlayed/averageExecutionTimePerInstruction/averageAmountOfInstructionsForLineOfCode? ;-)
Reasonably recent Intel and AMD processors (and most other high performance processors) include Performance Monitoring Counter (PMC) registers. You can monitor quite a variety of different things, but probably the most relevant to the question at hand would be number of instructions retired.
Putting these to serious use can be a little tricky -- for example, there are circumstances under which they can undercount the number of actual instructions retired (e.g., if a System Management Interrupt happens while executing a halt instruction, some processors won't count the resume from system management instruction). For the purposes at hand, however, you'd probably just show what it had, and ignore the minor detail that it could sometimes be a little off.
It's worth noting, however, that this is counting assembly language instructions, which don't correspond directly to lines of code in a typical higher-level language. Converting between the two could be non-trivial -- even in C, it's not at all fixed (though a lot of lines will be close to 1:1) but in something like Perl, for example, the number of instructions for a line of code could not only be quite large, but could also vary (hugely) depending on the content of a string, if it was being used as a pattern.
It's certainly an estimation. How they estimate it though it's an interesting question.
I would write a tool that parses the whole source code and creates a lookup table containing function name and source code lines for that function.
Then I would debug the game for a time t, says 1 hour, tracing every function called and writing the results to a file. At the end of the session, I would launch a script that reads the file and lookup the source code lines for every function called and sum the number of lines.
You now know the lines of code executed for time t and you could easily derive the lines of code executed for time t2 which is the interval at which you want to update your stats, say every 5 seconds.
This number is valid for one player, multiply it for the number of current players and you get a pretty good estimation of the total number of source code lines executed in real-time.
I believe, they just used some code coverage tool like GNU Gcov.
Edit: GNU Gcov is a Code Coverage tool used mostly in software testing. During testing they just integrate Gcov with the software being tested, and then do their usual testing. At the end of testing, they generate reports using data gathered by Gcov at runtime. Gcov gathers a lot of data including which functions got executed, the number of times they were run and the like.
