[rfk-dev] bugs

[Peter A. H. Peterson]

Quoting Eric S. Raymond:
> This one is logically mine.  Presently the version number is set in exactly one
> spot - configure.in - and I have bumped it to have a new value (1+sqrt(5))/2
> to reflect the major change in the POSIX codebase.  It doesn't, as you
> have obseved, presently have a minor part.

What do people think about having a release version number -- the
X.YYYY number -- which is relevant for releases, packages, etc., but
at runtime the version number in the status area displays a dynamic
count of the NKIs loaded at startup?

That way, the version number from the perspective of the build tools
is separate from the more whimsical tertiary NKI count.

> The actual fix, therefore, requires scrapping autotools.  I think this
> would be a good idea in general - autotools is hugely overcomplicated
> and heavyweight for rfk's needs.  But it's a larger and potentially 
> more controversial change than I wanted to try to make in combination with 
> merging Alexey's code.

I don't have a particular opinion about this, although I side towards
inertia/tradition/whatever will be easier for downstream packagers/current
maintainers, etc. rather than moving to something which may be nicer
in some sense but could be a headache for others. 

Regardless, I think this is a decision that needs to be made by the
group.

> Note for the future: I am willing to take the laboring oar in maintaining
> the NKI list.

I would prefer to keep that job for the time being, at least for the
official POSIX edition. 

*Most* of the NKI on the list were written either by Leonard or myself,
(with obviously many meaningful contributions by others over the years).
But the NKI list has not grown a lot in the last 10 years, and while
there's room for a lot more (obviously), I am also *very* afraid of an
explosion of NKIs somewhat diluting or diminishing the character of
the game, which has remained essentially stable for 15 years. (It's a
blessing and a curse that NKI creation is so cheap, and external NKI
makes it cheaper in a sense.)

So, while I definitely welcome NKI submissions, I think that if we get
a lot of new NKI candidates, it may become necessary for someone or
some entity (i.e., the list) to do some editorial curating.

Again, this is for the "official list". Once great thing about the
external NKI list feature is that we (or individuals) can distribute
their own NKI lists. I think it would be great to have a whole
collection of NKI lists on rfk.org that are optional or could be
downloaded by fans. (package robotfindskitten-extra!)

> > 4. I'm not sure that I like the bounded playfield.
> 
> I added the frame because (a) I think it looks better that way, (b)
> it's a common visual element with other games written in a nethackish
> UI style, and most importantly (c) it makes the actual game look more
> like the pseudo-screens on the website.

I'll play around wih this more and think about it. I totally get why
the frame makes sense, and there's a part of me that definitely likes
it in a kind of "why didn't we always do this?" way, but it's also an
unanticipated change so I think it's worth the group discussing it
rather than just accepting it passively.

I certainly do not claim to have the final authority on any of these
matters, so it would be great if other people would chime in.

Peter

-- 
Peter A. H. Peterson
Graduate Student Researcher
Laboratory for Advanced Systems Research
University of California, Los Angeles