Tuesday, May 09, 2023

Proposal: Traveling

times out fails 1-7 - rt

Adminned at 11 May 2023 12:34:16 UTC

If the Proposal ‘Blaze the Trails’ was enacted add a subrule called ‘Journeys’ to the rule ‘Links’ with the following text:

There is a publicly tracked boolean variable called ‘Allow_Journeys’ that defaults to False.


A Journey has the following attributes:
* A publicly tracked nonempty string called Name
* A publicly tracked boolean value called Ongoing that defaults to False
* A publicly tracked Source that defaults to blank
* A publicly tracked Destination that defaults to blank
* A publicly tracked Mode that defaults to blank
* A publicly tracked number called Passengers that defaults to 0

If there are two distinct Journeys sharing the same Name, the ‘Allow_Journeys’ variable automatically reverts to False if it is set to True.

If ‘Allow_Journeys’ is set to True and the Ongoing of atleast one Journey is set to False, any City Architect may perform the Commence_Journey action. The City controlled by the City Architect performing a Commence_Journey action is called the Conductor for the purposes of said action.

Commence_Journey is an atomic action with the following steps:
* Make a blog post or comment saying “Commencing journey named (Name of J)” where J is a Journey whose Ogoing is set to False
* Set the Ongoing of J to True
* Set the Mode of J to an existing Transit Link T which is between the Conductor and another City C
* Set the value of Passengers of J to be the minimum of the three quantities which are the Capacity of T, the Population of the Conductor and the Population of C
* Roll a DICE2. If the result of the die roll is 1, set the Source of J to be the Conductor and the Destination of J to be C, otherwise set the Source of J to be C and the Destination of J to be the Conductor
* Reduce the Population of the Source of J by the Passengers of J.

A Journey is called overdue if the Mode of the Journey is a Trasit Link and the Ongoing of the Journey has been continuously set to True for atleast as many hours as the Length of the Mode of that Journey.

If atleast one Journey is overdue, any City Architect may perform the End_Journey action which is an atomic action with the following steps:
* Make a blog post or comment saying “Ending journey named (Name of J)” where J is an overdue Journey
* If the Destination of J is set to a City, increase the Population of that City by the Passengers of J
* Set all the attributes of J except the Name of J to their default values.

The enactment of this proposal will automatically create a Journey with Name ‘J1’.

Trying to come up with a mechanism for traveling. A provision has been made so that people cannot suddenly start using this mechanic.

Comments

summai:

09-05-2023 12:38:52 UTC

I am a bit skeptical about the “Commencing/ Ending journey named (Name of J)” lines since they feel open to fall prey to scams. Can anyone suggest an improvement?

redtara: they/them

09-05-2023 17:59:24 UTC

mixing underscores and camelcase šŸ¤®

redtara: they/them

09-05-2023 18:04:07 UTC

jk but I would prefer if we just used words. Took me quite a while to parse things out.

On the substance of the proposal, I might have supported this if we were not going with a resource/trade mechanic, but I feel this will make things rather complicated.

JonathanDark: he/him

09-05-2023 18:20:07 UTC

I feel like it’s not going to be very fun to micromanage Population movement in this way. I’d rather just have simpler formulas that dictate how Populations move from one City or Region to another over time.

Bucky:

09-05-2023 20:29:54 UTC

against I agree with JonathanDark.

SingularByte: he/him

09-05-2023 21:28:35 UTC

against  per JonathanDark.

JonathanDark: he/him

09-05-2023 21:54:46 UTC

against Sorry, summai. They can’t all be winners.

Kevan: he/him

10-05-2023 07:51:12 UTC

against Zero-sum population movement is an interesting idea, but this does seem a bit too fiddly.

Josh: Observer he/they

10-05-2023 08:12:22 UTC

I want to vote for this but I don’t know what a boolean value is. Mathematicians: if you can’t explain your idea to an artist then it’s not simple enough to be a game mechanic.  against

SingularByte: he/him

10-05-2023 08:36:51 UTC

For reference, a Boolean is just a value that can only be True or False (or sometimes just 1 or 0), but yeah, spelling it out can be helpful.

Brendan: he/him

10-05-2023 12:55:19 UTC

against

summai:

10-05-2023 13:24:00 UTC

[redtara] Better get used to this style of writing šŸ˜…. Unless of course this is considered bad practice when writing nomic rules.

[Josh] Youā€™re an artist? Thatā€™s pretty cool. Regarding the boolean thing, I had assumed that this would be pretty standard terminology for a nomic game. Guess Iā€™m mistaken. Iā€™ll clarify from the next time.

Josh: Observer he/they

10-05-2023 13:36:01 UTC

@ Summai Only in the loosest sense. But for sure - nomics do attract a lot of maths and science and IT people, but not exclusively, so some inclusivity in the language is required.

JonathanDark: he/him

10-05-2023 15:07:53 UTC

@summai: I’ve found the hard way that the most successful Proposals, at least early in the game, advance a simple concept. If that is accepted, you then build on it later, or in some cases, take your concept plus others and revise them into a unified larger concept.

In your case for this Proposal, rather than spelling out a complicated way of moving Populations around, start with a simple formula of how a certain number of Population might transfer from one City to another over time, with some sort of trigger. It should be a simple calculation to start with. It may not be exactly what you want in the end, but what you’re trying to do is see if people even like the idea at all.

If that were to succeed, follow up by expanding the formula into multiple steps of an atomic action, but keep the steps small at first. Again, you’re testing the expansion of the original idea slowly.

Keep iterating over that until you get it where you want, or until the player base has decided that it is complex enough and no more complexity is desired.

The analogy in software development is pretty easy to see: iterative development is pretty common. You very rarely throw down complicated code at the very beginning. Rather, you implement one small piece of functionality, test it to make sure it works, then implement the next small thing, and so on, wiring them together over time to make the bigger shippable feature.

summai:

10-05-2023 15:52:49 UTC

I was going to send a private message about this to my mentor, but since you brought it up here, Iā€™ll post this publicly.

The criticism that this proposal seeks to micromanage population movement is entirely valid and I canā€™t fault anyone for not wanting such kind of mechanism.

However, regarding the complexity of the proposal of the proposal, I would argue that this is a simple concept in essence. I just wanted to close it off from potential scams which resulted in the wording of the proposal getting bloated. It is also true that this has resulted in the atomic actions being hard to implement. But like you said I actually intended this to be a starting point of the travel mechanism that is open for further modification, which is why the Allow_Journeys was set to False by default.

What are the ways to avoid this bloat and quasi-complexity in the future? Or is it just that Iā€™ll learn from experience?

JonathanDark: he/him

10-05-2023 16:10:11 UTC

It will probably come from experience, but there may be some guidelines that you could follow. Here’s some that I thought of, and of course these are general guidelines, not strict rules. You may notice a pattern of 3 in several of these, so a “rule of 3” is a good starting point. Also, this is my personal opinion and certainly not enshrined anywhere in BlogNomic itself.

When might my Proposal be too complex?
* If it introduces a new atomic action, and the action has mathematical operations or variable settings in more than 2 of the steps
* If it introduces a new atomic action, and the action has more than 3 steps in total
* If it introduces more than 3 new publicly or privately tracked variables into the gamestate
* If there are more than 3 paragraphs of new rule text that are not replacing existing rule text

As an example, you can see that Expand the Red Tape had more than 3 paragraphs of new rule text, and it is barely passing. Granted, it may not be for this reason alone or even in part, but when people have to read that much text and their eyes begin to glaze over, it doesn’t help your cause of getting support for it.

Kevan: he/him

10-05-2023 16:45:18 UTC

Proposal complexity does always need to play to the tastes of the active players, which changes over time - some people will see a detailed proposal as being too complex for them to follow, others will read an informally phrased one as riskily ambiguous. This is something that drifts back and forth depending on who’s playing, and we do actually seem to have been in a more programmer-oriented era recently.

A good benchmark for how to phrase a proposal is to look at the rules which have enacted recently. Something like the Kickstart rule might be instructive: it doesn’t define, track and scrupulously garbage-collect a bunch of variables, it’s using a plainer English step-by-step list that creates some Regions and casually refers back to “those Regions” in the next line. It’s also blocking an action with a line of ruletext (“No City Architect may carry out the daily communal population increase action.”) rather than setting up a tracked “Allow_Journeys” style boolean - remember that the ruleset itself is just another piece of gamestate, and there’s no real difference between a future proposal of “okay, let’s go, set Allow_Journeys to true” and “repeal the current sentence which says that Journeys are not allowed”.

Kevan: he/him

10-05-2023 16:57:17 UTC

Kickstart’s “Randomly assign Cities to those Regions, such that no Region has more than three Cities in it” is also a good example of something that a programmer would be very tempted to spell out as a complex and unambiguous “first populate a list of Cities, then randomise the order of that list, then pop the first element…” piece of pseudocode, but which (probably!) doesn’t really need to be, so long as the desired fair random outcome is understood.

summai:

10-05-2023 17:28:10 UTC

Thank you JonathanDark and Kevan, your comments were very helpful. Can they be included in the wiki, maybe as player essays for future reference?

Regarding the Kickstart rule, I had voiced my concern saying the rule should say ā€œrandomly assign all cities ā€¦ā€ since the kickstarter could just leave some cities out. But other than that I understand your point of using more casual language so that the proposal doesnā€™t look like technical jargon.

redtara: they/them

10-05-2023 21:01:28 UTC

@summai, better get used to this style of vote then against šŸ˜