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?

  • 1
    I'm curious what the point of this statistic to a player would be... Also, I don't remember that particular stat from the game (but I do remember the others). Would you happen to have a screenshot of it? Commented Jun 13, 2011 at 17:23
  • 4
    @FrustratedWithFormsDesigner: that's a geek thing. Cool enough to get mentionned here ten years later :)
    – user2567
    Commented Jun 13, 2011 at 17:25
  • It was just a fun thing one of their guys added i guess. Yeah, i still wonder about it 10 years on! ;o) Commented Jun 13, 2011 at 17:30
  • 1
    I believe that many games use scripting languages to specify high level behaviour, though I don't know about Black & White specifically, so it may be that this statistic came from their scripting engine. You might get better answers on the game development stack exchange site, where the faq appears to suggest that this sort of question would be acceptable.
    – Mark Booth
    Commented Jun 13, 2011 at 17:51

5 Answers 5


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.

  • 2
    Though it is lines, not instructions. Maybe timePlayed/averageExecutionTimePerInstruction/averageAmountOfInstructionsForLineOfCode? ;-)
    – Anto
    Commented Jun 13, 2011 at 17:32
  • @Anto Well, that would depend what it was written in. I would have thought bits of it at least would be in assembler, but who knows? Commented Jun 13, 2011 at 17:33
  • 1
    From what I recall, the AI had some Prolog bits that were generated on the fly, as a part of the creature-training. I don't know how that would factor into the "Number of lines executed" statistic. One line of Prolog could end up being numerous machine instructions. Commented Jun 13, 2011 at 17:36

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.

  • What if i had a faster processor than you? Commented Jun 14, 2011 at 17:05
  • @Gary clever, didn't think about that. I guess one should do it on several different computers with different hw configurations and average the result. Or just do it once on an "average" computer :) Commented Jun 15, 2011 at 3:10

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.

Code Coverage on Wikipedia


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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