I've centred on using an "Onion topology" for my campaign preparation. I also use a technique, both for campaign and adventure site preparation, whose name (not concept) I've borrowed from the crowd at Dream Pod 9 called "The Y-Cubed Law".
Onion Topology
One mistake I used to make all the time was lavishing waaaaaaaaaaaaaaaaay too much detail on things the players were never likely to find out and, thereby, rob my players of attention to details they were going to be facing constantly in the course of ordinary play from day one. (I blame I.C.E.'s old Campaign Law supplement for this since its step-by-step instructions started with the geography of a whole world including plate tectonics.) The cure, I later found, through much bitter experience, was to stop doing top-down design of my campaign and instead work on it from the bottom up. I later termed this "onion topology".
In onion topology you imagine your campaign world's information is arranged in layers like an onion. First you sketch out a whole onion in very rough detail – this would be things like gods, major continents/nations/whatever-suits-the-scope and other extremely broad-brushed details like that. You then move down to the core of the onion which is where the players are. That core is the immediate environs of where the players will start. In a typical pseudo-European feudal setting (which I will continue using as the example) it could be a single fief with attendant keep, village, outlying manor houses, etc. This you give in detail. You make plans for the keep and the manor houses. You make a map of the village. You place it somewhere in your "whole onion view" and draw up the local terrain according to the rough geography you have already put in place. You populate it with key NPCs (right down to the stats if this is important to your game). You find opportunities for plots via these NPCs. (Reading Georg Polti's The Thirty-Six Dramatic Situations is very helpful here!) You situate any typical adventure sites you want to use in the immediate future: haunted keeps, caves of despair, etc. Then, when everything is ready for your players ...
... you continue planning. Because players never do what you expect them to do. So you fill out the next layer of the onion to nearly the same levels of detail. Maybe you drop some of the finer details like minor NPCs, but you really need to detail one layer of information removed like the overlord's own fief, surrounding subinfeudated neighbours, etc. – anything, in brief, that the players might go to visit on a tangent.
Now you're ready to play. You have enough of a broad-picture view that your campaign isn't completely ad-hoc. You have many details for a smallish area in which you can situate your immediate-term needs for adventures and you have details for a larger area into which your players may suddenly sidetrack so you're not caught with your pants down. From here on in your campaign planning work is easy. Run your adventures. While you're doing that add little details to the next layer out until either your players branch out into it themselves or you're ready to branch out. As soon as they do, you start work on the next layer of the onion, always keeping your campaign details planning one layer removed from where the players currently wander around. This way you have the benefits of planning a campaign (especially the consistency) without the burn-out and the wasted effort. When your campaign finishes your detailed campaign notes will be a patchwork quilt of details and sketchy stuff, but your players will never know. To their eyes you'll have had this wonderfully huge and gloriously detailed campaign that they never reached the boundaries of.
The Y-Cubed Law
Hand in hand with the onion topology I used, since the early '80s, a technique I later grew to call "The Y-Cubed Law" courtesy of the boys at Dream Pod 9. Where the onion topology gives players the illusion of campaign breadth, the Y-cubed law gives the players the illusion of campaign depth.
What I found tending to happen both in my campaigns and others' was that in a bid to bring a place to life people would put in all sorts of interesting local quirks. For example: "In the village of Hothentot the temple bells ring once every ten days at 37 minutes past noon." Or: "In the land-locked city of Kamesh, right in the central square, there is an enormous, 1:1 scale statue of a whale." These are harmless little details of no meaning or merit; just flavour text, really. But ... players will always arrow in on these details and start asking questions. "Why does a land-locked country have a statue of a whale? How would they even know what a whale looks like?" ... and so on ad nauseum. As a player I always found the GMs floundering and looking, frankly, a little stupid as they get blind-sided by such questions and as a GM I floundered and felt, frankly, a little stupid when I got blind-sided.
Enter the Y-cubed law.
In the Y-cubed law, any time you introduce a detail into your setting (or, at its most extreme, into NPCs) you ask yourself the question "Why?" three successive times like this:
- Q: Why does Hothentot ring its bells once every ten days at 12:37? A: They are celebrating the defeat of a horde of bandits.
- Q: Why ten days? A: The bandits were defeated by ten doughty adventurers.
- Q: Why 12:37? A: The time represents the ratio of defenders (ten adventurers plus two hardy locals) and the number of bandits they killed.
There. Now a piece of local colour has something that will stand up to a bit of casual curiosity. It also happens to provide some ideas for possible future adventures. (Where are the adventurers now that the villagers have the wherewithal to actually properly pay them? Were there any surviving bandits who'll come back for revenge?) The total time to ask and answer the Y-cubed can be, after some practice, thirty seconds or so for each detail and yet that minimal time and effort not only gives the illusion of depth but also gives the GM plot seeds that he can use in the future, thus saving time overall.
Best Answer
I figured I'd try to answer the part of the question that most of the other answers haven't really touched on yet, namely "How do I decide whether a particular piece of tech would be too disruptive?"
One way to approach this question is to ask yourself, "How could the players achieve the same effect using things that are listed in the books?" If all the effects of the tech you're considering could already be achieved by other means (even if they might not be quite as practical), it's unlikely to completely break the setting. It might still have an effect on game balance, of course, but you'll at least have some kind of upper bound on how much difference the new tech could make by comparing the difference between the new and the established ways of doing things.
Taking your portable medkit for synthmorphs as an example, you should ask yourself "How else could the players heal a sick or injured synthmorph?" Maybe they can take him/her/it to a hospital; a hospital isn't portable, but it means that all the players are saving by using the medkit is the time and effort to travel to the nearest one. That could still make a big difference, depending on just how far the closest hospital is, but at least it gives you some idea of how big the difference could be. Or maybe your setting has magic as well as tech, and there's already a healing spell that works on synthmorphs, in which case having the medkit just means the players don't necessarily need to bring a mage with healing skills along.
Of course, when using this method, you should generally try to keep the effects of the new tech fairly conservative compared to what already exists in the game. For example, the medkit probably shouldn't be able to fix anything the hospital couldn't. In fact, its abilities should most likely be strictly inferior by a considerable margin, both for the sake of realism and to offset its convenience. Also, since the players can't really keep running to a hospital every few minutes, there should probably also be a limit on how often the medkit can be used, and/or on how long it takes to do its job. And, of course, if the setting clearly implies that something is generally lethal or disabling to synthmorphs, well, the medkit probably shouldn't be able to fix that.
This conveniently segues into another question you can ask yourself, namely "What effects would the existence of this tech have on established (or planned) elements of the setting?" For instance, try to think of any events in the backstory of the setting where having this tech might've made a difference. If you find yourself thinking "Well, those guys sure wouldn't have lost that battle if they'd had these medkits," and you can't think of any good reason why they shouldn't have had them if they existed, that could be an indication that adding that tech to the setting might at least disrupt the consistency of the backstory, if nothing else.
Also, think not just about what your players could or would do with the tech, but also about what their enemies (and other NPCs) could do with it. You're going to need to think about that sooner or later anyway, unless there's some good reason why only the players should have it, so you might as well think about it before you decide that it really exists.
If you have a suitably devious mind, you should also ask yourself "How could I abuse this tech if I wanted to?" Obviously, that means not restricting yourself to how you or the players think the tech should be used, but just looking at the stats as you've written them and thinking "OK, if I wanted to min-max and exploit the hell out of this thing, and had enough resources to pull it off, what could I do?" OK, so one portable medkit seems pretty harmless; what if you had a hundred of them, and combined them with all the most exploity features already in the game, what could you do then?
In particular, beware of anything without limits. A box that can unfold to twice its size is probably harmless. A box that can keep exponentially unfolding forever could easily break the game.
If you're not feeling so devious, a simpler alternative can be to just ask your players up front what they want to do with the tech. Then, if it sounds reasonable to you, write the specs so that it does that and nothing (too much) more. One advantage of this method is that you can harness your players' creativity in finding ways in which the new tech could be troublesome. (In particular, the kind of people who like to come up with exploits for game mechanics are also typically happy to point out those exploits before the mechanics are made part of the game, just as long as they get the chance to demonstrate their cleverness.) It also, in effect, binds the players into an unspoken promise not to step significantly beyond the limits they themselves set, or at least gives you and excuse to step in and say "Hey, wait a minute, that wasn't the way it was supposed to work!" if they do.
Finally, if you're not sure, don't be afraid of saying "OK, let's try it and see." Playtesting is an essential part of balancing the rules of any game, and there's no reason why you can't do that with your house rules too. Just tell your players that they can have the tech for one session to begin with, but that, if it unbalances the game too much, it's going to go away (or be redesigned) for the next session. In extreme cases, you can even tell your players "OK, that was just way too broken, let's just start over and replay the session without it." As long as the players knew in advance that this was going to be a test session, and as long as they can agree that the test didn't work out the way it was supposed to, they'll understand that.