[rfk-dev] Request For Comment: robotfindskitten standard

[Peter A. H. Peterson]

Quoting Tim Allen:
> Due to timezone issues, I happened to miss the first round of responses.
> Hopefully it's not too late to put my two cents in to the original
> draft.

Not at all. This process will take some time, I expect.

> RFK-01 wrote:
> # Abstract
> # 
> #    This is the abstract.
> 
> I suppose you'll want to fill this in at some point?

Yep.

> # 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
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.

> # 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'm not sure which implementation "current" refers to here, or how
> a simulation (which I assume is code for 'the rfk session the user is
> currently playing') can have a version number - surely all simulations
> run by the same version of the same implementation would share a version
> number? If so, why define it for each simulation individually?
> 
> The current J2ME implementation is tagged as "v1.0", and contains
> a static list of 406 NKIs. Does that mean I should have advertised it as
> "v1.0.406"?
> 
> For implementations which allow the list of NKIs to be edited by the
> user, or allow new NKI sets to be downloaded, should num_nki reflect the
> number of NKIs originally shipped with the implementation, or the number
> of NKIs in the running simulation?

Leonard actually wrote to me about this earlier (off list):

Quoting Leonard Richardson:
> 1. If an implementation loads its NKIs dynamically or for any other
> reason there is no total number of NKIs known when the program starts
> up, we should allow the program's version number to omit the
> number-of-NKIs part.

My thought was that, in the Standard Interface, the version number is
visible at all times, so it would be simple to update the num_nki
value per the given execution. The "current" major.minor (again, this
was my thought) would be for the running implementation. So my Lisp
version might be 0.76 while your J2ME could be 1.0. I think on a
website, etc., it would just be listed by major.minor number, since
dynamic NKIs mean that the num_nki could change between runs.

One potential issue here is interfaces which do not display the
version at all times, e.g. in an About tab, since the num_nki
value is actually potentially unknown at that time. 

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.

> # 8. Instruction Screen
> # 
> #    All robotfindskitten implementations SHOULD display an instruction
> #    screen prior to the first execution of the simulation environment.
> 
> The J2ME implementation starts with a main-menu containing "New Game",
> "Instructions" (which displays the implementation-generic sentences from
> the Standard Introduction) and "About" (which mentions the official RFK
> site). I put it that way because the other games on my phone also
> started with a similar main menu, and I figured anyone who played the
> game more than once would already know what was going on the second time
> around and shouldn't be forced to dismiss an instruction screen every
> time.

I think that SHOULD is appropriate in this case, since the constraints
of the J2ME platform mean that it is not directly implementing the
Standard Interface. I think this is similar to the Palm version in
this way.

> Does "[heart]" appear over robot, over kitten, or one heart glyph appear
> over both?

Good question. I don't think it matters.

> 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.

> #    The fifth frame with the ’heart’ character (which is printed in the
> #    version number line) is OPTIONAL because the ’heart’ character is not
> #    available on all platforms.
> 
> If the glyph is not available, would the ASCII string "<3" be a suitable
> fall back, or should the fifth frame be omitted entirely?

Personally, I like the idea of using the <3 string (one character over
each robot and kitten), but I don't know how others would feel about
this. I would call that an OPTIONAL replacement for a traditional
heart glyph.

Thoughts?

> # 9.1.2. Alternate Status Implementations
> # 
> My phone, using the smallest available font, can display approximately
> four lines of text, so spending three on the status area is a mite
> restrictive. :)

Yes, that's exactly why alternate interfaces are allowed in the
standard. The Palm version used a popup, and it looks like the Maemo
version does something similar.

> # 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?
> 
> Currently, the J2ME implementation creates a new field for
> each simulation, where the height and width are randomly chosen from the
> range 15..30, and as the simulation progresses the field is scrolled to
> keep robot near the centre of the screen.
> 
> I can imagine similar difficulties from the opposite direction for RFK
> implementations in high-resolution environments such as X11 workstations
> or modern Windows or Macintosh environments - running an RFK simulation
> in a field many hundreds of cells wide or high would likely be tedious.

Several good issues here. 

I wrote the text that way so that people attempting to implement a
compliant version of the POSIX version would need to follow that
constraint. 

However, a J2ME version on a small screen is already implementing an
alternative interface, so that rule wouldn't apply. I may need to
include something to make it clear that a non-standard interface
(including field scrolling like on the J2ME version) can still be
compliant.

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)

> # 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.

> # 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. 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.

> # 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.

> Is there a consensus on whether glyph, colour and NKI text should be
> independently chosen, or whether a particular NKI text could always be
> represented by the same coloured glyph across multiple simulations? One
> of the first questions new players tend to ask me is whether "A
> screwdriver" (or whatever) is always represented by a green "j", and it
> does seem a reasonable expectation.
> 
> The J2ME implementation currently chooses glyph, colour and NKI text
> independently, as I suspect most other implementations do.

I actually feel very strongly about this; NKI should not be statically
tied to particular characters, because that makes the identity of the
item more predictable. Of course, if kitten's character were always
randomized, it would not give away kitten's location, but it would
make 'j' into "either kitten or a screwdriver". robot should have no
idea what the item is until robot touches it. It's understandable that
users should ask this, but I think that unpredictability is central to
the rfk experience.

Wow, lots of good questions.

Thoughts, anyone?


-- 
Peter A. H. Peterson, technician and musician.
 ---=[ http://tastytronic.net/~pedro/ ]=---