Welcome! These forums will be deactivated by the end of this year. The conversation continues in a new morph over on Discord! Please join us there for a more active conversation and the occasional opportunity to ask developers questions directly! Go to the PS+ Discord Server.

Technological complexity

3 posts / 0 new
Last post
Arenamontanus Arenamontanus's picture
Technological complexity
One problem I have with the current tinkering system is that it seems too easy to make kitchen sink objects: why not add *all* bioware to a morph, *all* kinds of protection to armour, and so on? Sure, it will increase the price, but there are always someone who can pay the creds or rep. In the case of armour there are some obvious physical limitations, but these hardly apply to morphs. One obvious approach is to make the Hardware or Programming harder for every extra feature. Designing something with 5 extras would have a -50 modifier, discouraging it. However, I think a more fun and realistic approach is to allow it: people can just throw standard nanolibraries into their build however they want. The price is complexity, and in particular the risk that something goes wrong. As we know from software keeping everything modular and secure is very hard as projects grow (my favorite is the Vista speech recognition security flaw, http://blogs.zdnet.com/Ou/?p=416 ) If there are N subsystems there are N(N-1)/2 potential interactions. This means that the device with 4 extras will have 5*4/2=10 possible interactions. Assume that there is 1% chance of a problem per interaction, then the total chance of at least one problem is 65%! So my proposed house rule is that when somebody designs something, it gets assigned a complexity rating N based on the number of things going into it. Then the GM secretly rolls N(N-1)/2 dice, counting the number of 0's. An equal number of dice are rolled again, and the number of 0's here tells the number of hidden defects. They are either randomly assigned to pairs of subsystems or to the whole device. For example, designing an enhanced spaceroach a biologist throws in chameleon skin, extra armor and eelware. That makes 4 systems (roach, skin, armor, electricity) and 4*3/2=6 interactions. Rolling, he gets one bug. Selecting two systems at random it is between the skin and electricity - when the roach electrifies someone its chameleon skin flickers in a very visible way. General bugs might be security flaws (whether software, nanotech or biotech): attackers might gain a +30 bonus, reduced durability, vulnerability to certain conditions, random misbehavior (the railgun plays local mesh entertainment when fired) or emergent effects: the spaceroaches start communicating electrically, the AI gets an extra, unintended motivation. The probability 1% of a bug was mainly set for simplicity. It might be higher for certain kinds of designs (morphs, AIs). In this case, add bugs for 1's, 2's and so on in the second roll. Careful designers of course test their creations (new skill roll, takes an equal time as the design). That gives them the chance to discover one bug if they are successful (and several on critical success; critical failure means a fix introduces a new bug or misfeature). This can be repeated. Really complex designs are possible, but requires a lot of time-consuming testing. Too complex?
Extropian
killj0y killj0y's picture
Re: Technological complexity
I like the concept but i'm leary of adding complexity to a game already somewhat beyond my player's experience. In most systems Cost is a primary motivational factor in allowing for increased power or equipment. The very concept of scarcity goes out the window with respect to most of that when you're dealing with rep based economics. While nothing is ever really free the dedicated gamer can always find a way to turn ladders into 10-foot poles and make a profit. Shadowrun had the nice option of essence but I think here we can't apply new stats without unbalancing the system unnecessarily. In this case we could simply start with a Malfunction Rating of 100%. In a flat morph with minimum mesh you're never likely to run into a problem unless you have a flaw that would otherwise make it an issue like say a genetic defect. As complexity is added simply subtract a progressively larger share of that total at say 1-5% per addition based on cost. The real trick is when to make the check for malfunction. Personally I think you only need to start to worry about malfunction with 2 or more systems are active at the same time. Perhaps even more. I might even be inclined to raise the amount to 75-80% of the systems must be actively in use before I'll check. Now if one of those systems were damaged, say by a blow to the head or stray bullet and they were actively working at the time all bets are off.
Thindelock Thindelock's picture
Re: Technological complexity
killj0y wrote:
As complexity is added simply subtract a progressively larger share of that total at say 1-5% per addition based on cost. The real trick is when to make the check for malfunction.
I would tie this to critical failures. To keep this consistent with other mechanics, where a high stat and a low roll benefit the player, let's call the stat Reliability. Each piece of equipment has it and single-purpose gear starts at 99%. The more bells and whistles packed into a single piece of equipment/morph/etc, the lower the Reliability. When a character is making a roll where the equipment's bonus or capability are important, and he makes a critical failure on the dice, then he gets the usual fun of a crit-fail, and then rolls the Reliability of the equipment. A failure there indicates a system malfunction, left up to GM discretion... perhaps the character takes damage or a statistical penalty, perhaps their infiltration goes awry as the gear glows like a neon sign. Alternately, instead of adding mechanics, one could just use the complexity of Swiss Army equipment as a basis for his description of what happens on a crit-fail. Gets the point across thematically without having to worry about the balance or time-investment of another mechanic.