模倣子 Into to 4x4 Chimple Game

 Memetic Index — Manga Index

Introduction

I'm trying to create a regularized and simplified version of chess (2) that I can analyze and ultimately computerize to do things like (I hope) simulate societies in conflict (1).

I initially thought of a 3x3 version of the game, with only four pieces, at the corner, and this makes the set of deployment descriptors smaller and easier to deal with. At any rate, I've already laid out the four-by-four version of the game, so I'll leave this here, and make a new 

The Game 

The game consists of two sides, black and white, facing one another from opposite sides of the board. The board is four-by-four, and each side has four equal pieces (4). Pieces move like rooks in chess, i.e., side to side and forward, but they capture like pawns or bishops, i.e., diagonally. The game ends when all of one side's pieces are captured, or one side is no longer able to move (3).

fig. 1.1. Starting Board for Chimple

fig. 1.2. Movement of Pieces

fig. 1.3. Capture Directions

Game State 

The state of the entire game may be expressed as a 16-digit base-3 number. For instance, the starting state of the game may be named 2222,0000,0000,1111 (6). Each time a move is made (meme deployed) the board state changes. I hope that there will be a very clear and direction connection between the notation for eligible moves I describe below and which shall be the resultant next state, and that this will lend itself readily to a computer program implementation.

0	0	0	0
0	0	0	0
0	0	0	0
1	1	1	1

fig 2.1. starting position matrix P for one side

0	0	0	1
0	0	1	0
0	1	0	0
1	0	0	0

fig 2.2. rotation matrix R

The "white" position matrix, W, is rotated to Wr and multiplied by two for purposes of combining both sides to product the overall system state matrix (7), or looking at one side from the perspective of the other, for captures, may be achevied by the following operation:

Wr = R x W x R          fig. 2.2.1. "white from black's perspective"

Br = R x B x R            fig. 2.2.2 "black from white's perspective"

S = B + ( Wr x 2 )          fig. 2.2.3. "state matrix"

The assumption is that overlapping pieces is not allowed (8), since any such transition would be invalid. Any meme deployment (move) would involve a move to an empty space, or a capture.

For every space on the board, we can envisage "filter matrices" (10) which tease out whether there are capture opportunities from that space (based on the rotation of the other side's position matrix) or obstacles to movement (based on one's own position matrix, possibly with the piece in question removed).

For example, on the opening move for the black side, the far left corner piece (see fig. 1) can move forward or to the right, but is blocked on the right (9) by another piece. If there is an enemy piece up and diagonally to the right, that is a capture opportunity. So we have two filter matrices.

Collision Filter					Capture Filter
0	0	0	0		0	0	0	0
0	0	0	0		0	0	0	0
1	0	0	0		0	1	0	0
0	1	0	0		0	0	0	0

fig. 2.3. Filter matrices for lower left corner

So we perform an AND operation with the capture filter and the rotated enemy position matrix, and if non-zero, we have capture opportunities, and an AND between the own position matrix and the collision matrix to determine which positions, if any, are free to move to. In practice, as we'll see below, we shall want a set of capture and collision matrices, each with only one non-zero element, as this will dovetail more cleanly into the deployment determination system I will describe below.

Game Dynamics

My idea is to represent all movements in the game as deployment descriptors with the addition of the idea of "agent state" (5) which I think will make the game easy to write as a computer program. I shall probably elaborate all of the deployment descriptors for the game in a separate document, much as I did for my Triangular Baseball thought experiment. For now, I shall endeavor to give an overview and the seed of an idea how all of the possibilities might be elaborated, and how this might lead directly to a computer implementation.

First off, how many deployment descriptors are we looking at? Roughly speaking, pieces at any of the four corners may move to two spaces or attack one, three total, the eight side places may attack two and move to three, for five, while the four center spaces may attack four and move to four. So the possible "things one can do" is on the order of:

 4 x ( 2 + 1 ) + 8 x ( 2 + 3 ) + 4 x ( 4 x 2 ) = 12 + 40 + 32 = 84

What I hope to demonstrate is that with my slightly enhanced deployment descriptor notation it should be possible to describe which deployments (moves) are eligible for each piece on a team for any given state of the board. Moreover I hope each of these deployment descriptors shall lead directly and easily to the update of the board state.

Conclusions & Summary

I'm going to work up a 3x3 version of the game which will have fewer states, but will have similar, but smaller collision and capture filter matrices.

I need to come up with a naming system for the spaces in this 4x4 game, perhaps just the numbers of the spaces, 1-16. I will try come back to elaborate all of the deployment descriptors for the 4x4 game, either in this essay, or linked to a separate page.

So all I've done here is lay out how the game works, and made a bit of a foray into how it might be computerized.

One thing that remains is the system, or ideomemplex, that governs how the system, or the agents in it, make their decisions about which memes to deploy. This goes back to my essay on skins and random organic growth of memetic matrices.

___________________________________________

(1) For instance, two sets of pieces, white and black, would be governed by each by different memeplexes. That is, each would have independent memetic inventories and deployment matrix systems.

(2) simplified chess = "chimple". I have an earlier attempt at the game which I'm going to simplify further, e.g., such that pieces do not change into "queens" partway through, so that the entire board may be represented as a 16-digit base-3 number, i.e., that is the envelope for the number of states. In fact, each side's state may be represented as a 16-digit binary number, and they may be totally symmetric with one side flipped and superposed over the other to produce a "collision matrix."

(3) When all of one side's pieces are pinned in by the other side and are unable to make any move, that's one way for the game to end.

(4) In principle the size of the board and the number of pieces may be expanded indefinitely, and even other shapes used, or pieces initially deployed in more complex arrangements, once the dynamics of this simple version of the game is worked out. There could even be more than two players. The present goal is to work out the dynamics of the game, and the hope is that it may be expanded in complexity later.

(5) Normally deployment descriptors are of the format of State.agent.meme! => NewState, and the variation of "immunomemetic notation" which looks like State.agent1.meme1!agent2.meme2!...agent-n.meme-n! => NewState. To this I add "agent state" which looks like agent1.State1.agent2.State2.meme! => NewState. Hopefully the usefulness of this notation in expression which states are "eligible" for deployment will become clear.

(6) The lower left corner of the board is three to the zero, and the upper left is three to the fifteenth. Black pieces have value 1, white 2. If we divide the board into two sides, the white and black may each be represented as 16-digit binary numbers, and there two rotated and superposed as needed. These matrices are all sparse, of course, since there are at least eight blank spaces on the board at all time.

(7) The system state number is derived from the system matrix by simply adding up all of the nodes in the system matrix (rotated W, or Wr, times two, plus B, the black position matrix). Each state has its own distinct system matrix with is homologous to a system state number.

(8) It might be interesting to elaborate all of the "disallowed" configurations. Any state number disallows piece overlaps, naturally, since each place must be a white, black, or blank. However, some corruption of the position matrices of each side could produce this, although it would not be properly reflected in the system state. Things like more than four pieces of each color, or configurations that could not be reached by a valid sequence of moves would have state numbers, but would not actually be possible states (without a modification of the rules, that is).

(9) The left corner piece is also not allowed to move backwards or to the left, which may be a larger issue. But as we'll see in the deployment dynamics section, these moves will not even be considered as eligible moves, any sort of matrix filtering notwithstanding.

(10) one problem in our model is going to be how to identify each agent as represented in the position matrix with some kind of individual identity of said agent. Initially we don't care -- the game will work minimally without this -- but in order for it to function as a memetic fabric there must be a one-to-one identification. Since each agent "decides" what action to take, they could maintain a copy of their own state, represented in the position matrix. The only update that would come "backwards" from the position matrix is if a piece is captured, and they then discover that they've been erased when their turn comes up again--something like that.