[rfk-dev] Request For Comment: robotfindskitten standard

[Tim Allen]

On Tue, Jun 09, 2009 at 11:59:19PM -0700, Peter A. H. Peterson wrote:
> Attached is a draft for a proposed standard for robotfindskitten Zen
> simulation environments. While I've attempted to make it fairly
> comprehensive, it is still a draft and I'm interested in any comments.

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.

RFK-01 wrote:
# Abstract
# 
#    This is the abstract.

I suppose you'll want to fill this in at some point?

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

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

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

# 9.1.1. Success Message
...
# FRAME        DISPLAY
# 1.      #      k
# 2.       #    k
# 3.        #  k
# 4.         #k
#         [heart]
# 5.         #k
# figure 1. Success Animation

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

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.

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

# 9.1.2. Alternate Status Implementations
# 
#    Alternate Status implementations can be appropriate in certain
#    circumstances. To date, the two main reasons are constraint issues
#    and non-character-based implementations.
# 
#    First, hardware/software constraints can require a relaxation of the
#    simulation specification. For example, screen space constraints (such
#    as on the PalmOS or Atari versions) have made the persistent Status
#    too costly to justify.

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

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

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

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

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

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.