Game of War - a multiplayer non-automata

[alejandro]

Hi,
I'm developing a 2 player game where each player has their own colour of live cells. The rules for squares involving one colour are the same as Life, but there is to be some sort of enemy rule, say, too many enemy neighbours and the square dies). At the moment (in this very early development version), each player has a building area and a limited number of squares to use. They must build configurations which send spaceships and such to annihilate the enemy while building structures which are resistant to attack.

Here is a very basic version with the "game" in the top grid and a simulation grid at the bottom http://alejandroerickson.com/joomla/ima ... f_life.swf

I'm wondering

1. Has this or something similar been done? Linky?

2. To make the game more accessible it needs to have a library of configurations. I've yet to find a downloadable library on the web (aside from things that can be downloaded individually), but I'm sure there must be one!

I look forward to your input on this!

[Extrementhusiast]

Well, there has been a sort of life called Immigration, in which there are two colors of live cells, and the players try to kill off the opposing cells. It isn't as complicated as your idea, though.

A simplified version of your idea may be possible to construct with a "Rule Table", but I myself have no idea as to how they work.

[alejandro]

These are the rules I'm currently using:

1. Any live cell with fewer than two live friendly neighbours dies, as if by loneliness.
2. Any live cell with more than three live friendly neighbours dies, as if by overcrowding.
3. Any live cell with two or three friendly neighbours lives, unchanged, to the next generation.
(unless it dies at number 4)

4. Any live cell with more enemy than friendly neighbours, dies.

5. Any dead cell with exactly three neighbours of one colour and no others comes to life.

If you've coded your own life game this should be pretty straightforward.

Each block checks it's own rules, there are global variables:
nCurrentColour is the current colour
nNextColour is the next colour that will be applied after all the blocks are checked.

OffsetPoints is for looking at the neighbours of this square.

Code: Select all

public function checkRules():void {

			var enemyCount:Number = 0;
			var enemyColour:Number = -2;
			var friendCount:Number = 0;
			//count neighbours of same colour
			var OffsetPointsColour:Number;
			for(var i:uint =0;i<aOffsetPoints.length;i++){//friendly neighbour
				OffsetPointsColour = canvas.getPixel(aOffsetPoints[i].x, aOffsetPoints[i].y);
				if( OffsetPointsColour == nCurrentColour){
					friendCount++;
				}else if( OffsetPointsColour != WHITE){//enemy neighbour
					//this checks if the colour is the same for all enemies
					//enemy colour gets colour of first enemy neighbour
					//then check if all other enemy neighbours are same
					if(enemyColour == -2) enemyColour = OffsetPointsColour;
					if(enemyColour != OffsetPointsColour) enemyColour = -1;					
					enemyCount++;
				}
			}
			
			
			if((friendCount == 2) && (enemyCount <= friendCount) && (nCurrentColour != WHITE)){				
				//survival
				nNextColour = nCurrentColour;									
			} else if((friendCount == 3) && (enemyCount <= friendCount) && (nCurrentColour != WHITE)){				
				//survival
				nNextColour = nCurrentColour;
			}else if((enemyCount == 3) && (enemyColour != -1) && (nCurrentColour == WHITE) ){
				//5. birth
				nNextColour = enemyColour;
			} else {
				//lonely/overcrowded/attacked
				nNextColour = WHITE;
			}
		}

But these rules are not final. I was thinking that a player might get some kind of power up, so that they don't have to strictly outnumber the enemy to eliminate them. It's something to be experimented with i suppose.

[alex79]

The reason you feel the need for a powerup is because still-lifes are small and are able to be constructed densely,but few spaceships dense enough to overpower them exist because the rulestring for life contains only 2s and 3s. Even the few that exist (weighted spaceships in dense phase) cannot attack well because the nose is fragile (if the back is damaged the nose still moves until damage touches the nose) and the only way to crash into a still life with spaceships is by aiming its nose, so the attack rule needs editing to conform with the average pattern.