[rfk-dev] Request For Comment: robotfindskitten standard

[Tim Allen]

On Thu, Jun 11, 2009 at 09:43:55AM -0700, Peter A. H. Peterson wrote:
> Quoting Tim Allen:
> > RFK-01 wrote:
> > # 5.2. ’robot’ and ’kitten’
> > # 
> > #    The entities ’robot’ and ’kitten’ are likewise not proper nouns
> > #    because they are not a particular robot or kitten but rather their
> > #    archetypical forms within the simulation. robot and kitten MUST
> > #    conform to the same character and translation guidelines as
> > #    ’robotfindskitten’.
> > 
> > I've always felt that treating robot and kitten as ordinary common nouns
> > was sufficiently distinctive and off-kilter that they didn't need
> > a special lower-case rule as well. As for illustrating the archetypical
> > nature of robot and kitten, I've always felt that to say "a robot finds
> > a kitten" would be wrong for the same reason that "an air ripples
> > a water" is wrong.
> 
> This really only applies for the beginning of sentences, etc., since
> ordinary common nouns aren't capitalized otherwise. Making the rule
> for the beginning of the sentence just helps to highlight the
> difference which may not otherwise be obvious to English readers. If
                                                   ^^^^^^^
I'm guessing you mean 'non-English speaking' here.

> it were easy to do so, I could imagine printing "robot" in a different
> typeface, in which case the capitalization at the beginning of the
> sentence wouldn't really be an issue.

I think the RFC text should be updated to make this position more
explicit. Perhaps something like:

    The entities 'robot' and 'kitten' are likewise not proper nouns
    because they are not a particular robot or kitten, but rather
    aspects of the Platonic forces of robot-ness and kitten-ness. This
    distinction MUST be made in all introductory material, documentation
    and metadata, although the technique for highlighting the
    distinction may vary, including but not limited to the use of
    a distinct typeface, colour, or capitalisation for these terms.
    Implementations localised into English MUST use the distinctive
    grammar rules exhibited in the Standard Introductory Text, while
    other languages SHOULD use similarly distorted grammar.

> > # 6. Version Number
> > # 
> > #    The version number of the simulation is the software version number
> > #    of the *current* implementation. The version number MUST follow this
> > #    format:
> > # 
> > #    major.minor.num_nki
...
> I'll change the wording to reflect that the third value is
> *traditionally* the number of NKI in the pool at runtime, and is a
> SHOULD. (Again, shoulds can be ignored for "good reason".) That is,
> unless people think it should simply be OPTIONAL.

Making the num_nki field a SHOULD sounds good to me - if an
implementation happens to have a design that makes the specific number
difficult to determine at the time the version number is displayed, I'd
say that counts as "good reason".

> > Does "[heart]" appear over robot, over kitten, or one heart glyph appear
> > over both?
> 
> Good question. I don't think it matters.

...or one heart glyph over each, I suppose.

It's probably worth mentioning that the canonical presentation is...
whatever it happens to be (I don't happen to have the DOS version handy
right now) but mentioning that alternate renderings are allowed for
platform-specific limitations or capabilities (for example, you could
have one heart glyph over both if you managed to find a vt100-compatible
terminal that supported both Unicode and extra-wide glyphs, or the "<3"
rendering I mentioned).

> > You may wish to mention the preferred heart glyph is U+2665 ♥ BLACK
> > HEART SUIT (if that is, in fact, the preferred heart glyph). Also,
> > regardless of the colour of robot or kitten the heart glyphs should be
> > drawn in red (bonus points for including the CSS3 Color Module by
> > reference, so as to define what 'red' is) or the closest available
> > colour on the platform in question.
> 
> Capital idea! I don't know anything about the CSS3 color module... and
> of course fundamentally the heart and the red color come from extended
> ASCII and CGA colors, so I could reference those as well.

Upon further reflection, it occurred to me that an even more
impressively ostentatious reference would be the keyword values for the
'<color>' type in SVG 1.1, since that's an actual published W3C
recommendation rather than a working draft:

    http://www.w3.org/TR/SVG11/types.html#ColorKeywords

(to save you the click, it's basically just the X11 rgb.txt colours, and
'red' is defined as 'rgb(255, 0, 0)')

Of course, the EGA default 'red' colour wasn't exactly that shade of
red, and I believe the EGA colours very closely approximated the CGA
hardware palette. Wikipedia claims that CGA-bright-red is #FF5555, but
doesn't reference to any formal standard or specification:

    http://en.wikipedia.org/wiki/Color_Graphics_Adapter

As for character set, the official Unicode encoding for the IBM
control-character graphics agrees that U+2665 is the correct glyph to
render the heart:

    http://www.unicode.org/Public/MAPPINGS/VENDORS/MISC/IBMGRAPH.TXT

> > # 9.2. Field
> > ...
> > #    In the RECOMMENDED two-dimensional, character-based robotfindskitten
> > #    implementation, the Field size MUST be limited by the size of the
> > #    application window (that is, the field does not scroll within the
> > #    window). If the application window is resized, the Field SHOULD
> > #    resize to utilize the new window size.
...
> > However, if screen space constraints mean that a screen-sized field
> > would negatively impact the simulation experience, is there an 'ideal'
> > field-size that implementations should aim to reproduce?
...
> I don't know that an ideal field size exists; fully compliant standard
> interface implementations should support at least 80x25 (I would
> think) but I don't think that it's essential to the fidelity. Fields
> that are consistently small will make kitten finding relatively easy,
> but so does user-definable numbers of items in the field; you can
> choose (say) 5 items, and find kitten very quickly. So I don't think
> that matters. On the other end, huge field sizes would be tedious, but
> tedium doesn't necessarily affect the fidelity of the simulation, as
> long as it is still unpredictable. (IMHO)

Finding kitten from amongst two items on a 1000x1000 field is a very
different experience from finding kitten from amongst eight items on
a 4x4 field.  If the standard is trying to define how to reproduce the
simulated-Zen of the original RFK implementation, I think it should
mention default field-size and density values, even if particular
implementations use different values due to technical limitations, or
because the implementation allows the user to configure them.

> > # 10.1.3. Color
> > # 
> > #    If color is available, robot SHOULD be colored gray. robot MUST be
> > #    distinguishable from the background color.
> > 
> > This draft does not appear to offer any guidance on the field's background
> > colour, even in the RECOMMENDED implementation.
> 
> I didn't specify a background color, since terminal background colors
> are usually the choice of the window manager or terminal app. Forcing
> the background to be a specific color doesn't seem important as long
> as the items and robot are all visible against it.

That's a technical limitation of the POSIX implementation, but I would
imagine the original DOS implementation always used a black background,
and other implementations are likely to have to choose a specific
background colour, so the spec might as well suggest one.

> > # 10.2. kitten and Non-kitten Items
> > ...
> > #    The number of non-kitten items SHOULD be configurable before the
> > #    start of a new simulation.
> > 
> > If the intent of this standard is to ensure a consistent kitten-finding
> > experience across implementations, I think it would be wise to specify
> > a default NKI density, even if that density can be configured for each
> > simulation.
> > 
> > The J2ME implementation calculates the NKI density as follows:
> > 
> >     // How many NKIs do we need? 
> >     int numNKIs = width*height/20;
> > 
> > ...where 'width' and 'height' refer to the dimensions of the field.
> > 
> > In practice, I think this yields fields that are slightly too densely
> > populated, but it is a simple calculation.
> 
> Hmm... that's interesting. On the one hand, the spec is trying to both
> codify the "standard implementation" and also leave room for variants.
> So if there should be a standard density, I'd say it should be
> whatever the DOS or POSIX density is for an 80x25 screen and whatever
> the default number of NKI was. 

I agree - what is that density?

> But in general rfk implementations, I don't think the density should
> be a must. I guess we could define a RECOMMENDED density, and explain
> that this is defined as a density rather than a default number of nki
> since screen sizes may vary.

That seems like a good approach.

> > # 10.2.1. Appearance
> > # 
> > #    Appearance of items (kitten and all NKIs) MUST NOT identify kitten in
> > #    any way. In addition, all items (including kitten) MUST be visible,
> > #    discrete, and not likely to be the same between simulations. In the
> > #    RECOMMENDED character-based implementation, each item MUST be
> > #    represented by a character selected pseudorandomly from the printable
> > #    character set. (As seen in figure 2 below.) In any case, their
> > #    appearance MUST NOT indicate in any way which item is or is not
> > #    kitten.
> > 
> > The exact printable character set depends on the glyphs available on the
> > output device, and any readability factors of the presentation. For
> > example, the J2ME implementation uses most of the printable ASCII
> > characters, with the notable exceptions of "." and "`", since on my
> > display they're about two pixels each, and if kitten happened to be
> > represented by one of those in a colour very close to the background
> > colour, kitten might very possibly never be found.
> 
> I suppose I should adjust the wording to specify that "visibility" is
> more important than whether the character is technically "printable".
> But the standard is silent on what is or isn't a visible character
> since a.) that will really depend on the character set, and b.)
> there's no standard way to define it, AFAIK.

I'd say the overarching, ultimate concern is that every item in the
field be readily visible, and it's up to the author of each
implementation to guarantee that is the case. Depending on the platform,
available approaches might include choosing a specific font, choosing
a 'safe' subset of glyphs, choosing a 'safe' subset of colours, or
perhaps simply black-listing pathological glyph/colour pairs.

For example, in the J2ME port I chose to avoid "." and "`", but
I suspect if I'd limited my colour palette to simply bright red, bright
green and bright yellow, I could have kept them.



Tim.