On Sat, Aug 8, 2009 at 11:34, comex<com...@gmail.com> wrote:
> Why can't we just have an interface that
> - is open-source (so we know what's going on, and can replicate it to
> another server if the original one goes down),
> - is cross-platform (so I can run it),
> - is easy to change (preferably gives recordkeepors the ability to
> change the portions of the code related to their corner of the game),
> and
> - is versioned (so we don't have to fall back to email records to
> check old gamestate, and can more easily verify it)
>
> Then we wouldn't need five competing recordkeeping systems (of which
> BobTHJ's is by far the most complete, but it isn't complete and
> fulfills the least of those goals).
>
My goal is to slowly continue to add information to my database until
the full state of Agora is tracked. Really, I only have proposals,
CFJs and rules to go. Anyway, as I've mentioned before: my intent is
not to force Agora to become dependent upon my automation...but merely
to provide a service to the Agoran community and ease the
recordkeeping burden for officers who wish to make use of it.
After the last conversation on this issue a couple weeks ago I've been
working on re-writing large sections of my code to make it accessible
to others, with the eventual goal of making it available for others to
update and/or replicate. I've still got a ways to go, but once I get
finished with that I will gladly make my source-code available via
FTP. I can't solve the cross-platform issue, sorry. VB.NET is really
my only skilled language, and it'd be a pain to re-write it in
something else at this point (although I believe you can run ASP.NET
on non-windows platforms via Mono - sorry I have no first-hand
experience with this). I added versioning last week (theoretically, my
program can roll-back the gamestate to any point since July 10th when
I started tracking it, and can even adapt to changes in how actions
are processed based upon changes to the Agoran ruleset). Being able to
view the gamestate at a specific point in the past via the
web-interface is a planned feature (and not too far off). I've also
tried to make the code easy to change by extracting each rule-defined
action into its own class/file, allowing most actions to be
constructed with only a few lines of code.
> {
> Players who try to go beyond text processing and actually put some
> Nomic bookkeeping in a program are warned that the complexities are
> subtle. First, such a program should be as easy to modify as the rules
> of the game, or else the difficulty of changing it will put an
> unwanted brake on play. Moreover, it is very easy inadvertently to
> give the program decisions to make that are not actually clerical and
> that belong to the players, that is, to change Nomic without realizing
> it. This is true even of the most deceptively simple decisions such as
> renumbering rules after amendment, computing scores, and deciding who
> plays next. For the same reasons, mere word processing can introduce
> distortions. Decisions necessary to write a program or edit text may
> require a precision not explicit in the rule as written, in which case
> the programmer usurps the power of the game Judge if she simply
> chooses a reading of the rule. In any case, the game Judge should be
> the final arbiter of all questions and decisions, even those made by a
> program, unless of course a rule has changed the role of the Judge.
> }
> -Peter Suber, The Paradox of Self-Amendment
Note that since developing it I've tried to make my program adaptable
to this process. It hasn't been easy to come up with a workable
solution, and it is still not complete, but my system now correctly
models about 99% of the information it tracks. For those exceptions,
I've designed it so I can go back and flag a past transaction as
DISPUTED or FAILED. Upon doing so the gamestate is rolled back to that
point, the corrected results of the action are processed and then the
later actions are re-processed to generate the new correct gamestate.
BobTHJ
