[rfk-dev] Request For Comment: robotfindskitten standard

[Peter A. H. Peterson]

Quoting Nathanial Hendler:
> I don't like 10.2.2 rule 2.  I think a programmatic mechanism to
> prevent kitten from being unattainable should be considered ok.  I'm
> ok with either style of game-play, but if I had to specify one as a
> MUST, I'd say that the kitten MUST be attainable.

This is an interesting point, and I can see it from both sides.

Fundamentally, I think the conflict is between the required randomness
in the simulation, and the sense that robot should be able to find
kitten. After all, it is called "robotfindskitten" not,
"robotseekskitten". Is it robotfindskitten if it is impossible for
robot to find kitten? On the other hand, is it a Zen simulation if
there is a mechanism which intervenes to make certain arrangements of
NKI impossible?

I don't want to make it required to have "kitten insurance" because
that actually complicates the code pretty significantly (compared to
the rest of rfk). But with kitten insurance being optional, the result
is that in some implementations you will *always* know that you can
find kitten, but in some implementations you may not be able to find
kitten. Those implementations would then seem inferior and broken.

This issue actually affects Steve's earlier question about what
happens when a screen shrinks, resizes, or rotates, and I think we'll
need to reword those parts.

Forgetting temporarily what should happen when the screen increases in
size, shrinking is actually much more difficult and no consistent
behavior exists. If you shrink the POSIX terminal after starting a
game, very unpredictable behavior results. Section 9.2 para. 2 states
that the field does not scroll, and that the field is limited by the
size of the window. This means then that items may be dropped from the
field (including kitten). Or, if the items proportionately shrink into
the new smaller field, they may combine in such a way as to make
kitten unattainable, or there may be too many items for the space
provided. Also, can items, when shrinking, pass through robot? In
short, shrinking is complicated.

You can think of rotating the Android as shrinking, or you could
rotate the orientation of the field (rotate the characters 90 degrees
in their position, since they're not really on a text terminal). But
this would imply moving the Status to the new "top", which would
theoretically take more lines to print the same NKI (since it's
shorter), which ultimately changes the size of the field anyway; it
gets shorter, but fatter. I guess you could change the font size to
avoid changing the field proportions, but this seems dumb.

So size changing is an inevitability, both shrinking and growing.
Growing is simple; either you move the NKI, or you don't. But
shrinking is complex. What's the best approach? And how does it relate
to your feelings about "kitten security"?

In particular:

1. Should kitten always be attainable? Should we require all
implementations to have a consistent behavior?

2. How should we handle it when the Standard Interface changes shape?

> Regarding 9.1.1 (Success Message), I don't think the animation should
> be a SHOULD.  I agree with the "way to go" message, but I think the
> animation is not critical to the zen simulation, and if anything,
> feels less-zen than the simple message.  I don't like the animation.
> There, I said it.  Not that it's too cutesy, just that it suggests a
> relationship or story between robot and kitten that I think should be
> left to the player in order to fit into my idea of a zen simulator.
> If I was writing this doc, I would have said, "MUST NOT" contain the
> animation, but I'm willing to meet in the middle and leave it out.

Also an interesting point.

However, I think that "You found kitten!  Way to go, robot!" suggests
its own story as well. And in fact, every NKI suggests things within
the simulation and are not left only to the player. Even things like
robot's appearance (#), as abstract as it is, is not left *entirely*
to the player.

In the same way that the simulation of robotfindskitten (as we have
described it) ends with joy at the finding of kitten, I think the
it is appropriate to define that robot and kitten participate in an
eternal, archetypical dance.

That said, I think it is even more appropriate that the Animation be a
SHOULD element. Section 4, paragraph 2 states:

"[ambiguity] complicates the standard because certain design choices
(for example, how to represent robot) are technically open to
interpretation, but in character-based implementations there exists a
unanimous preference (#) that should be respected whenever possible.
As a result, this document attempts to describe the essential elements
of robotfindskitten -- those elements without which a program is not
truly robotfindskitten -- and the elements which are merely strongly
recommended (especially for character-based interfaces) but which are
not strictly required. It should be understood that strong
recommendations should be violated only in special cases and when the
implementor truly understands what he or she is doing."

While SHOULDs are usually avoided due to hardware constraints or other
technical issues, I see no reason why "conscientious objection" can't
be a part of that list. If you think that the Animation is not
robotfindskitten, you have the freedom to leave it out. 

So, I've said a lot here... thoughts?

Peter

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