SR3R Project Forum

Discussion and debate for the SR3R Project
It is currently Fri Jul 19, 2019 7:55 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Fri Feb 15, 2008 8:28 am 
Offline

Joined: Fri Jan 25, 2008 5:20 pm
Posts: 175
Location: Worcester, MA
One thing that has always bugged me is the security sheath. I like the idea of security tally. I like the idea of progressive security. What I don't like is the idea of variable security sheathes. I mean lets look at the practical matter. When hacking into a rating 4 host (regardless of subsystem rating), you're only going to acquire so much security tally. When hacking into a rating 8 host you're going to acquire security tally much faster, even if the subsystems haven't changed. For that reason I think it's possible for us to create a single security sheath for all hosts that will make life MUCH easier on GM's. It could look as follows (numbers are arbitrary)

Tally - Reaction
9 - Probe
12 - Passive alert
15 - Blaster
18 - Trace
21 - Gray/Black of choice
24 - Red Alert
27 - Security decker

Or whatever. The idea is quite simple if host rating is variable and if decker's TN's are variable (subsystems) based on how tough a system is to crack ... the security sheath REALLY doesn't need to be variable. We can create a single, simple one, that will work in almost all situations. Of course GM's can tailor it to their needs, but if we make it simple and easy to remember (ever 3, or 4, or 5, *something* happens), we will make life easier for everyone.


Top
 Profile  
 
PostPosted: Fri Feb 15, 2008 11:55 am 
Offline
Forum Admin

Joined: Wed Jul 18, 2007 3:11 am
Posts: 903
Hm. While I do think that exactly what appears at each trigger step should be tailored to the host (and we obviously must give several examples of "normal" security sheafs to help indoctrinate GMs), maybe it would be a good idea to standardize the actual trigger step numbers based on security value (color)?

For instance, maybe a Blue host hits a trigger step every 9 points of tally. Maybe a Green every 8, an Orange every 7, and a Red every 6?

This would actually fit in very well with my background tally proposal, which really needs its own thread as well...


Top
 Profile  
 
PostPosted: Fri Feb 15, 2008 12:20 pm 
Offline
Forum Admin

Joined: Tue Jul 17, 2007 11:50 am
Posts: 827
Location: DeeCee
I think what feral is saying is that a system with a security rating of 4 doesn't need to increase the distance between steps because the lower security rating effectively already has. A system with a security rating of 4 will progress, on average, at half the speed of a system with a security rating of 8.

I don't think we need a 'this is THE security sheaf, do not change it', which is what feral may be suggesting (at least that's what I read into his post). But we do need some more samples of valid sheafs we can apply. As feral points out, however, we don't need to break down these sheafs based on easy/moderate/hard (i.e. the security factor), only on the color of the host, if that.


Top
 Profile  
 
PostPosted: Mon Feb 18, 2008 12:27 pm 
Offline

Joined: Fri Jan 25, 2008 5:20 pm
Posts: 175
Location: Worcester, MA
Yeah I'm not saying there should only be one for everything. I AM saying we should reinforce the idea that the steps have no need to change between host ratings or colors. Currently host rating is directly proportional to how fast you acquire tally. Color isn't so much, but is directly proportional to how bad the responses to tally are. I see no need for any host to have a different step demarcation than any other, just based on color what happens at each step can be different. The host rating and the brutality of the actual responses take care of the rest.

I'm saying don't make it *impossible* for a sheathe to have anything but a step count of 10, just make it so in all of the examples and reinforce the fact that the host rating determines the difficulty and the color determines the severity of response and the actual step factor should rarely if ever vary. This will make it more clear to GMs what they should look like rather than inundating them with far too much variability. This will lead to a more consistent play experience across GMs. All the GM has to memorize then is "something happens every 10" and when creating a host can then focus more on the color and the rating. Of course some people want to make crazy hyper-unique hosts with insano-variable subsystem ratings and vanishing sans and pavloft IC and all that other garbage, but really push the idea of a simple and consistent base case for generic play.


Top
 Profile  
 
PostPosted: Mon Feb 18, 2008 1:55 pm 
Offline
Forum Admin

Joined: Wed Jul 18, 2007 3:11 am
Posts: 903
Or at least a solid core foundation for building the more complex concepts on. Start with default trigger steps, and a default sheaf for each color. then add the exceptions like customized sheafs, linked networks, vanishing SANs, etc. on top of the base example. Okay, I can definitely see that.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group