Xconq Development Efficiency

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hello Xconq game developers,

  In a little bit I am going to discuss my Xconq development priorities 
and how I am going to determine them from this point forward, but first 
I wanted to say a big thanks to everyone who has stepped forward and 
contributed to this project. I have been particularly encouraged by 
Coop's and Elijah's work over the past few weeks; it shows that we 
really can get things done if we want to.

  Now, about development priorities:
  As most have probably observed, Xconq hackers (those who develop the 
C code for the Xconq kernel, AI's, and user interfaces) are a bit scarce 
at the moment. Given the limited amounts of time that can be devoted to 
Xconq hacking and the number of bug reports and feature requests, I feel 
it is necessary to reprioritize my development commitments.
  I will continue to observe the principle that bug fixes are generally 
more important than new features. However, I am going to give more 
consideration to how much help the bug reporter or feature requester 
gives me.

  In the case of a bug report, help can be considered the following:
(1) A saved game from which the bug can be reproduced by playing nor 
more than 2 turns. Instructions indicating precisely how the bug can be 
reproduced with the sample file will be considered a plus. (See some of 
Matthew Skala's early posts with attachments for examples of what can be 
considered helpful bug reports.)
(2) A _detailed_ set of observations indicating the circumstances under 
which the bug seems to occur, in the case the bug is now reproducible as 
in (1).

  In the case of a feature request, help can be considered the following:
(1) We discuss the feature request in detail on-list.
(2) After a decent agreement has been reached, the _feature requester_ 
should provide a _simple_ game module containing a playable game in 
which different aspects of the agreed upon tables, properties, and gvars 
can be tested _quickly_ without playing much of the game. The 
not-yet-implemented features can be left commented out so that requester 
can make sure that the module actually loads before posting it to the 
list or sending it to me.

  These criteria are designed to minimize the amount of time I spend 
reproducing bugs or designing testbeds for new features. Hopefully, this 
will allow us to be more productive.

  Of course, any serious bugs, affecting general Xconq gameplay (i.e., 
commonly used games rather than just experimental modules), will be 
given highest priority.

  Aside from those things meeting the above criteria, I will continue 
to develop the SDL interface towards maturity. This should not in any 
way discourage the discussion of bugs or new features....

Eric

P.S. I am going to take care of the 'change-type' bug that Elijah 
reported in Star Fleet Battles a while back ago. It is easily 
reproducible. After that, I am going to continue work on the SDL 
interface unless I get some games showcasing other bugs or feature requests.