[rfk-dev] Request For Comment: robotfindskitten standard

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

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

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.

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

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.

Leonard

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
>