[rfk-dev] Request For Comment: robotfindskitten standard

[Peter A. H. Peterson]

Quoting Leonard Richardson:
> My semi-canon pronouncements:
> 
> 1. It's fine to make sure kitten can be found--more generally, that no
> NKI is generated inaccessible. If I'd had the skills I would have put
> this in the original version.

Sounds good. I'll change it so that this is an optional feature.

> 2. I never capitalize 'robot' or 'kitten', but I don't think it
> matters a whole lot.

Ok. Of course none of this is life or death. But if there are no
objections, I'm going to leave these as MUSTs and try to bring things
(the site, POSIX, and the std.) into line.

> 4. I think the only necessary part of the ending is the "Way to go,
> robot!" message.

Ok. Do people think the animation should be a SHOULD or an OPTIONAL?

> 3. I'm a strong believer in robotfindskittenlike games that don't
> exactly implement the spec, and I don't want the spec to scare people
> off from writing such games.
> 
> 5. In general, I think lots of details of the interface--whether the
> whole field must be visible, where the message goes, what happens when
> the screen shrinks, etc. are accidentals of the first rfk and not
> essentials. I think the essentials are that robot wanders around,
> encountering nki, and eventually finds kitten.

I do agree with both of these, and for the record, the standard is as
much a joke as it is seriousness. If I seem way too into this, it's
because I'm actually entertained by standards, as weird as that is...
so I thought it would be funny to create a one for rfk. It's actually
funnier to me because rfk is so simple and whimsical. I'd like to be
able to quote a standard when I tell people it's not supposed to be
"Robot Finds Kitten".

But perhaps in order to be less pedantic and intimidating, many of the
MUSTs should be changed to be SHOULDs or MAYs. It would obviously be a
shame if anyone was put off from creating a port (even a "bad" one)
because of the standard. For that matter, if people are put off by
even the idea of an rfk standard, please speak up.

Peter

PS:  I can also add a section to specifically encourage other
robotfindskittenlikes and Zen simulations in general.


> On Wed, Jun 10, 2009 at 7:23 PM, Peter A. H.
> Peterson<pedro at tastytronic.net> wrote:
> > 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/ ]=---
> > _______________________________________________
> > rfk-dev mailing list
> > rfk-dev at robotfindskitten.org
> > http://robotfindskitten.org/cgi-bin/mailman/listinfo/rfk-dev
> >
> _______________________________________________
> rfk-dev mailing list
> rfk-dev at robotfindskitten.org
> http://robotfindskitten.org/cgi-bin/mailman/listinfo/rfk-dev

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