Troubleshooting Process

Thursday, 7. October 2010

Throughout our all of our lives problems or lesser and greater natures inevitably crop up. How we resolve these problems in large part determines our success in life. The logical process of troubleshooting is very useful both in life and in gaming to determine the real cause of failures, so is worth examining further in depth.

With any systems there is a line or web (in the case of more complicated situations.) of supporting systems. Its useful to look at some of these as a supporting chain in which any failure within it will produce an overall system failure. In addition, the first chain within any loop is the core supporting structure and even small deviance’s in this can cause cascading failures throughout the system.

Each failure within a supporting system causes a specific kind of result, which may or may not be shared by others within the system. These results have to be sifted through and tested to find the real root cause of the problem.

In order to get into this, a Sherlock Holmes cap and pipe is needed along with some patience and wherewithal. That is of course because with the overall failure is just a superficial covering of the problem at hand. It is a small set of clues, nothing more. Enough of these clues pieced together begin to reveal a real picture Hastily deciding without proper information produces the wrong result most of the time, with emotional time and monetary cost attached. I’m not aware of anyone who enjoys that.

Our process looks something like this
1) Analyze the method of failure
2) Determine which systems could’ve possibly been involved.
3) Start by looking at deviances and failures in the base levels of the supporting system.
4) Systematically work through supporting systems until a cause of failure is found. One of the fastest methods of doing this is halving. You got to the midway point, examine if everything is OK. If it is, you proceed halfway between the systems again and check. If its not.. you’ve got half the systems on the other side to check and find the problem.
5) Fix cause the cause of the problem.
6) Verify your work.

The easiest real life application to this is with electronics. There is a easy straight chain of systems that have to be sorted through, with the base system most likely being a power supply. Any deviance in that will cause issues throughout the rest of the system. The same method is easily usable with any sort of mechanical process, but can be used to sort through social processes and attempt to analyze them as well… it’s just considerably more difficult in that case to pinpoint a cause.

Just as an easy example from a gaming or teaching standpoint, we can examine lets say something simple such as dice results, or on a more complicated end player satisfaction with a game (Or conversely, GM satisfaction.)

In the case of dice systems, it’s not performing as we’d like it to.. so going off of the chart above
1) Results are either consistently too high, or consistently too low. Or too inconsistent period.
2) Dice, throwing method (D4′s in particular do not like to throw randomly for me.)
3) Throwing method is easily tested with an entropy tower, or simply giving a good toss simply to get randomization. Looking at the dice – results are based off of what the average for the set should be
4) Eliminating the toss, our dice used is the problem
5) Either adjust the difficultly, or use a different dice method that produces results more consistent with what you want.
6) Test the fix!

In the case of lets say, player satisfaction is considerably deeper.
1) Player is unhappy with X
2) Game results, storytelling, Player them self
3) The base systems in this case would be the player and the GM. Some simple questioning after the fact should reveal if everything is normal. If it’s not.. you may have found your fix there.
4) Look at all of the variables. The player may have had a real bad day or week. You as the¬†storyteller may be pissed off at them for whatever reason and it’s showing. The type of game you’re running may not be what they’re wanting to play.
5) Get the problems resolved!
6) Test session, next game~

That’s probably an oversimplification in a lot of cases, but it’s a methodology that can be used to verify that you are getting the desired results by attempting to work on the correct problem.¬† Some extra time taken in analysis pays off well at the end.

Technorati Tags: ,

Leave a Reply

Spam Protection by WP-SpamFree