This is a proposed hacking simplification for Shadowrun 3E. It retains the dice pools, the operational and special utilities for a deck, the deck ratings, and system ratings. The main changes are to the target number to determine a success, and the elimination of the 28 distinct but ultimately limiting actions into 5 broad categories of actions.
Systems are still identified in the format Security Rating-Access/Control/Index/Files/Slave.
Security Rating is a color code followed by a number. The color code (blue, green, orange, or red) is a shorthand indicator for how quickly the system responds to unauthorized operations. Higher difficulty systems respond faster to the security tally than lower difficulty systems. The number is the size of the dice pool the system will use when attempting to detect or oppose an unauthorized user.
The ACIFS code references the strengths of 5 separate subsystems on a particular host.
Access is used for tests involving access and authorization.
Control is used for tests involving altering or executing commands.
Index is used for tests involving locating files, information, or other resources.
File is used for tests involving uploading/downloading/creating/deleting files
Slave is used for tests to control devices under the direct control of this host, such as maglocks, security cameras, etc.
I also use the security rating as a helper when randomly generating the values for a host. The table below lists the various values that are typically assigned to a particular security rating:
|Rating||TN||Dice Pool||Values||Tally Step|
TN refers to the target number on a d6 for a success. Rather than use the variable target number in SR3, I am using a fixed TN based on the difficulty of the system.
In the simplified system, the hacker determines which of the subsystem or subsystems on the target host he or she wants to interact with each round. The security value for the subsystem indicates the number of successes required to obtain full access to the subsystem, at which point the hacker no longer has to make tests when interacting with that particular subsystem.
Operational utilities that the hacker has loaded into his/her deck will modify this number of successes - the utility rating is subtracted from the subsystem rating, and the difference is the actual number of successes needed, with a minimum of 1 success required.
Note that full control of a subsystem isn't always required for an action; the results of an incremental success (cumulative total of less than the total required) should be communicated to the player as to what new information or actions are now available.
Finally decryption/encryption will be handled as an isolated system. The encryption strength of a remote host can be determined randomly with a value tied to the host's security rating, or assigned a number. A hacker who is encrypting data from his deck will use the deck's MPCP rating to determine the strength of his encryption.