I feel that in order to create realistic real-life games, game developers need some ways to monitor the system itself i.e. players' moves, other events and the state of the system itself. I know that creation of profiling/tracing -systems is not that easy, look how many people have tried to do better coverage -program in Python and fell far away from the original coverage.py.

  1. I may be associating profiling/tracing wrongly to this game-development phase of dynamic monitoring but I am interested to know where/how profiling and tracing -techniques such as pythonic sys.settrace() are used in game development?
  2. What is their purpose and what are the dynamic event monitoring systems really called? Game engines?
  3. Are there some ready systems to advance/investigate profiling/tracing -areas in game development?

1 Answer 1


There are two kinds of data we can profile, at the high level:

  1. We can profile the execution of the program itself -- what functions are called when and where, how long they take, and what impact they have on the environment (allocations, locks, threads spawned, et cetera).

  2. We can profile what the user is actually doing with the program -- where they are in the game when they die, where they are when they earn the most experience, what they spend the most money on, which skills they use most often.

These aren't fundamentally different operations, really, although the type of data collected by each operation is pretty significant. The type of data collected by the first technique is generally reusable across many programs, whereas the second type of data tends to be more program/game specific (experience may not even exist in a particular game, for example).

You have the right terminology for this kind of technology -- "profiling," "tracing," "user monitoring" and such are all appropriate terms. The technology itself is fairly straightforward to implement as well. The most basic approach just involves instrumenting code by calling a function that collects the desired data. You can then write that data to a log file or (most usefully) send it to a database for later querying and report generation.

Code coverage, which you mention at one point, is a little more complex and difficult to get right (especially in more dynamic languages). It is more akin to the first technique, that is examining the state of your code rather than how users use your program.

  • \$\begingroup\$ in order to make this kind of systems, what kind of commands/privileges are a prerequisite? Suppose we have 99.99% CPU-consuming game using a huge amount of memory, a real bottleneck. To monitor such program sounds a challenge in itself, because the monitoring it may overheat the system. I am not sure but this problem may require zero 0 level privileges on some systems such as W.XP (maybe associating to unrelated topic, not sure) to prioritize the kill over the bottlenecked software's commands. So by which technique you can address this problem, not making monitoring a problem? \$\endgroup\$
    – user6365
    Apr 8, 2011 at 17:23
  • \$\begingroup\$ @hhh In order to discover the bottleneck in any game, simply reduce usage of a single system resource such as memory bandwidth, or texture bandwidth, or pixel shader usage, and if the framerate increases, you've found your bottleneck. Profiling tools that track the duration of time spent in various sections of code CPU side, only use 0.01% of the CPU anyway, so the problem you mention isn't really an issue. \$\endgroup\$
    – Olhovsky
    Apr 8, 2011 at 17:45
  • \$\begingroup\$ For inline'd profiling I have always loved the code sample from GameDev Magazine's Aug04 edition.. Might be a bit dated by now but is a good piece of code to use and fiddle with. Anywho, can find all the code samples over the years at: gdmag.com/resources/code.htm (Also just neat to see how the topics have changed over a decade as well) \$\endgroup\$
    – James
    Apr 8, 2011 at 21:42

You must log in to answer this question.