Sensors
Jim Vassilakos
(18 Sep 2021 22:42 UTC)
|
Re: [TML] Sensors
Evyn MacDude
(18 Sep 2021 22:51 UTC)
|
Re: [TML] Sensors
Kurt Feltenberger
(18 Sep 2021 23:03 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(18 Sep 2021 23:07 UTC)
|
Re: [TML] Sensors
Kurt Feltenberger
(18 Sep 2021 23:16 UTC)
|
Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Greg Nokes
(18 Sep 2021 23:24 UTC)
|
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Mark Urbin
(19 Sep 2021 14:10 UTC)
|
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Bruce Johnson
(20 Sep 2021 18:55 UTC)
|
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Zane Healy
(20 Sep 2021 23:27 UTC)
|
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Mark Urbin
(21 Sep 2021 00:45 UTC)
|
Re: Crunchy vs Squishy [WAS: Re: [TML] Sensors]
Phil Pugliese
(21 Sep 2021 04:32 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(18 Sep 2021 23:54 UTC)
|
Re: [TML] Sensors
Evyn MacDude
(19 Sep 2021 00:15 UTC)
|
Re: [TML] Sensors
Thomas Jones-Low
(19 Sep 2021 00:08 UTC)
|
Re: [TML] Sensors
Evyn MacDude
(19 Sep 2021 00:33 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(19 Sep 2021 16:57 UTC)
|
Re: [TML] Sensors
Jim Vassilakos
(20 Sep 2021 23:32 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(21 Sep 2021 16:33 UTC)
|
Re: [TML] Sensors
Jim Vassilakos
(21 Sep 2021 20:17 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(21 Sep 2021 21:13 UTC)
|
Re: [TML] Sensors
Kurt Feltenberger
(21 Sep 2021 22:40 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(21 Sep 2021 23:47 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(21 Sep 2021 23:54 UTC)
|
Re: [TML] Sensors Alex Goodwin (24 Sep 2021 19:02 UTC)
|
Re: [TML] Sensors
Timothy Collinson
(25 Sep 2021 17:28 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(25 Sep 2021 19:09 UTC)
|
Re: [TML] Sensors
Nokes.Name
(25 Sep 2021 21:15 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(26 Sep 2021 09:12 UTC)
|
Re: [TML] Sensors
Nokes.Name
(26 Sep 2021 15:43 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(26 Sep 2021 16:43 UTC)
|
Re: [TML] Sensors
Nokes.Name
(26 Sep 2021 16:45 UTC)
|
Re: [TML] Sensors
Timothy Collinson
(27 Sep 2021 07:00 UTC)
|
Re: [TML] Sensors
Bruce Johnson
(27 Sep 2021 17:56 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(27 Sep 2021 23:27 UTC)
|
Re: [TML] Sensors
Timothy Collinson
(27 Sep 2021 07:00 UTC)
|
[TML] Dodgie by name, dodgy by nature(?)
Alex Goodwin
(27 Sep 2021 19:37 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(21 Sep 2021 23:44 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(22 Sep 2021 08:13 UTC)
|
Re: [TML] Sensors
Jim Vassilakos
(22 Sep 2021 14:51 UTC)
|
Re: [TML] Sensors
David Shaw
(22 Sep 2021 15:07 UTC)
|
Re: [TML] Sensors
Jim Vassilakos
(22 Sep 2021 16:26 UTC)
|
Re: [TML] Sensors
Thomas Jones-Low
(22 Sep 2021 20:35 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(22 Sep 2021 19:30 UTC)
|
Re: [TML] Sensors
Rupert Boleyn
(22 Sep 2021 20:30 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(22 Sep 2021 22:36 UTC)
|
Re: [TML] Sensors
Jim Vassilakos
(23 Sep 2021 16:05 UTC)
|
Cian Rants About dTons (Was Re: [TML] Sensors)
Cian Witherspoon
(23 Sep 2021 04:27 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Evyn MacDude
(23 Sep 2021 04:55 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Cian Witherspoon
(23 Sep 2021 06:39 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Rupert Boleyn
(23 Sep 2021 06:54 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Cian Witherspoon
(23 Sep 2021 07:15 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Rupert Boleyn
(23 Sep 2021 06:13 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Cian Witherspoon
(23 Sep 2021 06:46 UTC)
|
Re: Cian Rants About dTons (Was Re: [TML] Sensors)
Rupert Boleyn
(23 Sep 2021 06:57 UTC)
|
Re: [TML] Sensors
Alex Goodwin
(19 Sep 2021 06:16 UTC)
|
Re: [TML] Sensors
Phil Pugliese
(19 Sep 2021 16:46 UTC)
|
On 22/9/21 7:13 am, Phil Pugliese - philpugliese at yahoo.com (via tml list) wrote: > > > On Tuesday, September 21, 2021, 01:18:45 PM MST, Jim Vassilakos - jim. > vassilakos at gmail. com <xxxxxx@simplelists.com> wrote: > > > Alex Goodwin wrote: > > are you designing for _cause_ or _effect_ here? > > I'm not sure what you mean. > > <snip> > Jim, To quote from https://web.archive.org/web/20140220180803/http://www.alanemrich.com/Class/Class_PGD_glossary.htm : "Design for Cause: When a game's design has players follow all of the logical steps and procedures to obtain an outcome; when players experience a methodology and must consider its many facets. This can often lead to systems that are over-engineered. That is, when the players are doing all the work and the designer is having all the fun." "Design for Effect: When a game abstracts complex procedures for simplicity’s sake so that the players can get straight to the "boom." That is, when the designer does all the work so the players can have all the fun." With that chucked in, it sounds like you're going for cause. By contrast (and this may be due to differing player groups wanting different levels of rational knowability), I've gone for effect with Parental Advisory jump drives (nicking liberally from GT:ISW and its parent, GT) 1. J3+ drives may exist, but are unavailable to any polities, groups, etc in the setting (c 2128 AD). Ancients and/or Yaskoydri (who may well have such) are not within the PA setting. J2 is the maximum (modulo misjumps), which lead to this line from me when Easy Frag was having a little trouble wrapping his bonce around the "age of sail" bit: "EF, Nikki is _aboard_ a state of the art communications device." 2. No way is known to _deliberately_ exit Jump into deep space - _accidental_ exits are very possible (the PCs have done this themselves - frinstance, the Goofy Holler). 3. Three separate, successful (MGT2) rolls are required to successfully enter Jump and emerge within 3 Mm per parsec jumped of expected destination. Further, only _trained_ sophont operators making those rolls (not defaulting, using Moustache-level JOAT, or a drone boat) have a chance to catch critical failures by succeeding on a reroll and downgrading the crit fail to a regular one (requiring the Jump attempt to be restarted, which could be an embuggerance itself). These three rather simple, functionally orthogonal, rules have produced the effect on PCs that I was looking for - as the first Terran jump drive only fired up in anger 40 years earlier (in the year of STRAYA's tricentennial celebrations), it's reflecting that almost all deeper Terran knowledge of Jump physics is empirical. Less detail (modulo doing violence to disbelief suspenders) means there's less for some wombat to keep self-consistent. Yes, saying that any form of FTL can "confirm to reality" is a stretch, but that was the most convenient example I had to hand. Returning to Winchell Chung's observations on frameworks (from http://www.projectrho.com/public_html/rocket/prelimnotes.php ): "if you do not have a a framework, you have no clue how much is left to be discovered. The framework _gives you a map of your ignorance_. Basically the framework allows you to see things that are otherwise invisible to you. ... This powerful tool can be applied to your science fiction. If you can construct a framework for some feature of your universe, you can notice concepts that you might have failed to address. Not that you as an author gives a rat's heinie if your framework has holes. But these holes can be valuable sources of plot ideas and innovative concepts to dazzle your readers. Ideas that are a logical consequence of your science fiction universe, and thus will have a plausibility which will impress the heck out of your audience. Because chances are these innovative concepts are currently invisible to your readers. Hey, it beats dealing with writer's block; staring at the keyboard until drops of blood appear on your forehead." An accidental case of the second part of this was me remembering to penalise Nikki's attempts to find buyers for spec cargoes by an amount depending on the size of the system's economy (the up-to-11 hubworld known as Terra doesn't penalise such attempts). This provoked comments (since flogging spec cargoes suddenly became more difficult) along the lines of "ah, he wants us to go where the money is". I will repeat my recommendation for adopting at least the broad outline of how GURPS handles sensor detection - ceteris fnordibus, that approach has approx 2000x of dynamic ... um ... range. The lower bound of the sum of sensor capability, object signature and range to object of -10 is "sensor isn't good enough to even try to detect target" - at the upper limit of that sum of +10, detection is automatic. As x10 range is another -6, that's 3.3 lots of 6 between those two bounds, for the far bound to be approx 2000x (actually 10 ** ( 20 / 6 ) - 2154x ) farther away than the near bound.