[rfk-dev] Request For Comment: robotfindskitten standard

[Peter A. H. Peterson]

Quoting Peter A. H. Peterson:
> 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.

Hi All,

Great comments. I think the standard will be really improved by your
input. Over the next week or so, I'm going to put in all these
changes/comments, and reorganize it a bit. I'll resubmit to the list
for another round at that point.

In particular, I'm going to make the first section of the standard the
elements which are essential for any robotfindskitten implementation
to be compliant. This includes randomness, unpredictability,
terminology, instruction screen, success message, etc. This way,
widely variant implementations (such as OpenGL or even Secret Agent
Clank) could be "unconditionally rfk compliant" implementations of
robotfindskitten. These elements are pretty much completely platform
and representation-independent.

Then, I will define the more restrictive standard for implementations
which *intend* to implement the Standard Interface in a
fully-compliant manner. These implementations could be called
"unconditionally rfk compliant (traditional)" or something like that. 

(Software modules are usually "unconditionally compliant" if they
violate no MUST conditions, "non-compliant" if they violate any MUSTs,
and "conditionally compliant" if they violate any SHOULDs.)

But the benefit here is that this way, versions like J2ME, and OpenGL
could be "unconditionally rfk compliant" but be "conditionally rfk
compliant (traditional)" (or "non-rfk-compliant (traditional)". This
should lower the bar for making unconditionally compliant
implementations (as leonard said, "robot walks around, robot finds
kitten"), while also allowing us to sharply define the elements of the
traditional interface standard, since that's what people usually
implement. (For example, I'd make the animation a MUST for traditional
implementations... but we can debate that if people want.)

Sound good?

Peter

PS: If you have more comments, keep sending them, it's not hard to
integrate them. Also, if you have ideas about what the compliance
terms should be for "general rfk" vs. "traditional rfk", let me know.

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