DIS: Re: BUS: [Proposal] The Hexeract
On 3/23/22 11:38, secretsnail9 via agora-business wrote: > I submit the following proposal: > > Title: The Hexeract > AI: 1.0 > Author: secretsnail > Coauthors: Jason pretty much covered the copy editing. So bigger picture thoughts: * I would vote AGAINST this as is. Ultimately there's too little interactivity (that isn't zero-sum) and the hexeract seems overly complex for gameplay that's actually a quite simple grind. The only interactivity really is allowing people to pass your fence without blocking them (which btw would be better as With Support than Without Objection, considering the timescale. This would also enable contracts and promises to facilitate it.). It feels like real-world play would be very individual. * Proposals this big should have a blurb at the top describing them. Your examples should also be blurbs attached to the proposal, not rule text. In fact, writing them as rule text creates the possibility that the rule says two different things (if the example and the mechanic don't actually match up), which can make the game more broken. * This might be more personal preference, but I'd divide this into multiple rules something like: Grids, The Hex & Moves on the Hex, Mountains & the Wincon, The other assets & the Hexor. It'd be more readable and easier to amend this way. But again, that's more-so style. -- nix Herald
Re: DIS: Re: BUS: [Proposal] The Hexeract
On Wed, Mar 23, 2022 at 1:29 PM Jason Cobb via agora-discussion <
agora-discussion@agoranomic.org> wrote:
> > A player CAN swap the locations of two specified spaces by paying a fee
> of
> > 5 Movies.
>
> The grid rule doesn't clearly support this. I think, in general, it
> would be better to avoid modifying the locations of spaces in order to
> avoid questions of what happens when a space's location is set to an
> invalid value.
>
I think it was fine as it was, but it should probably be kept and better
defined because the potential gameplay from it seems worth the trouble.
> Overall this just seems grindy, difficult to track, and not particularly
> fun to play. It also screws over anybody who joins in the middle of the
> round, and it's potentially significantly damaging to miss even a week
> with a free move if other players aren't willing to sell you assets to
> catch up.
>
I adjusted the win condition and how vertokens work to make it more
forgiving for new players. Now a mountain climb only counts towards a win
if you were the most recent person to climb it. Also I changed the tokens
to be liquid and destructible, because why not? This seems like something
that could be easily added to if passed, and I was hoping other people
could suggest changes to make gameplay better.
I've been throwing a lot of ideas around in my head, including:
* making the huge fence much bigger, for example placing a fence on all
spaces with a certain entry for a dimension (but that would be a third of
all spaces and definitely hard to track)
* adding some kind of mines for the products instead of having them come
for payday
* linking the current economy or point system somehow
* adding a way for assets to be stored on spaces
* Making it so only one fence can be on a space at a time and you destroy
fences instead of hopping over them
* Calling the fences gates and making the fee for passing through go to a
player, and have the fee be set by the owner
* Making fences reinforced so they take more to get over
* A way to claim others' fences as your own
I think I also addressed everything else you mentioned in this new draft:
Title: The Hexeract
AI: 1.0
Author: secretsnail
Coauthors:
Create a rule with title "Grids" and the following text:
{
A grid has D dimensions, where D is a positive integer, and where its 1st
through Dth dimensions are defined in the rules. Each finite dimension has
a width of W, where W is a positive integer. A dimension is either wrapping
(syn. wrapped) or non-wrapping (default). A dimension is either infinite or
finite (default).
A location on a grid is a vector with D dimensions, where D is the number
of dimensions the grid has, with each dimension having a value as an entry,
whose Dth entry is a non-negative integer less than the Dth dimension's
width if the Dth dimension is neither infinite nor wrapping. All entries
for a given wrapping dimension are equal modulo that dimension's width. For
example, in a grid with 2 Dimensions of widths 2 then 3, [1,2] would be a
valid location and [2,1] would, if and only if the 1st dimension is
wrapping, also be a valid location.
A grid has exactly one space for each location on that grid.
A space (A) is adjacent to another space in the same grid (B) if it is
possible to once add 1 or once subtract 1 from a single entry in B's
location to get A's location. For example, on a grid with 2 dimensions of
widths 2 then 3, [1,2] would be adjacent to [1,0] if the grid was wrapping,
and not adjacent if it is not wrapping.)
Space A and space B to swap locations is for Space A's location to be
changed to Space B's location, and for Space B's location to be changed to
Space A's location, simultaneously.
}
Create a rule with title "The Hexeract" and the following text:
{
The Hexeract is a grid with 6 dimensions. The 1st-6th dimensions all have a
width of 3.
The Hexor is an office, whose weekly report includes a visual
representation of each of The Hexeract's spaces.
Fence List is a [space on The Hexeract] switch tracked by the Hexor, with
any set of persons as a possible value, and is the empty set by default. A
person "owns a fence on" a space if e is in that space's Fence List. A
space is "fenced" if its Fence List is not the empty set. A space on The
Hexeract can be referred to by its location.
Player Space is a player switch tracked by the Hexor with possible values
from the set on all spaces on The Hexeract, defaulting to [1,1,1,1,1,1].
For a player to move to a space is to change eir Player Space value to that
space. A player is on a space if eir Player Space value is that space.
Fencehops, Fences, and Movies are each a currency, tracked by the Hexor.
Whenever a payday occurs, each active player gains 1 Fencehop, 1 Fence, and
1 Movie.
A player CAN once a month grant 1 Fencehop, 1 Fence, or 1 Movie to a
specified player by announcement.
A player CAN, if e has not already done any of the below this week:
* move to a specified non-fenced space
DIS: Re: BUS: [Proposal] The Hexeract
On 3/23/22 12:38, secretsnail9 via agora-business wrote:
> I submit the following proposal:
>
> Title: The Hexeract
> AI: 1.0
> Author: secretsnail
> Coauthors:
>
> Create a rule with title "Grids" and the following text:
> {
>
> A grid has D dimensions, where D is a positive integer, and where its 1st
> through Dth dimensions are defined in the rules. Each finite dimension has
> a width of W, where W is a positive integer. A dimension is either wrapping
> (syn. wrapped) or not wrapping (default). A dimension is either infinite or
> finite (default).
>
> A location on a grid is a vector with D dimensions, where D is the number
> of dimensions the grid has, with each dimension having a value as an entry,
> whose Dth entry is a non-negative integer less than the Dth dimension's
> width if the Dth dimension is neither infinite nor wrapping. All entries
> for a given wrapping dimension are equal modulo that dimension's width. For
> example, in a grid 2 Dimensions of widths 2 then 3, [1,2] would be a valid
> location and [2,1] would not be.
This is internally inconsistent. If locations are equal modulo the
width, [2,1] is a perfectly valid location that's exactly equivalent to
[0,1].
>
> A grid has a space for each location on that grid, and that space has that
> location as a location.
The second clause seems unnecessary. This should also probably say
"exactly one space".
> A space has a location. A space (A) is adjacent to another space in the
> same grid (B) if you could add 1 or subtract 1 from a single entry in B's
> location to get A's location. For example, on a grid with 2 dimensions of
> widths 2 then 3, [1,2] would be adjacent to [1,0] if the grid was wrapping,
> and not adjacent if it is not wrapping.)
>
> }
"A space has a location" is redundant with the previous paragraph.
As I said on Discord, the use of "you" in this manner is unconventional
and doesn't gain anything. I don't think it's a good idea to either make
the text less legalistic or to introduce pronouns with unknown referents.
> Create a rule with title "The Hexeract" and the following text:
> {
>
> The Hexeract is a grid with 6 dimensions. The 1st-6th dimensions all have a
> width of 3.
>
> Each space on The Hexeract has a list of persons that own a fence on it,
> which is initially empty. A person "owns a fence on" a space if e is in the
> list of persons that own a fence on that space. A space on The Hexeract can
> be referred to by its location.
The "list" should be a switch. You should also consider making it a set,
rather than a list (unordered and ignores duplicates).
> PlayerSpace is a secured Player switch tracked by the Hexor with possible
> values from the set on all spaces on The Hexeract, defaulting to
> [1,1,1,1,1,1]. For a player to move to a space is to change eir PlayerSpace
> value to that space. A player is on a space if their PlayerSpace value is
> that space.
Player should not be capitalized.
"Hexor" is never defined.
The use of UpperCamelCase names is not standard, and I don't think it's
a good idea to introduce it. Also, why is this secured?
"their" -> "eir".
> Fencehops, Fences, and Movies are each a currency, tracked by the Hexor.
>
> Whenever a payday occurs, each active player gains 1 Fencehop, 1 Fence, and
> 1 Movie.
>
> A player CAN once a month grant 1 Fencehop, 1 Fence, or 1 Movie to
> specified player by announcement.
"specified other player"?
> A player CAN, if e has not already done any of the below this week:
>
>* move to a specified non-fenced space adjacent to the one e is on by
> announcement.
When is a space fenced or non-fenced?
>* move to a specified fenced space adjacent to the one e is on by
> announcement, provided e owns a fence on that space.
>
>* move to a specified fenced space adjacent to the one e is on without
> objection from any Player who owns a fence on that space.
>
>* move to a specified fenced space adjacent to the one e is on by paying
> a fee of 1 Fencehop.
>
>* move to a specified fenced space e owns a fence on by paying a fee of
> 3 Fencehops.
>
> A player CAN Build a Fence by paying a fee of 1 Fence, provided e doesn't
> already own a fence on the space e is on. When e does so, e is added to the
> list of players who own a fence on that space.
>
> A player CAN Build a Huge Fence by paying a fee of 5 Fences. When e does
> so, e is added to the list of players who own a fence on each space
> adjacent to the one e is on.
What if e's already in some of those space's fence lists?
>
> A player CAN move to a specified non-fenced space adjacent to the one e is
> on by paying a fee of 1 Movie.
>
> A player CAN swap the locations of two specified spaces by paying a fee of
> 5 Movies.
The grid rule doesn't clearly support this. I think, in general, it
would be better to avoid modifying the locations of spaces in order to
avoid questions of what happens when a space's location is set to an
invalid value.
> A mountain has a name,
