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)

Re: [TML] Sensors Alex Goodwin 24 Sep 2021 19:01 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.