I would be happy to help you code or annotate, whoever word you are using, each message. ---- Publius Scribonius Scholasticus p.scribonius.scholasti...@gmail.com
> On Sep 28, 2017, at 3:28 AM, Owen Jacobson <o...@grimoire.ca> wrote: > >> This is the first stage of an attempt to create an annotation system >> designed to formalize game state changes by attaching formal descriptions of >> those changes to documents, represented by email messages. At this time, I >> plan only to archive messages, but there will be a read element allowing >> anonymous users to read and enumerate messages from the archive in the near >> future. > > The broader scheme here is this: > > 1. A client app forwards public messages to the archive. They sit in an > “unannotated messages” queue until someone - me, probably - picks them up and > annotates them. > > 2. A user annotates each message with a short formal description of the > game-state changes imposed by a message. These annotations are mutable, so > mistaken annotations are not a permanent problem, and are versioned so that > vandalism can be undone. I haven’t worked out the exact schema for these > annotations, yet, but the concept I’m working with is loosely based on the > RFC 6902 JSON Patch format, adapted for Agora’s specific needs. For example, > an annotation transferring shinies might read, in YAML form for readability: > >> - op: event >> office: Secretary >> summary: o paid Ørjan 1 sh. >> >> - op: transfer >> from: /Shinies/Player/o >> to: /Shinies/Player/Ørjan >> delta: 1 > > Obviously, this is an awkward format, but it has some nice properties that I > think make it worth building on. I’m still tweaking the actual format for > annotaitons, and it’s likely I’ll add a UI or some variety of terse syntax so > that it’s possible to write this kind of simple action in fewer than eight > lines. > > 3. The archive exposes an API that can sum up the annotations, starting from > the beginning of time, all the way up to a specific point in time, and then > return the computed state of the game plus a list of events by office. My > report scripts will become “query this API in a specific way, and feed the > resulting data to a template to render it for email.” > > The idea is that instead of trying to reduce Agora to a set of formal > actions, I instead want to keep the prose forms as the primary documents and > allow formal note-taking alongside them. Many of Agora’s state changes are > formalizable, and from there, those parts of Agora’s state are computable, so > this could take a bunch of load off for computing those parts of the game. > > I’ve had some success with a reduced version of this approach for the office > of Surveyor. All Surveyor’s reports have been generated by a built-to-purpose > Python script that applies the same principles to a set of local YAML files > instead of a web API. > > -o
signature.asc
Description: Message signed with OpenPGP using GPGMail
