BlogNomic: The Ninth Dynasty of ais523

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?

mixing underscores and camelcase 🤮

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.

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.

I agree with JonathanDark.

  per JonathanDark.

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

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

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. 

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.

[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.

@ 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.

@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.

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?

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.

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”.

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.

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.

@summai, better get used to this style of vote then 😅