Wieke said:
As far as amusing bugs go, this is a good one. Glad it was found though.
Has me wondering how hard debugging actually is for these kinds of projects. Cause as far as is know (which isn't all that much I admit) you'd need to add a break point to the function that alters the players "wanted" status so you can trace it back to the object that changed it. Though doing that would require at least a partial recompile of the project which could take some time.
In modern game design, a lot of this type of information is already being logged so that it can be shipped back to the manufacturer so that they can understand how their software is being used and improve it.
But there are a couple of things to consider. When creating a large development project first and foremost is that the code is broken down in to multiple subgroups of code and resources. So in order to add a specific log to says "who reported the crime", you would end up only recompiling a very small section of the game and not the whole game. Second, the way this usually works is that you capture the current memeory state when tracking down a bug of this nature. You can see what objects are in memomory and where the program is executing. You can then use a custom scenario builder and a binary search to get a very good idea of where the problem is well before ever looking at the code.
Finally, if they are really trying to track something down, you wouldn't play the same scenario over and over again, you would use a scripted to play the scenario. The game makers have a very greate ability to script "user" behavior for testing. In the end the life of a SDET or a game tester is much simplified by using reason to track down problems rather than trying to trace the code.