Faspeel Game Intro - Memetic Index - 3x3 Chimple Game
Introduction
I want to lay out all of the states and thereby the deployment descriptors that completely describe Faspeel. This should be possible.
States of the Board
The board has four squares and two pieces on it, we'll call them the nickel (in grey) and the penny (in orange). The pieces may not move past one another, and their positions are either "near," or able to bump into one another on the next move, or "away," where one piece must move closer to the other before a bump is possible. All of these positions are symmetric--it doesn't matter whether a piece is "near" on one side or another, and all "away" positions are rotations of one another. Of course, in terms of whether it's "away" or "near" the side of either coin which is showing is irrelevant.
|
|
|
fig. 1.1. "Away" position (starting postion)
|
|
|
fig. 1.2. "Near" position (bump is now possible)
A Simplification to the Board
Actually, have a grid is not strictly necessary. The coins may simply be placed on the table, facing one another, a bit apart. Moving away then becomes literally moving away, and moving near is moving near. The looks more like a "dating game," which is one interpretation of the game. This is useful, since the states of the game (described below) do not strictly accommodate two different ways to be away or near, and this is moreover not necessary.
fig. 1.3. Simplified "Near" (no grid)
fig. 1.4. Simplified "Away" (no grid)
There are two global states, Away and Near. The board is in one of these two states for both players, and if one player changes the state, it changes for both of them.
In addition to the relative positions of the coins on the board, each players board piece, "the show," is either Heads or Tails.
fig. 2. Heads and Tails up of the two types of coins in the game
The Other Coins
Finally, each player has "a message" made of two coins, one covering the other. The other player can only see the top coin, "the cover," while the other is "the secret," known only the player that owns it.
If we ignore the "secret" coins for now, we should be able to elaborate the possible states of the game in the following manner. The whole system state is either Near or Away, so that precedes any deployment descriptor, as we shall see. An example of an "agent state" is penny.ShowHeads, which means that the penny agent has their showing (on the board) coin heads up, regardless of any other states of the board. So the possible states involving just what the penny player has on the board look like:
fig. 4.1. Possible States of the penny player's board coin "the show"
The number of possible states grows rapidly when we consider that "the show" for the nickel player is independent to the penny one
Away.penny.ShowHeads.nickel.ShowTails
fig. 4.2. All "show" states for both players
Next we add the "message" or rather, the "cover" for both players, which increases the number of states by a factor of four. We leave off the "secret" for both players, since it cannot be seen as a state of the board. How a "secret" state impacts the macromemetic behavior of the board. As far as state transitions go, a player decides to do a bump! deployment based on what they can see, and assuming that they will "win" on the outcome, but there are two possible outcomes, one favorable, the other unfavorable.
Away.penny.ShowHeads.nickel.ShowTails.penny.CoverHeads.nickel.CoverHeads
I have a complete table of all the states, including the secret, in the appendix.
This could be written in a generative notation in something like the following fashion:
fig. 4.4. generative notation for all visible states
This says that the deployment descriptor string shall always start with either Away or Near, and will mention penny twice, and nickel twice as well (2). Unlike the complete list above, this notation may not rigorously specify the dependences between the substates of all of the coins (1).
Each state is unique, and we can imagine a long binary number that represents the total state. We have three coins, and they are either "near" or "away" so that's a 7-digit binary number, or 127 different possible states.
Allowed Transitions / Deployments
Now that we've defined all of the states that the system may be in, we can go ahead an describe all of the transitions that the system may make between these states. One way to do that is by writing a bunch of deployment descriptors. These are discussed at great length elsewhere, and they look a bit like the states we outlined above, notation-wise, except for the addition of their having a mention of some agent that is taking some action (deploying a meme) and that it leads to some destination state.
Every state above is going to have at least one transition associated with it. We don't expect any "dead-end" states or "leaf states" so each state is going to have at least one way to get into it, and at least one to get out of it, so we'd expect to have at least 32 deployment descriptors for the system (3).
Movement of "Show" Coins
Either player can move the game from Away to Near, and when Near, either player can decide to bump the other, which then reveals the secret and determines the outcome, returning the system to Away. The bumped player also shuffles their message coins.
fig. 5. "Show" coin movement deployment descriptors
When one of these deployment descriptors happens, the system simply flips from the Away to the Near state or back. As far as the state descriptor, or number, is concerned, as described in the appendix, this is simply a flipping of the lowest order bit of the seven-bit state number.
Flipping the "Show" Coin
Another operation is that a player may flip their "show" coin.
fig. 6.1. Flipping "Show" Coin from all States
The problem is that this is ambiguous, since either player can flip their coin. Here we use agent-state notation (4) to make this clear:
fig. 6.2. Flipping "Show" Coin with Agent-State Notation
Since the show coin may be changed independently from the position (Away/Near) and indeed from the other player or either message coins, we can drop the position state.
fig. 6.3. Remove Explicit Near/Away State, All Deployments
Note that by using agent-state notation, we should be able to update the state directly. In the chart of all the states in the appendix, the heads-tails of the penny player's show coin is the second bit, and that of the nickel player is the fifth bit. So in effect, we can dispense with the start and end states and still have a meaningful deployment descriptor (5). The state is automatically updated by the deployment of this meme (flip!) and the only other change is that it's now the other player's turn.
fig. 6.4. Bare Minimum Deployment
Changing of "the Message"
One thing about "The Message" is that the cover does not need to change, in face, neither coin has to change during a shuffle! but all that the other player can see is "The Cover." So in terms of state, the other player sees that a shuffle took place, and that the cover changed or did not. There is one other state, the "secret" that could have one or another value, unbeknownst. Again, this change is independent from a move between Near/Away or a flip, although it becomes relevant during a bump! (6).
fig. 7.1. Changing the Cover
Bumping
When one player bumps another, the game enters a compelled state (7), "Bump", where the players "score" their situation, count points, and then return to the away state. If we lay this out in complete state notation, where one player wins (the bumpee's coins don't match the bumper) or a "both" win, where both coins match each other. Otherwise, the bumper loses, possibly getting no points while the bumpee may get a point. This looks like:
Near.penny.bump! => Bump.penny.SecretHeads.nickel.SecretHeads.penny.win! => Away
Near.penny.bump! => Bump.penny.SecretHeads.nicket.SecretTails.penny.lose! => Away
Near.nickel.bump! => Bump.penny.SecretHeads.nickel.SecretHeads.nickel.win! => Away
Near.nickel.bump! => Bump.penny.SecretHeads.nicket.SecretTails.nickel.lose! => Away
Scoring
The scoring may be done in a number of different ways. One way is that if the show coin of the bumper matches the secret coin of the bumpee, then both win, each getting a point. Another is to compare both secret coins, and if they match, both get one point. If they don't match, then neither player gets a point, or the bumpee gets a point, the bumper zero.
These systems need to be configured and "gamed" to make the game work best. Alternatively, the game could be played in "aggressive" or "passive" modes, where the bumpee can get points by "tricking" the the other player into bumping in order to achieve a one-sided victory.
We can use game theory to assign reasonable scores to motivate players to play dishonestly, or to try to cooperate.
| Points | Bumper | ||
| Tails | Heads | ||
| Bumpee | Heads | 0, 1 | 1, 1 |
| Tails | 1, 1 | 0, 1 | |
fig. 8.1. Both win on match, otherwise bumpee gets 1, bumper zero
Obviously the bumpee has no advantage in cooperation, so players will be discouraged from bumping. This is the "don't talk to women" scenario.
| Points | Bumper | ||
| Tails | Heads | ||
| Bumpee | Heads | 0, 1 | 2, 2 |
| Tails | 2, 2 | 0, 1 | |
fig. 8.2. Both win on match, otherwise bumpee gets 1, bumper zero
It's good to make the point here that there are virtually unlimited ways to handle the scoring system, and that this will impact the strategies, from a game theory standpoint, of what a player might try to do. This is according to Hoyle, however, since obviously dating behavior is strongly influenced by whether approchers are well-received by approachers, for instance, whether there is a large pay-off or penalty associated with a bad tête-à-tête, or a reward for just trying a lot, without giving it too much thought.
Hypotheses & Deployment Decisions
I am working on the idea of a "hypothesis" that each player can begin to put together about what they other player is "signaling" based upon their show and cover coins. For instance, a player may develop the hypothesis that if the other player is showing both heads, then their secret coin is heads, and they can set up their own secret coin to match this before bumping. Another hypothesis could be that the other players cover always matches their secret, or their show always matches their secret, and go with this hypothesis. A hypothesis may prove to be valid or not, and in the latter case, they may try others.
An hypothesis is basically an "endomemetic" model of the other's behavior. This should be able to be represented as a set of deployment descriptors, for example:
Near.penny.SecretHeads.nickel.ShowHeads.nickel.CoverHeads.penny.bump! => Bump.penny.win!
Near.nickel.ShowHeads.nickel.CoverTails.penny.away! => Away
Near.nickel.ShowTails.nickel.CoverTails.penny.shuffle! => penny.SecretTails
These are some examples of hypotheses where the penny player hypothesizes that if nickel is showing and covering one coin face, then that is the coin face of nickel's secret, and so if one deploys a bump! at such a time, one can expect to win.
We need to sort out the format for deployment decision hypotheses such that they are easy to use and contribute to the economical representation of a memetic system. A basic example of this is how the system is in a given state (8) For example:
Given1 = State1
Hypo1 = Given1.agent-p.meme1! => State2
Given2 = State3.agent-n.meme3!
Hypo2 = Given2.agent-p.meme4! => State5
fig. 9.1. Simple Givens and Hypotheses
A given is a description of the current state of the system, possibly ending in an immunomemetic string to make things more specific. The hypothesis is the bit that describes what the given agent is considering doing, and the expected result. In fact, it could be any other agent, in a multi-agent system.
Given6 = State6
Hypo6 = Given6.agent1.meme1! => State7
Hypo6-1 = Given6.agent2.meme2! => State7-1
Hypo6-2 = Given6.agent3.meme2! => State7-1
Hypo6-3 = Given6.agent4.meme4! => State8
fig. 9.2. Hypotheses in multi-agent systems
The point is that we want a system where we can concatenate deployment strings in a useful and meaningful way. So something like State.agent.meme! => NextState seems reasonable. When the current state of affairs matches the given for a given hypothesis, all of the possible outcomes for the hypothesis are eligible for testing against what happens next.
Tidying up the Bump Notation
One thing we do need to work out, and I reckon it will clarify to no small extent the rest of the hypothesis notation is how we handle the bump! meme, i.e., how do we denote the predicted outcomes of deployments and whether they win! or not?
Which memes and states should be operative when bumping happens? We have two states, Away and Near, and also other states such as p.ShowHeads and such, and bump! may only be deployed when the game is in the Near state. Does that send us into some kind of compelled Bump state, which is really the same thing as a bunch of automatic alliance/immunomemetic responses, i.e., that a win! or a lose! is deployed (by the bumpee?).
 |
| fig. 10. The Bump state and bump! meme |
Actually, we could think of the possible outcomes in terms of hypotheses, and list the possible outcomes.
GivenX = "some collection of states, e.g., penny.ShowHeads.CoverHeads, etc."
Hypo = Near.GivenX
Hypo.bump! => Bump.penny.SecretHeads.nickel.SecretHeads.win! => Away
Hypo.bump! => Bump.penny.SecretHeads.nickel.SecretTails.lose! => Away
This is still rather inadequate. We want a set of hypotheses which contain all of the possible outcomes, and then what the results will be. For instance, the possible outcomes are that both secrets are matching, a match!, heads or tails, or they are non-matching, a split!, and one or the other of the players has heads. So match!(heads), match!(tails), split!(penny), or split!(nickel) are all of the possible outcomes, and a shared point value for each, as in figs. 8. above. There is also the idea as to which side is the bumper or the bumpee. So the way we divide it up is that the bumper gets a certain set of points, and the bumpee another, possibly identical set of points.
Near.penny.bump! => penny.Bump.penny.SecretTails.nickel.SecretHeads.split!(nickel) => Away
Near.penny.bump! => penny.Bump.penny.SecretHeads.nickel.SecretTails.match!(penny) => Away
Near.nickel.bump! => nickel.Bump.penny.SecretTails.nickel.SecretHeads.split!(nickel) => Away
Near.nickel.bump! => nickel.Bump.penny.SecretHeads.nickel.SecretTails.match!(penny) => Away
fig. 11. Complete Set of final bump deployment descriptors
One problem we run into here, which I may have rather clumsily addressed, is that of the system remembering which player initiated the bump!. This would normally be implemented with two different Bump states, which penny.Bump and nickel.Bump effectively accomplish, and perhaps in good keeping with the idea behind agent-state notation.
This way the state of the system records who was the bumper and whom the bumpee, and which of the four possible outcomes happened.
It remains to lay out all possible deployments in terms of sets of hypotheses for both players. It might be good to start from a generative notation and then enumerate all of them. That would then lead to a way of fleshing out a deployment decision system.
What is a Deployment Decision?
A deployment decision is where one agent decides to do something, and chooses amongst their possible choices of what to deploy. This game is turn-taking, so an agent is always free to choose what to deploy. The question is what to choose.
One idea I had is that we do it at random at first, and the agent populates which of their hypotheses are actually "reasonable" and then starts to play to win, so to speak.
This might be more reasonable and less arbitrary than a lot of other ways to handle deployment decisions, but it's still a problem.
Summary & Conclusions
Some more elaboration is required. I should lay out all of the possible moves in the game in the form of hypotheses. This should look like starting in the Near state and then all of the possible combinations of the other player's visible states and then prediction as to what will eventuate.
Things get deeper, however, since the other player may be gauging their settings off of what we are doing, in fact, they probably are. So we have to deal with all of the visible states on both sides. Presumably we don't have to figure in our own Secret state, since it's invisible. That might get into whether the other player can read our "poker face," which might actually be an interesting question.
In short, next step is to probably lay out all hypotheses, since I already have all of the states here, and then start to lay out some kind of programmatic design for implementation of a machine model.
Some game theory tables of how to pay out the points on bump! interactions is also called for.
____________________________________________
(1) This may not actually be a problem with these generative expressions, even complex ones. The generate all possible states, all possible combinations of the
(2) It might seem that penny not need to be mentioned twice, or that penny and nickel could be in some kind of notation like [ penny, nickel ] and save a lot of redundancy in the generative expression. This is probably true, and will become increasingly important for general descriptions of larger and larger memeplexes. The following generative expression may make sense:
[Away, Near].[ [penny, nickel].[ [ShowHeads, ShowTails ], [ CoverHeads, CoverTails] ] ]
(3) In our case we have some memes that change the "show" or the "message" without moving the "show" on the board, and often messing with the "message" doesn't change the "cover" (or anything). This could lead to the meme deployment looping back to the same state. One thing we hope to get away with using the "agent state" notation is that simple actions, like flipping my own "show" coin are independent, and shift the overall state of the system, but without changing anything else. So we can complete the new state of the system as just a "delta" based on a single action by either player. Each player can change the away/near state, their own "show" or "cover" (and "secret"), which makes for 32 transitions, or actually 64 accommodating for back and forth transitions if we elaborate all of them in detail, plus one state change, for each player, where they shuffle their message, but without changing the cover coin (which means that the secret may or may not have changed), and also bumping.
(4) Agent-state notation is where we show the state as specific to a given agent, such as penny.ShowHeads or nickel.CoverTail along with just the state notation.
(5) If a meme getting deployed, like flip!, and we can just invert the flag in the system state descriptor to its opposite, then our deployment descriptor does not have to say which state it started on or which state it ended up on, as such.
(6) When one player bumps another, the bumped player's secret is revealed, and if it's the same as the show of the bumping player, it's a cooperative bump, scored as such, otherwise a contested bump, typically favoring the bumpee.
(7) A compelled state is where one of some defined subset of memes must be deployed, resulting in leaving the compelled state for some other specified state. In the case of bumping, the game enters a state where the players compare their secret coins and their show coins, and a scoring process is performed, and then the game reverts to the away state.
(8) A "given" state may be a slippery thing, but our definition of hypotheses may deal with this well. You can, as we can in Faspeel, simply define a configuration of the game as a state. As we illustrate in the appendix, it's possible to elaborate all of the states of the game, which is sort of the point. In other situations, as I'm studying in essays on "memeplectic skin" and so on, the "state" of the system is less precise, and can (hopefully) be determined by looking at the history of deployments that have taken place previously, perhaps looking back a rather long time.
________________________________
Appendices
All Possible States (including secrets)
The variables of the system are whether it's Away or Near, what each player is "showing" and "covering" and then the "secret" which each other can’t see. That’s seven binary digits, or 127 possibilities.
| State Number | 1 | 2 | 4 | 8 | 16 | 32 | 64 |
|---|---|---|---|---|---|---|---|
| Position | Penny Player | Nickel Player | |||||
| "Show" | "Cover" | "Secret" | "Show" | "Cover" | "Secret" | ||
| 0 | Away (zero) |
tails | tails | tails | tails | tails | tails |
| 1 | heads | ||||||
| 2 | heads | tails | |||||
| 3 | heads | ||||||
| 4 | heads | tails | tails | ||||
| 5 | heads | ||||||
| 6 | heads | tails | |||||
| 7 | heads | ||||||
| 8 | heads | tails | tails | tails | |||
| 9 | heads | ||||||
| 10 | heads | tails | |||||
| 11 | heads | ||||||
| 12 | heads | tails | tails | ||||
| 13 | heads | ||||||
| 14 | heads | tails | |||||
| 15 | heads | ||||||
| 16 | tails | tails | tails | tails | tails | ||
| 17 | heads | ||||||
| 18 | heads | tails | |||||
| 19 | heads | ||||||
| 20 | heads | tails | tails | ||||
| 21 | heads | ||||||
| 22 | heads | tails | |||||
| 23 | heads | ||||||
| 24 | heads | tails | tails | tails | |||
| 25 | heads | ||||||
| 26 | heads | tails | |||||
| 27 | heads | ||||||
| 28 | heads | tails | tails | ||||
| 29 | heads | ||||||
| 30 | heads | tails | |||||
| 31 | heads | ||||||
| 32 | heads | tails | tails | tails | tails | tails | |
| 33 | tails | ||||||
| 34 | heads | tails | |||||
| 35 | heads | ||||||
| 36 | heads | tails | tails | ||||
| 37 | heads | ||||||
| 38 | heads | tails | |||||
| 39 | heads | ||||||
| 40 | heads | tails | tails | tails | |||
| 41 | heads | ||||||
| 41 | heads | tails | |||||
| 43 | heads | ||||||
| 44 | heads | tails | tails | ||||
| 45 | heads | ||||||
| 46 | heads | tails | |||||
| 47 | heads | ||||||
| 48 | tails | tails | tails | tails | tails | ||
| 49 | heads | ||||||
| 50 | heads | tails | |||||
| 51 | heads | ||||||
| 52 | heads | tails | tails | ||||
| 53 | heads | ||||||
| 54 | heads | tails | |||||
| 55 | heads | ||||||
| 56 | heads | tails | tails | tails | |||
| 57 | heads | ||||||
| 58 | heads | tails | |||||
| 59 | heads | ||||||
| 60 | heads | tails | tails | ||||
| 61 | heads | ||||||
| 62 | heads | tails | |||||
| 63 | heads | ||||||
| 64 | Near (one) |
tails | tails | tails | tails | tails | tails |
| 65 | heads | ||||||
| 66 | heads | tails | |||||
| 67 | heads | ||||||
| 68 | heads | tails | tails | ||||
| 69 | heads | ||||||
| 70 | heads | tails | |||||
| 71 | heads | ||||||
| 72 | heads | tails | tails | tails | |||
| 73 | heads | ||||||
| 74 | heads | tails | |||||
| 75 | heads | ||||||
| 76 | heads | tails | tails | ||||
| 77 | heads | ||||||
| 78 | heads | tails | |||||
| 79 | heads | ||||||
| 80 | tails | tails | tails | tails | tails | ||
| 81 | heads | ||||||
| 82 | heads | tails | |||||
| 83 | heads | ||||||
| 84 | heads | tails | tails | ||||
| 85 | heads | ||||||
| 86 | heads | tails | |||||
| 87 | heads | ||||||
| 88 | heads | tails | tails | tails | |||
| 89 | heads | ||||||
| 90 | heads | tails | |||||
| 91 | heads | ||||||
| 92 | heads | tails | tails | ||||
| 93 | heads | ||||||
| 94 | heads | tails | |||||
| 95 | heads | ||||||
| 96 | heads | tails | tails | tails | tails | tails | |
| 97 | tails | ||||||
| 98 | heads | tails | |||||
| 99 | heads | ||||||
| 100 | heads | tails | tails | ||||
| 101 | heads | ||||||
| 102 | heads | tails | |||||
| 103 | heads | ||||||
| 104 | heads | tails | tails | tails | |||
| 105 | heads | ||||||
| 106 | heads | tails | |||||
| 107 | heads | ||||||
| 108 | heads | tails | tails | ||||
| 109 | heads | ||||||
| 110 | heads | tails | |||||
| 111 | heads | ||||||
| 112 | tails | tails | tails | tails | tails | ||
| 113 | heads | ||||||
| 114 | heads | tails | |||||
| 115 | heads | ||||||
| 116 | heads | tails | tails | ||||
| 117 | heads | ||||||
| 118 | heads | tails | |||||
| 119 | heads | ||||||
| 120 | heads | tails | tails | tails | |||
| 121 | heads | ||||||
| 122 | heads | tails | |||||
| 123 | heads | ||||||
| 124 | heads | tails | tails | ||||
| 125 | heads | ||||||
| 126 | heads | tails | |||||
| 127 | heads | ||||||
No comments:
Post a Comment