This is the third, final, and largest part of this series, which examines the lessons in problem-solving that I learned through training as a fire warden and as a systems analyst back in the early 90s, as applied to an RPG context. The goal is offer practical techniques that can be used to get a GM or a player through whatever difficult situation they may encounter. Part One offered some general advice, while Part Two took a detailed look at the subject of setting priorities, and used the example of a GM needing to fit game prep into a limited time window. With the series originally intended to be a single article, this concluding chapter will warp up the subject with some more practical techniques and advice to get you out of trouble.

Can information gathering occur concurrent with rapid action?

You can’t act decisively without facts to base your plans apon, but every moment that passes gives a problem time to grow, so immediate and decisive action is required. This is a classic dilemma that military and rescue personnel face on a regular basis, and some of the advice already offered – “What can you do Right Now?, and Part two’s entire discussion on breaking problems up and prioritizing the smaller problems – has been aimed squarely at overcoming the conflict between the two mission objectives.

This question considers another way to resolve the conflict. It can also be stated , “do any part of the problem you understand and then reconsider the whole,” but that implies seeing the action started through to its conclusion – and sometimes the information gathered while undertaking immediate action can change the need for, or priority of, that immediate action. If the situation is not what it appears – often the case when dealing with mistaken assumptions or a scheming mastermind – it might turn out that the immediate action is in fact the last thing that should be done.

Still another way of describing this procedure is “positioning your forces ready to act while they gather intelligence on the problem”, and that is often the description applied in a military context; but this suffers from the opposite flaw to the first alternative formulation, in that it implies that all you will do is get ready while gathering information, which can mean failing to take advantage of opportunities when they present themselves.

A fourth way of offering this same advice is to “stir around but do nothing final, and see what happens”. This is tantamount to involving yourself in a situation without a plan while not knowing what that situation is, and implies that any information-gathering will be coincidental and by happenstance, rather than a deliberate priority.

Because all the alternative ways of describing the process are flawed in one way or another, they are less likely to produce a solution when adopted as a policy or tactic than is the primary approach I’ve offered. Furthermore, if the opposition is particularly canny or well-informed (that scheming mastermind again), they may be able to distinguish between these approaches, recognize the shortcomings inherent when one of the alternatives is employed, and then exploit that flaw. This is something PCs should bear in mind when it’s an NPC group opposed to their interests who is trying to solve “the problem”.

What’s changed?

When something that has worked reliably for some time suddenly fails, in whole or in part, the first question should be “What’s changed?” The connection between that change and the new behavior might not be obvious, may be very convoluted, and there might in fact be no connection – but it’s a starting point that can lead to solutions.

One of the systems for which I was responsible in my Systems analyst days had a report listing various things in customer name sequence. It had worked perfectly for years. Suddenly and without explanation, it was listing some of new customers separately to old customers. Clearly something had changed, but nothing seemed obvious. It was eventually discovered that the operating system captured the difference between a Space and a Shift-space, and the department had a new data entry person who had the habit of pressing the shift key to capitalize the client’s name and sometimes hit the shift key a little early. A new step had to be added to the data entry process to strip out any shift-spaces and replace them with ordinary spaces, and a batch job written to clean up the records that were already in the system incorrectly.

You get the same question offered when you start getting system crashes on a computer – “What’s Changed?” Have you installed some new hardware, or new software, that could be interfering with some other process that had been working reliably in the past?

One of my older computers developed the habit of crashing at certain times of day. It could be reliably expected to happen. What had changed? Answer: I had replaced the power board with a generic brand version because I needed to use the old one elsewhere (it had more outlets). When the signals sent over the power lines to switch off-peak hot-water systems on or off reached this new power board, they produced a moment of “dirty” power – I don’t know whether it was a voltage spike or a corrupted waveform instead of the smooth AC input expected – but the old power board had been filtering this out, and the new one was not. This in turn was enough to cause the computer to crash. Part of the problem was that the computer’s power supply unit was getting old, and it was becoming more sensitive as a result. Eventually, it burned out under the unusual input. Replacing it provided a partial solution – instead of crashing the computer, the signal was simply passed through to the soundcard and manifested as audible tones. Only when I got some additional hardware that required putting the larger powerboard back in place, and these tones stopped abruptly, did the whole story become clear – I had blamed the failing power supply and that was only half the problem.

This advice applies far more broadly than just to computers. Whenever a system delivers an unusual or unexpected outcome – whether that’s a system of bureaucracy or of government or of law or whatever – your first question should always be, “What’s Changed?” and your second, “How could that change have resulted in this unusual outcome?” If the unusual outcome is a problem to be solved – and it almost always is a problem for someone, even if the results were beneficial (people like to learn from serendipity) – this is almost always the start of the path to a solution.

No-One’s Perfekt

People make mistakes. Good systems design anticipates this and prepares solutions to identify and correct the mistake before it becomes significant – but those systems are designed and built by people, too, so from time to time something will slip through the cracks. Which is all quite understandable – unless your department is charging the people for whom the system is being developed or maintained four figures an hour for your time, when it becomes simply not good enough?

The bigger and more complicated a system is, the easier it is for a mistake to fall through the cracks.

Another truism of systems development is that a mistake in design that is identified later in the development cycle – in the testing phase, for example – costs at least ten times as much to correct as one discovered at the beginning, during the design process.

Once again, these principles have a reach that goes far beyond the world of software engineering. Consider the Tacoma Narrows Bridge, where a design flaw resulted in catastrophic failure four months after it was built. Warning signs were present in that period, as interviews of motorists revealed after the fact. Presumably, these warning signs would also have been present during construction – but they were either not noticed, went ignored, or the complaints never reached the ears of someone who could do something about them in time. On November 7, 1940, the bridge collapsed and fell into Puget Sound. Whatever correction of the design flaws would have cost during the design phase, it would have been less than if corrective action was taken during the construction phase, which would have been less than solving the problem before it became catastrophic, at which point the entire US$8 million dollar structure had to be replaced.

To some extent, the engineering principles that were responsible for the flaw in design were unknown prior to the collapse, so this problem could be considered an unrepresentative example; so let’s take another: the Hubble Space Telescope.

Initially funded in the 1970s, technical delays and budget problems delayed the project. Originally intended for a 1983 launch, it would not reach orbit until 1990. In particular, congress cut funding during the planning stages; to what extent this contributed to the later problems with the telescope may never be known. Unknown to anyone at the time, despite some warning signs, the equipment used to monitor and control the grinding of the mirror had been incorrectly assembled, causing the mirror to be very accurately ground to the wrong shape. In 1993, a major shuttle mission performed an ingenious repair, and we’ve been going gosh-wow ever since.

I don’t know how much the repair mission cost, but for sure it was more than replacing or repairing the mirror before launch would have been. And that would have been far more than discovering the incorrect installation of the testing equipment during the grinding process. And that, in turn, would have been far more than making sure the testing equipment had been correctly set up in the first place – which would have been done if the potential implications had been correctly identified in the planning stages and appropriate testing specified. Ultimately, a minor flaw in the planning process mushroomed into catastrophic failure, from which the project was rescued by a combination of smart thinking and a lot of money and effort.

The sooner a problem is discovered, the easier it is to fix. It’s as true in engineering and writing novels and RPG adventures as it is in computer programming and systems development. It’s always important to identify and understand the cause of a problem. Sometimes, it is the only pathway to a solution, and for certain it’s the only way to ensure that the problem doesn’t recur – and that it has been solved and not merely hidden from overt view, this time around.

Look beyond the immediate

It’s not at all uncommon for a problem’s consequences to be discovered long before the problem itself – and, as I wrote in part 1 of this series, you have to “Manage Symptoms, Cure Causes” and not the other way around. It’s not at all uncommon for a problem in a process or situation to be completely unnoticeable until some other product or situation attempts to use the flawed product of the original process or situation. You can sometimes find the real cause of a problem, and the correct solution to that problem, by looking at the last step in the process that appeared to work successfully.

I had this rammed home to me recently. I had a problem while preparing the recent review of The Unconventional Dwarf. The article uploaded and saved just fine, but when I went to preview it (to make any final tweaks or corrections to the layout) WordPress kept coming up with a 404 “page not found” error – it was claiming that the article didn’t exist, that I was trying to preview something that WordPress couldn’t find. Eventually, I discovered that my cookie for the site admin pages had been corrupted somehow, and that this formed a key input into telling the WordPress control panel how to do its job (because that was where my preferences were saved). Log out, delete the cookie, and log back in – problem solved.

It’s often worth looking, then, beyond whatever is manifesting the problem, at whatever produced the inputs to that particular process. In fact, the earlier “shift-space” problem that I described is another example of this – at the time that the data was being entered, it appeared to be saved perfectly correctly, and there was no problem in evidence. Only when another process attempted to work with the flawed data did a problem manifest itself – but the problem was not in the process giving incorrect results, that was simply where the symptoms of the problem were manifesting.

“Garbage In, Garbage Out” is a well-known phrase these days, and it describes the situation in the “shift-space” problem to a T. But I have never seen what should now be an obvious corollary: “Garbage Out, Garbage In” when talking about the way one process connects with another. If something strange is happening, it generally pays to look beyond the immediate “something strange” when trying to work out why strange things are happening.

Don’t ignore the waistcoating

A related lesson is summed up in the maxim quoted above. Trying to trace a problem to a particular subsystem ignores the seams in between – and that’s sometimes where the real problem is.

One of the systems for which I was responsible back in my Systems Analysis days started crashing and producing garbage. Part of this system imported information from a seemingly unrelated system run by a completely different department. The latter system was still working perfectly, but whenever this import job was run, it would collapse or parse garbage which was corrupting the database of the system I looked after. It didn’t take long to discover the cause – the effects of inflation on prices had just carried one of the data fields in the file being imported to a new order of magnitude, one that was one digit too long for the importing software. The output, in other words, might have read “1022.48” and the software I looked after could only cope with a number of “999.99” or less. It took only a moment to fix the problem; it took rather longer to write and test a one-off tool to remove the corrupted data and troll through the other departments database to capture the correct information to replace it. It subsequently transpired that the other department had been forced to modify their own system to cope with the extra digit, but no-one had realized that this might have knock-on effects elsewhere in any other system that used that information. Fixing the actual problem was relatively trivial, fixing the overall system ecology – the principles and practices of the department within which I worked – to prevent (or at least to watch for) similar problems arising in the future was rather more difficult.

Reality doesn’t draw hard lines and say “this process ends there” and “this process begins here” – these are artificial limits imposed to aid human comprehension. So far as reality is concerned, it is all one big, ongoing, complex, process. The problem is that we often impose these limits before we really understand what we’re talking about, and are imposing them in order to facilitate that understanding – and sometimes, there is something going on in-between the two processes that wasn’t known about at the time.

If you can’t see anything going wrong in either of the processes, but the outcome is unexpected nevertheless – and this happens all the time in economics and biology and ecologies and a hundred other fields – it’s a sure bet that something is happening in the waistcoating between the two identified processes. And the lesson from The Butterfly Effect is that the waistcoating can be influenced by processes that are unbelievably distinct from the situation being discovered – you just need a long chain of causes and effects to couple the two together.

So if there is no obvious cause for a problem, and hence no obvious solution, don’t ignore the waistcoating.

Document! Document! Document!

I’ve gotten myself into trouble more times than I can count because I didn’t write something down – usually something so obvious, so important, that I would have “no trouble” remembering it. Way back in April 2011 I wrote The failure of …ummm… Memory, the title of which should clue you into how well that usually works out.

Adequate documentation becomes even more important when you’re analyzing someone else’s handiwork, such as when you’re maintaining a computer program they’ve written. Every hour spent on documentation saves five to ten hours time for everyone who subsequently work on that software, every time they have to work on it – provided the documentation is also maintained.

Whenever you are sure that your documentation is adequate, in terms of RPGs, the only thing you can be sure of is that something vitally important is missing – and the best that you can hope for is that what is written there will provide enough context to remind you of what’s missing.

In terms of gaming, a lot of GMs will carefully insert clues to future problems into their adventures. That’s information that will frequently be lost to players who don’t write it down.

The Cheat’s solution to problem creation
I know of absolutely nowhere wherein it is written that the GM needs to have a specific problem in mind when he offers a clue to the solution of that problem. You can drop the clue and figure out what it means later. This keeps the campaign spontaneous, fresh, and unpredictable – but means that it will collapse into a screaming heap somewhere down the track if the players remember that clue and keep trying to fit it in, somewhere, while the GM has forgotten it. The more you rely on improv over prep, the more important it becomes to document what you come up with on the fly.

Allow for human laziness

We all get lazy from time to time. You can’t work continuously, day in and day out, and maintain the same level of dedication to whatever you are doing – whether it’s running a campaign, working a job, or chores around the house. If we could only know when it was vital that we be at the top of our games, we could ease up a little the rest of the time and stockpile our energies for when it really matters. Inevitably, most of the time, we don’t have this information, which means that somewhere, at any given time, someone has taken their foot off the accelerator at the worst possible time, permitting a Balrog or two to slip through the cracks.

They start out small and innocuous, and can usually be penned up and exhibited in the zoo if caught quickly enough, but inevitably some of them will reach full maturity – and that’s when there’s a problem, both for whoever was guarding the henhouse and for whoever is sent in to clean up the mess.

Constant supervision is not the answer; not only is it wasteful of resources, being spied apon constantly has a detrimental effect on both the quantity of work performed and its quality, and ultimately is simply shifting the problem from one set of shoulders to another – waiting for the day when the supervisor is off his game. Even worse, it can become expected that “George” will fix the problem, relaxing the standard of diligence that would otherwise be present.

The only solution is to make allowances for human laziness at the same time as you are making allowances for people making mistakes – and build systems into your processes that test for overlooked consequences and errors of omission as well as errors of commission.

Of course, this is fairly irrelevant when you are the troubleshooter who has to solve the problem after the fact, isn’t it?

Not at all. One of the tasks that must be achieved when first looking for a solution is working out how long you have to come up with a solution and implement it. And that almost always involves working out how long people will take to achieve certain tasks.

You almost always have a little more time than you think. The last minute may be a hour or so long. The last second is often a full minute in length.

Part of the reason for this is that this is reality, and part of it is because, while the GM wants to make things dramatic and exciting, he doesn’t want the PCs to fail, necessarily. So the GM throws minor inconveniences and roadblocks into the path of a solution so that PCs can’t implement it until the last minute, or even the last possible second – and then balances the books by making sure that the players have a fair chance at achieving a solution in the time available.

Always allow for human laziness. His. Theirs. Yours. The GMs. But don’t ever make the mistake of assuming that non-humans have human laziness problems; they may have none, or may have completely different issues to overcome.

Don’t lose track of the clock

If this seems like contradictory advice to that of the previous section, that’s because it is. While most GMs will stretch the time window out to heighten the drama, they won’t view with generosity a failure to be in position to execute the solution when the time comes. Only when the PCs have a solution that to the best of their knowledge will work and is reasonable will the GM consider himself free to take liberties in the name of excitement – coming up with that solution and making all the preparations necessary to implement it is the responsibility of the PCs and their players, and he or she will be scrupulously fair in the meantime – even if that means that they appear to be biased against them. In other words, if the PCs opposition has an advantage over them, expect them to exploit it to the best of the GMs ability because that is what an opposition in that circumstance would do.

That means that there is a hard limit, time-wise, to how long the players can take to find a solution to whatever problems they are confronting. Beyond that point, momentum will carry their enemies to a victory that remains inevitable only because the PCs didn’t find a way to stop it.

The exact measure of that hard limit will vary depending on the circumstances, though the GM will usually drop a hint or two. If he doesn’t, or if whatever hint there might have been has sailed clear over your head, this becomes one of the key pieces of intelligence that the GM expects the PCs to have to obtain as part of their investigations.

Nor should any GM ever guarantee that the PCs will have enough time to find a solution. There are two circumstances in which the GM will usually do the exact opposite:

1. When the GM’s hints that there is a problem that isn’t being addressed by the PCs have fallen on deaf ears until the other side’s plans have had time to mature; or,
2. When the GM wants to run a 13th-hour adventure, which usually means that the enemy “victory” is nowhere near as set in stone as they think it is.

All of which means that it behooves the problem-solver to never lose track of the clock. You might not know what the timeline looks like, you might not recognize a deadline if you tripped over one, but you should always be aware of how long you have spent on a problem – and how long it’s likely to be before the sands of time run out.

This is also true at a metagame level. A GM will only watch the players going around in circles without direction for so long after he’s given them all the clues they should need to at least get started on a solution before he will lose patience. Normally, after presenting a problem to the PCs, the passage of game time shifts to something close to real time, or even slower; when his patience runs out, it’s prone to accelerate in the other direction, and word will reach the PCs that there has been an unfavorable development of some sort – and things have just gotten worse. What happens after that depends on the GM. Some will take pity on the players, who will have undoubtedly become just as frustrated, and offer an increasingly blatant hint – at some price to be dictated by the GM on another occasion. I’m of that sort. Others will let events take their course – so that if the players don’t pull their fingers out, eventually the PCs will simply stand around and wring their hands in despair while the plot comes to its inevitable conclusion, and let the chips fall where they may.

Playing an RPG is all about problem solving (amongst other things), ground that they have had in common with computer-based RPGs since the days of Zork. Time keeps happening in the game; don’t lose track of the clock, and – if you have to – be prepared to go with your best guess and make it up as you go along.

Work within the limits of resources

We’re inching toward the conclusion of this article, but we’re not there yet. In part one, I suggested that people needed to know their tools. The suggestion above is an extension to that principle. You not only know what your tools can do, and how to use them to do it, you need to know what other tools are available and what they can be used to achieve – for those times when your own toolkit is inadequate to a solution.

At the same time, it does no good wishing for moonbeams; “I could solve it in a trice if Pi were equal to four, or if I squared the circle,” just doesn’t cut it. Some problems may be simply too big to be solved with the resources that you can bring to bear, and that’s as true in real life as it is in game prep and for the characters in an adventure.

In a way, that’s what this entire series has been about. After all, problems with easy solutions can be solved right away, with no need for advice from anyone. It’s when you don’t have any easy answers that you want advice. So, when confronted with a problem that seems too large to be solved, you have just two approaches to pursue – and the right answer is probably going to be a combination of both.

Are resources inadequate?

Are your current resources sufficient to solve the problem? If not, you need to work out what else you need, and the obtaining of the necessary becomes a part of the solution.

Can problems be scaled down?

The other approach is to find a way to scale down or isolate your problems, and one of the best ways of doing that is to reduce the resources of the other side (there always seems to be some form of active opposition in these cases). Better yet, you might be able to take the other side’s resources and make them your own, taking two steps forward for the price of one.

When the PCs first arrived in Dimension Halo, the local setting for the adventures within my rebooted superhero campaign, the problems that confronted them seemed too big for them to solve. Organized Crime was running rampant, Corruption was systemic, Joseph McCarthy was US President, there was an oppressive superagency called the S.I.D. which answered to no-one except for the alien mastermind who was the local dimension’s analogue of the greatest Hero the PCs had ever known, and the PCs were very much on their own, with no official authority or sanction of any kind – only a pressing need to get control of these situations.

They started by cleaning up one police department, then achieving popular support, agitating against the repressive regime. From one clean department, they obtained localized authority, and used it to clean up one city council, which enabled them to clean the corruption out of an entire state. They enticed the S.I.D. into public excesses and slowly won the support of the media. Bit by bit, they reduced the scope of the problem, eventually forcing Al Capone out of the Governor’s mansion in Illinois, breaking the back of organized crime, arresting all but one of the justices of the supreme court, obtaining proof of corruption that led to the arrest and conviction of 2/3 of Congress and 3/4 of the Senate, forced the S.I.D. to become a rogue agency, and eventually put the choice of the future to the public in a closely-fought presidential election between a known honest man and their arch-enemy. Eventually, he was isolated and alone, while they had national backing and sanction and mass popular support. The initial situation was completely reversed. No one plan could have accomplished all this; there were too many surprises and plot twists along the way. By acquiring additional resources (public support, official sanction, allies) and denying resources to the other side, one after another, the lines of what was possible and what was not were moved until a solution emerged.

The Insoluble Problem

Even more extreme, some problems seem insoluble. When presented with such a problem, players should always remember that the GM has no interest in presenting them with a genuinely insoluble problem (the NPCs that he has created are a different story). My rule of thumb, as a GM, is to always make sure that there is at least one solution to every dilemma, even if it is not obvious – and where there’s one, there will usually be two or three. Finding one and implementing it are then up to the PCs. The objective is for everyone to have fun, not for me to out-think the players; I’m more on their side than opposed to them.

Accordingly, no matter how insoluble a problem is, there is a solution possible. Failure to find it generally comes down to one of four mistakes: Flawed Logic, Flawed Assumptions, Narrow Focus, or a Fuzzy Reality.

• Flawed Logic – something that seems an inevitable consequence, isn’t.
• Flawed Assumptions – something that is being taken for granted is not as inevitable as it seems.
• Narrow Focus – there is a possible course of action that is not even being considered.
• Fuzzy Reality – the players are applying one or more real-world constraints or restrictions that might not always apply in the game environment.

When confronted with an apparently insoluble problem, how should one proceed? [NB: These techniques won’t always apply to real life problems but are worth trying, anyway.]

Look For The ‘Because’ Contradiction

This works to correct flawed logic and, sometimes, the other causes. List the things you might do and articulate the one salutary reason why it won’t work – then try and envisage a way to change the circumstances so that the ‘because’ you will not inevitably follow. This will usually produce a list of possible courses of action that can be taken to make the insoluble, soluble. One of these will usually be more practical than the others, or will have fewer unwanted consequences, or be more controllable by the PCs, or simply be more tolerable – that’s the one you want. If there are none that fit this prescription, you then need a three-step solution – in other words, you need to further modify the circumstances so that taking that particular course of action will not have the intolerable unwanted consequences, or that will not be so uncontrollable, or will become more practical, or will become more tolerable. Simply keep adding steps to the solution package until you get to where you need to go – or run out of time and need to implement the best plan you have.

Examine The Environment of the problem

This works as a correction when the problem is a flawed assumption. Every problem has constraints that limit the scope for possible solutions, many of which are simply assumed to exist by those looking for a solution. Those assumptions are rarely tested for validity. Redefining the problem in various ways can get around the flawed assumption; when you find something that seems to solve the redefined problem, reconsider the original formulation of the problem to identify the flawed assumption (if any) and verify that this really is a solution to the problem.

Part of this procedure is in considering the characteristics of each of these solution constraints for something that may not necessarily be the case. This may involve some simple testing to discern the difference between the apparent and reality, if any.

This is a technique for thinking outside the box – and remember, a box has six sides – something I pointed out in an earlier problem-solving article, Boxed In: A problem-solving frame of reference for players & GMs alike, which I commend to your attention at this point.

Visualize the situation

Sometimes problems seem to have no solution because of the way you are looking at the problem. This is usually an example of Narrow Focus, in which you simply aren’t considering all the possibilities, and is also something addressed by the “Boxed In” article. If you can see no solution, try looking at the problem from a different viewpoint.

If we’re talking about some sort of physical problem, try a different physical perspective; the use of figures and miniatures and maps and battlemats encourages a top-down perspective, so much so that many people forget that the space they are in even has a ceiling – or has no ceiling. Lock the PCs in a 20′ x 20′ room, with a near-impregnable door and the lock and hinges on the far side, and no apparent exit, and they will start to think about secret doors. Put the actual secret door in the ceiling and it will take them ages to find it – and they will probably check the walls three or four times, first, and maybe try and burn down the door, to boot.

For any other sort of problem, pick a character whose personality you know well, and who is absolutely nothing like that of your own character, and ask yourself how would they solve this particular problem? I like using Dr Doom for this purpose, but it’s not my only option. Once you have a solution, all you have to do is refine it until it becomes acceptable to your character. It’s this sort of “outside the box” thinking that leads to the famous “shoot the hostage” solution in Speed…

Assume you haven’t been told everything

All too often, players assume that they’ve been told everything they need to know when the GM falls silent. I always find it more productive to assume that I haven’t been told everything, and try to work out what I should be asking the GM questions about. This is still another way of testing the parameters of the problem, and you should not be afraid to take that literally as well as figuratively. The wall may only look like it’s made of granite…

Slice The Sausage

Some advice that you often hear when asking how to diagnose a computer problem is to turn off everything that might be causing the problem, and see if it goes away. If it does, then turn things back on, one at a time, until you find the problem returning – and that will tell you what is actually causing the problem.

A similar approach is used to diagnose hardware faults. Borrow someone else’s computer and try replacing each of your suspect components temporarily. Use their hard disk to boot up. Try their graphics card. Whatever. Or, if the component cost is low enough, replace any possible culprit on general principles and see if the problem gets fixed. I’ve heard of a number of cases, for example, where it looked like a disk drive was failing when the real problem was an intermittent fault in the cable connecting the drive to the motherboard – and replacing this $5-$10 part fixed the problem. Or you can plug things into different sockets of the same type on the computer.

The first request of my ISP when people have trouble with their internet connection is to make what they call the “plugs out” test. This involves unplugging phones and everything else that is connected to the phone line except the computer and seeing if you can connect. If you can, plug the other items back in, one at a time, until you isolate the problem. On one occasion, I discovered that the line filter had failed; replacing it brought back my internet connection. On another occasion, I discovered that the phone cable used to connect my modem to the phone outlet had failed – no warning, it was simply completely dead. Both problems were solved a lot more cheaply than getting a technician out to test the actual phone line.

The metaphor that I use to think of all these tests, and similar problem solving approaches, is “Slice the sausage” – in which the “sausage” is the accumulation of all the things that might be the cause of the problem. Remove “the sausage” and then put it back, one slice at a time. I use this metaphor as a reminder to actually employ this problem-solving approach on a broader scale, and to deal with problems other than these specific examples.

The Well of Infinity
I was going to offer an example of an insoluble problem at this point, and then start listing all the things that could be tried as solutions, but time has gotten the better of me. Since it wasn’t going to add materially to the advice offered, I’m going to forego it. I might write it up and tack it on as a fourth part to the series sometime when I’m short of time to write something. For now, though, I’ll just move on…

Don’t Panic

When you’re confronted with the unexpected – or even an expected problem – these immortal words should be the first thing that comes to mind. Panic doesn’t help you think faster, it doesn’t help you think more clearly or more deeply – in fact, it inhibits all of these things just at the time when you most need them.

Keep those two words of advice in mind when you’re implementing whatever solution (however incomplete) that you come up with, too.

Expect the unexpected

After all, if you could see the whole problem, you would also see the whole solution. Since you can’t do the latter, you also can’t do the former – and that pretty much guarantees that there will be surprises along the way.

It can always be worse

Whatever problem you are faced with, it can always be worse than it is, or than it currently appears. Don’t waste effort trying to think of ways in which this could be true; just tell yourself this, and get on with things. Again, this is true in real life as well as in-game.

It can always get better

Similarly, no matter how hopeless things may appear, always remember this. Just because you don’t know how to make this happen doesn’t mean you should stop going through the motions and doing what it is that you do. Again, there are going to be surprises, and at least some of them should be pleasant ones (from your point of view). You may not know how long it will take, either; all you can do is keep going, endure, and wait.

Never Say Die

No-one can possibly implement all of this advice, or you would never do anything but figure out theoretical solutions to your problems. The key to success is to identify which problem-solving strategy is most applicable to whatever trouble is currently confronting you, and employ it. If it doesn’t work, try one of the others. I don’t care if the problem is a real-world one, or a fictional one, or a game-mastering one – the techniques are the same. That’s why these lessons from my past experience apply not only to the context in which they were given, but to any broader context you may encounter.

And you know, there’s very little that is more gratifying than solving a problem that confronts you…