Re: DIS: Proto: Buy low, sell high
I don't know if it's overdue just yet, but I am getting to assessing all possible proposals tomorrow. On Sat, Jun 24, 2017 at 19:11 Aris Merchant < thoughtsoflifeandligh...@gmail.com> wrote: > On Sat, Jun 24, 2017 at 1:17 PM, omd wrote: > > Proto: Buy low, sell high (AI=2) > > > > Create a Power-1 Rule titled "Stocks": > > > > The following Stocks exist: > > > > Abbr. Name > > - > > CFJCollaborative Finance Journal > > PDFPower Dance & Fitness > > PGPPineapple Growers' Partnership > > RR Renascent Ribbons > > WGSWright Goods & Services > > > > Create a Power-1 Rule titled "Properties of Stocks": > > > > For each Stock, Holdings of that Stock is a player switch whose > > value is a nonnegative integer, default 0. > > > > Intrinsic Value is a Stock switch whose value is a nonnegative > > integer, default 1. > > > > Market Value is a Stock switch whose value is a nonnegative > > multiple of 0.2, default 1. > > > > The Brokor is an office; its holder tracks all switches defined > > in this rule. > > > > Create a Power-1 Rule titled "Buying and Selling": > > > > A player CAN Buy a specified Stock by announcement: the Stock's > > Market Value is increased by 0.2, e pays Agora the new Market > > Value in shinies, rounded down, and eir Holdings of that Stock > > increase by 1. > > > > A player CAN Sell a specified Stock by announcement: the Stock's > > Market Value is decreased by 0.2, Agora pays em the *previous* > > Market Value in shinies, rounded down, and eir Holdings of that > > stock decrease by 1. > > > > The above notwithstanding, a player CANNOT Buy or Sell if one of > > the component actions would fail (including Selling with 0 > > Holdings). > > > > > > Create a Power-1 Rule titled "Turning the Crank": > > > > Turning the Crank (which SHOULD be performed weekly, see below) > > causes each Stock's Intrinsic Value to change according to a > > Random Decision as follows: > > > > Chance Result > > -- -- > > 35% Move by 2 in the direction of Market Value. > > 30% Move by 4 in the direction of Market Value. > > 30% Move by 2 in the opposite direction of Market Value. > > 5% Reduce by 50%, rounding up. > > > > (Moving by X in the direction of Market Value means increasing > > by X if less than it, or decreasing by X if more than it, even > > if the result overshoots; vice versa for moving in the opposite > > direction.) > > > > Furthermore, it increases each player's Balance by the sum of, > > for each Stock, eir Holdings of that Stock times its Weekly > > Dividend, rounded up after the final sum. A Stock's Weekly > > Dividend is equal to half its Intrinsic Value. > > > > Cranks Needed is an integer Agora switch, tracked by the Brokor, > > initially 0. At the beginning of every week, Cranks Needed goes > > up by 1, to a maximum of 3. When Cranks Needed is greater than > > 0, the Brokor CAN Turn the Crank by announcement. In a given > > Agoran Week, the Broker SHALL Turn the Crank until Cranks Needed > > is 0. > > > > > > Create a Power-2 Rule titled "Random Decisions": > > > > The rules may define a process initiated by announcement to > > include a Random Decision, specifying a range of possible > > results and associated probabilities. This means that the > > person CAN select any of the possible results by announcement in > > the same message as initiating the process, and CANNOT initiate > > the process without doing so. Furthermore, e SHALL make the > > selection randomly, following the associated probabilities and > > independently from any other random decisions, using a method > > that allows any other player to reasonably verify e has done so > > correctly (e.g. dice server). > > I generally like this proposal. However, the holdings of stocks might > be better framed as assets, as they are a form of property. Have you > seen the assets proposal? It's resolution is overdue, and I think it > avoids many problems to define things centrally. > > -Aris >
Re: DIS: Proto: Track it on the wiki
Because this has almost the same effect and makes allows all players to fully participate without additional accounts. Publius Scribonius Scholasticus p.scribonius.scholasti...@gmail.com > On Jun 25, 2017, at 2:36 PM, omd wrote: > > On Sun, Jun 25, 2017 at 5:35 PM, Publius Scribonius Scholasticus > wrote: >> What about instituting a rule to strongly encourage all players to list in >> their message the effects their actions would have on specific variables and >> even provisional values for them. I don’t want to take this off list. > > Why?
Re: DIS: Proto: Track it on the wiki
On Sun, Jun 25, 2017 at 5:35 PM, Publius Scribonius Scholasticus wrote: > What about instituting a rule to strongly encourage all players to list in > their message the effects their actions would have on specific variables and > even provisional values for them. I don’t want to take this off list. Why?
Re: DIS: Proto: Track it on the wiki
As to officers’ tooling, this could also be handled as a strong encouragement to share your code with your successor. Publius Scribonius Scholasticus p.scribonius.scholasti...@gmail.com > On Jun 25, 2017, at 2:31 PM, omd wrote: > > On Sun, Jun 25, 2017 at 1:33 PM, Alex Smith wrote: >> One of the huge strengths of Agora is that its entire history can be >> deduced from the weekly/monthly office reports, making it easy to >> determine facts about past gamestates; and all actions also go via the >> lists, so you can interpolate the gamestate in between, as well. > > I agree, which is why my proposal would still have reports and actions > being sent to the lists - the wiki would basically serve as a > substitute for players manually performing that interpolation, in > order to allow for more fast-paced gameplay. (It would also serve as > the basis of reports, of course.) > >> I'm in favour of more office automation but I'd rather it be done via >> parsing messages sent to the lists, rather than requiring actions to be >> entered externally. > > Do you object to systems that require (or at least strongly encourage) > actions to be entered externally, but send automated messages to the > lists reflecting them? Requiring players to manually send messages in > a parseable format is definitely also viable, but I like it somewhat > less for various reasons, including the confusion caused if they get > the format wrong. > > Also because there's the potential for less-than-fully automated > updates, which can be more flexible. In the future (again, not > proposing this for the present), imagine the wiki could be configured > to just send each change to a given page as a diff to the list, along > with the edit message. Then, we could define the edit message as the > canonical action from the Rules' perspective, but players would be > expected to make substance of the edit reflect the effects. For > example, I could make an edit with the message "pay ais523 2 shinies", > and the diff would change our balances to suit. I think this would > actually be pretty readable, not just a form of spamming the lists - > you could tell pretty easily from the diff whether the action was > carried out correctly, and having the old and new state in the message > would actually be helpful in understanding the context of the action. > > Compared to this, a fully automated shiny tracking system would be > preferable in some ways, but would be more dependent on the whims of > whoever wrote the code, harder to modify to account for rule changes, > harder to transition between recordkeepors, etc.
Re: DIS: Proto: Track it on the wiki
What about instituting a rule to strongly encourage all players to list in their message the effects their actions would have on specific variables and even provisional values for them. I don’t want to take this off list. Publius Scribonius Scholasticus p.scribonius.scholasti...@gmail.com > On Jun 25, 2017, at 2:31 PM, omd wrote: > > On Sun, Jun 25, 2017 at 1:33 PM, Alex Smith wrote: >> One of the huge strengths of Agora is that its entire history can be >> deduced from the weekly/monthly office reports, making it easy to >> determine facts about past gamestates; and all actions also go via the >> lists, so you can interpolate the gamestate in between, as well. > > I agree, which is why my proposal would still have reports and actions > being sent to the lists - the wiki would basically serve as a > substitute for players manually performing that interpolation, in > order to allow for more fast-paced gameplay. (It would also serve as > the basis of reports, of course.) > >> I'm in favour of more office automation but I'd rather it be done via >> parsing messages sent to the lists, rather than requiring actions to be >> entered externally. > > Do you object to systems that require (or at least strongly encourage) > actions to be entered externally, but send automated messages to the > lists reflecting them? Requiring players to manually send messages in > a parseable format is definitely also viable, but I like it somewhat > less for various reasons, including the confusion caused if they get > the format wrong. > > Also because there's the potential for less-than-fully automated > updates, which can be more flexible. In the future (again, not > proposing this for the present), imagine the wiki could be configured > to just send each change to a given page as a diff to the list, along > with the edit message. Then, we could define the edit message as the > canonical action from the Rules' perspective, but players would be > expected to make substance of the edit reflect the effects. For > example, I could make an edit with the message "pay ais523 2 shinies", > and the diff would change our balances to suit. I think this would > actually be pretty readable, not just a form of spamming the lists - > you could tell pretty easily from the diff whether the action was > carried out correctly, and having the old and new state in the message > would actually be helpful in understanding the context of the action. > > Compared to this, a fully automated shiny tracking system would be > preferable in some ways, but would be more dependent on the whims of > whoever wrote the code, harder to modify to account for rule changes, > harder to transition between recordkeepors, etc.
Re: DIS: Proto: Track it on the wiki
On Sun, Jun 25, 2017 at 1:33 PM, Alex Smith wrote: > One of the huge strengths of Agora is that its entire history can be > deduced from the weekly/monthly office reports, making it easy to > determine facts about past gamestates; and all actions also go via the > lists, so you can interpolate the gamestate in between, as well. I agree, which is why my proposal would still have reports and actions being sent to the lists - the wiki would basically serve as a substitute for players manually performing that interpolation, in order to allow for more fast-paced gameplay. (It would also serve as the basis of reports, of course.) > I'm in favour of more office automation but I'd rather it be done via > parsing messages sent to the lists, rather than requiring actions to be > entered externally. Do you object to systems that require (or at least strongly encourage) actions to be entered externally, but send automated messages to the lists reflecting them? Requiring players to manually send messages in a parseable format is definitely also viable, but I like it somewhat less for various reasons, including the confusion caused if they get the format wrong. Also because there's the potential for less-than-fully automated updates, which can be more flexible. In the future (again, not proposing this for the present), imagine the wiki could be configured to just send each change to a given page as a diff to the list, along with the edit message. Then, we could define the edit message as the canonical action from the Rules' perspective, but players would be expected to make substance of the edit reflect the effects. For example, I could make an edit with the message "pay ais523 2 shinies", and the diff would change our balances to suit. I think this would actually be pretty readable, not just a form of spamming the lists - you could tell pretty easily from the diff whether the action was carried out correctly, and having the old and new state in the message would actually be helpful in understanding the context of the action. Compared to this, a fully automated shiny tracking system would be preferable in some ways, but would be more dependent on the whims of whoever wrote the code, harder to modify to account for rule changes, harder to transition between recordkeepors, etc.
Re: DIS: Proto: Track it on the wiki
I concur with ais523's thoughts, but would appreciate if e could describe the reasoning for his dislike of GitHub. Publius Scribonius Scholasticus On Sun, Jun 25, 2017 at 10:33 AM, Alex Smith wrote: > On Sun, 2017-06-25 at 12:53 +, comex wrote: > > On Sun, Jun 25, 2017 at 1:28 PM Alex Smith > > wrote: > > > Serious, strong objection to this. If I have to have a Github > > > account to play, I'll just deregister. > > > > If your reason for avoiding GitHub is what I think it is, IMHO it’s > > misguided… > > > > ..but no worries, that’s just my opinion. If this passes and > > assuming you > > don’t change your mind, I can just set up a different wiki. > > To be clear, although I dislike Github in particular, I'm also very > wary of anything that requires the use of a website external to the > mailing lists to be able to play. > > One of the huge strengths of Agora is that its entire history can be > deduced from the weekly/monthly office reports, making it easy to > determine facts about past gamestates; and all actions also go via the > lists, so you can interpolate the gamestate in between, as well. > > I'm in favour of more office automation but I'd rather it be done via > parsing messages sent to the lists, rather than requiring actions to be > entered externally. > > -- > ais523 >
Re: DIS: Proto: Track it on the wiki
On Sun, 2017-06-25 at 12:53 +, comex wrote: > On Sun, Jun 25, 2017 at 1:28 PM Alex Smith > wrote: > > Serious, strong objection to this. If I have to have a Github > > account to play, I'll just deregister. > > If your reason for avoiding GitHub is what I think it is, IMHO it’s > misguided… > > ..but no worries, that’s just my opinion. If this passes and > assuming you > don’t change your mind, I can just set up a different wiki. To be clear, although I dislike Github in particular, I'm also very wary of anything that requires the use of a website external to the mailing lists to be able to play. One of the huge strengths of Agora is that its entire history can be deduced from the weekly/monthly office reports, making it easy to determine facts about past gamestates; and all actions also go via the lists, so you can interpolate the gamestate in between, as well. I'm in favour of more office automation but I'd rather it be done via parsing messages sent to the lists, rather than requiring actions to be entered externally. -- ais523
DIS: My public key to secure our messages
Hi, attached you'll find my public key Publius Scribonius Scholasticus (E8A213A2) You can use this key to encrypt and secure our messages. To start using it, you'll need to install an OpenPGP software on your computer. Below you'll find a list of possible solutions for your operating system: OS X https://ssd.eff.org/en/module/how-use-pgp-mac-os-x Linux https://ssd.eff.org/en/module/how-use-pgp-linux Windows https://ssd.eff.org/en/module/how-use-pgp-windows-pc iOS https://itunes.apple.com/app/ipgmail/id430780873?mt=8 Android https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain Please import the public key into your local OpenPGP Key-Manager. Looking forward to exchange snooping-free messages with you. Regards , Publius Scribonius Scholasticus
Re: DIS: Proto: Track it on the wiki
What do you think eir reason is? Regardless, I will also be voting against because of both ais523’s objection and my own feeling that we should try to contain the game. Publius Scribonius Scholasticus p.scribonius.scholasti...@gmail.com > On Jun 25, 2017, at 5:53 AM, comex wrote: > > > On Sun, Jun 25, 2017 at 1:28 PM Alex Smith wrote: > Serious, strong objection to this. If I have to have a Github account > to play, I'll just deregister. > > If your reason for avoiding GitHub is what I think it is, IMHO it’s misguided… > > ...but no worries, that’s just my opinion. If this passes and assuming you > don’t change your mind, I can just set up a different wiki. >
Re: DIS: Proto: Track it on the wiki
(...argh, I thought the Gmail mobile app would strip the copied and pasted formatting, but apparently not. Enjoy the huge text…)
Re: DIS: Proto: Track it on the wiki
On Sun, Jun 25, 2017 at 1:28 PM Alex Smith wrote: > Serious, strong objection to this. If I have to have a Github account > to play, I'll just deregister. If your reason for avoiding GitHub is what I think it is, IMHO it’s misguided… ...but no worries, that’s just my opinion. If this passes and assuming you don’t change your mind, I can just set up a different wiki.
Re: DIS: Proto: Track it on the wiki
On Sat, Jun 24, 2017 at 10:09 PM Gaelan Steele wrote: > I like the idea of having separate repositories per report (like we have > now), which also allows recordkeepors to manage their tooling (under this > rule, I couldn't keep the rules in YAML, for example). I think we should > keep anything on GitHub as unofficial, which allows record keepers to do > whatever they wish with regards to citizens updating the report (possibly > with an Agency or Organization providing an incentive to do so). Well, the ruleset is something I’d very much not want to track on the Wiki, because (a) it doesn’t change that often, and (b) it’s easy enough to screw up that it should be the job of a somewhat trusted player, or at least someone who knows it’s eir responsibility and takes it seriously - not ‘whoever feels like updating the wiki’. But I’m sympathetic to wanting to allow recordkeepors to manage their tooling. Basically, I have a few overlapping concerns about the “keep it unofficial” model: - Sometimes recordkeepors have come up with some super fancy tooling, sometimes allowing self-service… and then gotten bored of the job of the game, leaving the next recordkeepor to start from scratch. - In that case and others, if the recordkeepor doesn’t have much direction or perhaps is new to the game, e’s likely to gravitate towards just doing what it says in the rules, not setting up (or even continuing) an unofficial system - especially one that puts semi-high requirements on other players (requiring them to update a website along with their actions). - Most importantly: Recordkeeping style is not always just an ‘implementation detail’. It fundamentally affects the type of rules we can, or tend to, enact. For example, some potential game systems have enough repetitive calculations that they’re infeasible to run without automation; others depend so fundamentally on interpreting human-written text that automation can be of little benefit. We can’t have the former without recordkeepors who know how to program. The latter is a bit more egalitarian, but requires more time commitment and, importantly, waiting time: automation can accept actions 24/7, run trusted, complex computations on them and show everyone the new state, while a human recordkeepor can’t always be online (and has better things to do), and even when actively working on recordkeeping, takes longer to work through things. So there has to be a slower pace, less frequent actions. And then there’s the third option of decentralized human recordkeeping, like what I’m proposing for the Wiki, which is sort of a compromise between automation and centralized human recordkeeping, but not quite the same as either. Latency is avoided because players can update the records themselves, but the bandwidth problem is magnified, as inexperienced players are both slower at making the necessary calculations, and less willing to spend time doing so. Unlike with an automated system, we can call on humans to interpret text if desired, but unlike with a single human recordkeepor, those interpretations can’t be authoritative/trusted. Significantly, even when a game idea is at its core amenable to different styles of tracking, as is usually the case, expectations of which method will be used often influence design decisions. If I’m writing a rule I expect to be implemented with automation, I can throw in random calculations and extra steps ‘for free’ - it does make the rule a bit harder for players to understand, but it won’t cause headaches for recordkeepors. On the other side, proposals are free-form text because we expect a human Rulekeepor to read adopted proposals and manually apply them to the ruleset. What if we wanted to automate it? We could try to design a program that recognizes common proposal idioms (“Amend Rule XXX by replacing… with…”), and maybe it would have a decent recognition rate… but if the proposal system had been designed with that in mind from the start, we’d just ask players to send proposals in diff format. There could be a little online script to assist less savvy players in generating them. On a larger scale, the whole idea that the canonical record of actions is a mailing list reflects a game designed primarily around centralized human recordkeeping - as opposed to automation, which would prefer a webapp, or decentralized recordkeeping, which would prefer a spreadsheet or a wiki. Not that I’m proposing making the wiki a canonical record, at least for now (in the future, if desired, we could probably split the difference by making a generic system for semi-structured wiki changes that also notify the list). But I think it can and should be ‘canonical enough’ to be referenced by SHALLs. Sure, in theory we could design rules around the expectation of a wiki, yet steadfastly avoid mentioning this in the rule text itself, leaving the details to explanatory annotations in proposals and unofficial proclamations from office holders. But why s
Re: DIS: Proto: Track it on the wiki
On Sat, 2017-06-24 at 16:44 -0400, omd wrote: > Proto: Track it on the wiki (AI=2) > > Create Power-1 Rule titled "Wiki": > > The Wiki is located at https://agoranomic.org/wiki/. > > For any state the rules define to be "tracked by all players on > the Wiki": > > - When any player performs an action via public message that > changes that state, e SHALL reasonably concurrently update the > Wiki to note the new state Serious, strong objection to this. If I have to have a Github account to play, I'll just deregister. -- ais523
