WARNING: What follows is a game only a Geek could love.

Today’s design is a twist on the venerable game of chess, via quantum mechanics (See…I warned you).

If you’re the kind of savvy reader that hangs out at the Chrome Cow, you doubtless are familiar with a certain theoretical feline belonging to one Erwin Schrödinger. This cat has the misfortune to be confined in a box with a deadly device that has a 50-50 chance of triggering with an hour. At the end of the hour, goes the thought experiment, the cat, sealed from observation inside the box, is neither dead or alive, but is in superposition, a combination of these possible states. The cat does not live or die until the box is opened by an observer, who through the act of observation collapses the possible dead/alive states of the cat into one or the other state.

So what’s that got to do with Chess? What, indeed!

Enter Superpositional Chess (Super Chess? EigenChess? Quantum Chess? Schrödinger’s Pawn?).

Like Schrödinger’s experiment with the Cat, mine too is wholly theoretical, so to follow along you will need the following imaginary supplies:

• Two Chess Boards
• Two Sets of Chess Pieces

Set up both boards in the traditional manner. The players will take turns as per usual, but each player will move one piece of their color on each board, each turn.

If each player moved the same piece on each board to the same spot, the game would be identical to standard chess. It’s when the two moves diverge that things get interesting.

In this example, the white Knight has two potential legal moves.

If, on the two separate chess boards, he moves to each of these legal spots:
 

 The superpositional board is the additive result of Boards A & B.  In the above example, the knight is said to be superpositional, it exists only potentially in both spots.

So before things get too confusing, here are the rules:

Basic Definitions

• Each board is set up like a traditional chess game
• Both boards have the same color pieces facing the same player
• If two of the same type of pieces of the same color occupy the same space on both boards, that piece Exists in that space.
• Only one piece can Exist in one space at any given time.
• At the beginning of the game, before anyone has moved,
• All pieces Exist
• If two of the same pieces of the same color occupy different spaces on both boards, those pieces are Superpositional.
• See example above
• Only two Superpositional pieces of any color and any type can occupy the same space:

• Existing pieces take precedence over Superpositional pieces
• No move can be made that creates a Superpositional piece on a space occupied by an Existing piece

Player’s Turn

• Movement Round
• Player may move a piece of his color on each board, OR
• Collapse a Superpositional piece
• Player chooses two Superpositional pieces of the same type and color
• Player moves one of those pieces  to match the position of the matching type of piece on the other board
• That piece now Exists (this example follows on from the Knight example above):

Resolution Phase

Two Superpositional pieces of different colors may occupy the same space, but what happens when one of those pieces is Collapsed, and now Exists in that space?

Above we see four Superpositional pieces.

Black chooses to Collapse their Pawn. At then end of Black’s turn, we have a Black Pawn that Exists in the same space as a Superpositional White Knight. This is not allowed, so White now has a Resolution Phase to correct the problem:

In the above example, White chooses to Collapse the Knight to the space not occupied by the Black Pawn. If White had chosen to Collapse the Knight to the same space as the Black Pawn, the White Knight would have been forfeit.

• The first piece to Exist in a given square captures any piece that comes to occupy that space in the resulting Resolution Phase.

It is very likely as the game progresses that one move will trigger a cascade of alternating Resolution Phases.

• White’s move requires a Black Resolution Phase
• Black’s Resolution Phase requires a White Resolution Phase
• And so on…

 

---

 

Threat and Check

For Existing pieces, the endgame rules of Check and Checkmate are the same as regular chess. It is when we bring Superpositional pieces into the mix that we need new rules.

Threat

• When a Superpositional piece is placed such that it can execute a capture move on a King (Existing or Superpositional) the next turn, the player that moved it there must announce "Threat"
• Threat is one step less serious than Check
• The player would have to spend their next turn Collapsing the piece for it to escalate into a Check:

• When an Existing piece is placed such that it can execute a capture move on a Superpositional King the next turn, the player that moved it there must announce "Threat"
• Threat is one step less serious than Check
• The Threatened player can Collapse their King to safety:

What about the case where two Superpositional pieces are threatening two Superpositional kings?

This is still classified as a Threat.

• A Check or Checkmate is only possible when an Existing King is in peril from an Existing enemy piece.

Threat, Check and Checkmate must be announced both in in the Movement Phase and the Resolution Phase

---

Optional Rules

Entanglement

• For all pieces except the king and queen
• Number the pieces
• Pawns 1-8
• Knights 1-2
• etc.
• When placing the pieces in their initial position
• Lowest number go on the left
• So the leftmost pawn is #1, the rightmost #8
• Leftmost Knight is #1, rightmost is #2
• You may only collapse pieces
• Of the same Color
• Type, AND
• Number

Final Thoughts

This game (I kind of like the name EigenChess) might be a great way to introduce young Chess players to the world of quantum mechanics, and build up some intuition for some of the non-intuitive aspects of that branch of scientific inquiry.

If someone really wanted to play this on an ongoing basis, the easiest approach is probably a software solution to manage the boards and states of the pieces.

However, you could also set up two physical boards, place a top-down video camera over each board and then superimpose the two video streams, which would give you a result like the Superpositional Board used in the above illustrations.

Either way, drop me a line and let me know how it works…};^)

-game over-

Thanks for reading another action-packed installment of Design a Day. For background on the Design A Day challenge, take a peek here and here.

Ok. I owe you a Lazarus and the Time Machine Part 2, but I can’t resist the chance to post a quite nearly timely World Cup inspired design.

I’ve consulted with experts in the field, and the consensus is that the World Cup involves Soccer.

In my mind this is quite nearly the same thing as Foosball, except that in Soccer the games are much longer and harder schedule.

I admit it. I’m not really an organized sports guy, and today’s design is less inspired by the World Cup and more by Rockstar’s latest table tennis opus.

The idea is simple:

Foosball + Wii = Awesome.

The perspective is top down, and on the bottom of the screen you can see the single player’s control rods.

Moving the Wii controller left and right in front of the player selects different rods. Moving the wand forward and backwards slides the rod in and out. Twisting the wand (which should be readable with the accelerometer, I think) twists the corresponding handle.

There’s not much more to it. It is single player versus AI. There is a multiplayer mode for two or four people over the network. Two players play head to head, four players play two-on-two.

There is of course room for much ancillary bling: skinnable, unlockable men, unlockable tables, special physics modes, special team count and placement modes, ladder play and of course, as the title of this design suggests, some excellent branding opportunities.

It’s a simple game, where execution and feel is everything.

-game over-

Thanks for reading another action-packed installment of Design a Day. For background on the Design A Day challenge, take a peek here and here.

The Design-A-Tron Lite. Rewritten, a mere 20k, not counting the text for the database. I think it’s up to about 890+ billion potential combinations.

The new version of the full implementation is in the works. It has…more.

You can groove to it on the eRadiRace page, and remember the late nineties. It has a certain Wipeout PSX thing going for it.

Aside: Wipeout XL. Best video-game soundtrack ever. I have a the original game disk lying around here somewhere, and in a move that would be utterly foreign to the DRM-crazy Sony of today, the songs from the game are encoded on the disk as regular old CD audio.

I was going to link to Amazon, and point to a preview clip, but I realized the song I like best from the game isn’t on the official soundtrack album. Perhaps someone out there can help me identify the artist and song name of this clip:

[audio:http://www.chromecow.com/wp-content/audio/WipeoutXL_Artist_Unknown.mp3]

Some day real soon now I’m going to write up what I have learned in these Flash projects, and how I see it applying to prototyping in a production environment.

* Beats certified phat by and independent panel of beatologists.

It was therefore gratifying to see some of the movers and shakers in the industry make announcements this week that amount to first steps toward the Chrome Cow’s mad, glorious vision for the future.

I direct you first to the lads in Redmond, as Microsoft introduces their Live Anywhere strategy. To quote the Gamasutra article,

One of the biggest announcements at E3 was that Microsoft is developing Live Anywhere, a network infrastructure that will allow players to communicate and interact seamlessly with the Xbox 360, Windows Vista PCs, and Windows Mobile and Java-based mobile phones.

Combine this with John Carmack’s latest announcement about Massively Multiplayer Cellphone Games (via CNN),

"We’re probably going to have a sequel to ‘Orcs and Elves’ but I’m really into the idea of a massively multiplayer cell phone title," he said. "I have absolutely no interest in going and competing with Blizzard in the high end of that market, but a cell phone version might be interesting." John Carmack

Now we are getting very close to the kind of persistent, cross platform and multi-game shared universe that I have proposed in various guises in Towards a Better World, Cross Dressing: AR Across Platforms and Open.World.

One Universe, many games, many platforms. You heard it here first.

The Unspoken Superpowers of the Average Player Character

Though Lazarus and the Time Machine sounds like a pairing straight from the Design-a-Tron, the next few Design-A-Days will be focused on two main metaphors: Time travel and resurrection.

And metaphors they are…most of the time. I’m not an academic, so you’ll have to live with my conjecture and the occasional link to Wikipedia to back up the loose history that comes next.

The Continue

I think it is a safe bet to assume that the original notion of the Continue was a simple revenue calculation. A player is more likely to pay another quarter to continue playing a game they have already invested time in rather than starting over from scratch. My quick search of the interweb hints at this, though I have found no direct confirmation.

Further, he conjectured, certain limitations inherent to the original arcade machine architecture would have limited the options for allowing the player to continue a game. Due primarily to the small amounts of RAM, if any, available (he pulled out of his assumptions) you would have been limited to either restarting the player from the point of death (no RAM, simply continuing in-situ), or restarting the player at the beginning of a level (saving only the level-start score, all other state restored from ROM).

But how do we continue a game from the point the player died? They’re dead, after all. Just drop their avatar back in the game, and let them go. Who’s going to question?

What about starting them back at the beginning of the level? Won’t that transition be jarring? Will they recognize that they have moved backwards in the game? It’s not that different than the jump-cut discontinuities of French New Wave Cinema; players will adapt.

And it was from these completely plausible and humble beginings that the two most powerful and successful metaphors of video game history were born: Resurrection and Time Travel.

In the intervening years, the hardware changed, moved into the home on consoles and on home computers. The abilities changed, the requirements and player expectations evolved, but the save and the continue still exert a powerful influence today. This column is going to focus primarily on the way things are generally done. The next two or three will look into directions to expand and play with the underlying mechanics.

The World Clock

I’m going to go out on a limb and say that most saved games use the following model (yes, there are notable exceptions, and I plan to note them, give a fella a chance):

The avatar dies. The World Clock is rewound to a previous state, and the player resumes from this earlier time, but with an inexplicable (usually, in game terms) knowledge of future events.

There are many ways to embroider this basic mechanic. Marathon’s Pattern Buffer states this explicitly, most of the time it is just an unspoken superpower possessed by nanotechnologically enhanced super-agents down to lowly 1930’s cabbies alike. Sometimes the granularity is user controlled (Quick Save), other times doled out sparingly by the designer (Resident Evil PS’s Typewrite Ribbons).

The Danse Macabre

Platform games have evolved their own baroque traditions for bringing the player back into the game. The checkpoint is essentially a World Clock rollback. The checkpoint is usually where a player goes when he has run out of lives, triggering a continue. But before such drastic measures, the player must first lose a number of lives*. When a life is lost, the player respawns (resurrects) in place. In-game powerup or score triggers can increase either number of lives, or number of continues.

There are many games who break these conventions (to their great credit), like Prince of Persia: Sands of Time which allows the player not simple reset the world clock, but scrub the timeline (in a limited way). I will talk more about these exceptions next time, and explore some alternatives. Until then.

-game over-

* Another common model is lives lost return you to a checkpoint, a continue bounces you to the start of the level.

Thanks for reading another action-packed installment of Design a Day. For background on the Design A Day challenge, take a peek here and here.

Well, I finally got eRadiRace in a presentable form. You can read the release notes .

Launch eRadiRace!

Here is a recap of how to play:

eRadiRace is a two player game.

Player 1 Controls: Left/Right/Up/Down Arrows

Player 2 Controls: A/W/S/D Keys

Player’s crafts leave colored walls on the playing field. The player who survives the longest without hitting a wall or the edge of the screen wins that round.

Players can control the speed of their craft.

To speed up, hold down the key in the direction of travel.

To slow down, hold down the keep opposite the direction of travel.

Example: If you are moving up, hold down the Up key / W Key to speed up. To slow down, hold down the Down key/ S Key.

Warning: Going fast makes you larger!

-game over-

Thanks for reading another action-packed installment of Design a Day. For background on the Design A Day challenge, take a peek here and here.

Also, eRadiRace is close enough to done that you can pretty safely look for it in all of its two-player splendor sometime this evening.

Woot, as the kids say.

There is a new (and still incomplete) version of eRadiRace posted.

Launch the new broken thing!

I’ve come to the conclusion that talking about learning Flash is about as interesting as watching The Paint Drying Channel. So, I’ll spare you further exposure to that curse. What I will do is post these things up as they are finished in the game design section, along with the source code and pertinent lessons learned. The code may be ugly, but it’s well commented.

The preview: Flash 8’s Draw API is your friend.

Lameness Alert:

Pre-production is in full swing on the next round of games at Helixe, which means I’m Johnny-on-the-Spot for the next couple of months.

So yes, expect further slippage on the Design-A-Day. You deserve better, and I’ll understand if you want to start seeing other designers. It’s not you…it’s me.

I’ll endeavor to keep you amused and entertained, if not enlightened, in the meantime.

Code to the new version after the jump.

//  Base Contruction for Multiplayer Line Blocking Game

/* This makes heavy use of the Flash 8 Drawing API
   there is a good overview of it here:
    http://www.adobe.com/devnet/flash/articles/image_api_print.html
*/

//import classes we will be using
import flash.display.BitmapData;
import mx.managers.DepthManager
    //http://livedocs.macromedia.com/flash/mx2004/main_7_2/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Flash_MX_2004&file=00002014.html
import flash.geom.Rectangle
//_______________________________________________________________________
   
   
// Initialize Stage and Load BG image from Libray   
var stageW:Number = 485;
var stageH:Number = 600;

var bg_mc:MovieClip = this.createEmptyMovieClip ("mc", 1);
var myBmp:BitmapData = new BitmapData (stageW, stageH, true, 0×00000000);

myBmp.draw (BitmapData.loadBitmap ("bg_pic"));
bg_mc.attachBitmap (myBmp, 0, "never", false);
    //trace(bg_mc.getDepth());

// Sets the Player Avatar Depth above that of the Background
Player_1_mc.setDepthTo(DepthManager.kTopmost);
    //trace(Player_1_mc.getDepth());

//_______________________________________________________________________

// Initialize Sounds

badGoalSound = new Sound();
badGoalSound.attachSound("badGoal");

//________________________________________________________________________
//Initialize all variables
gameOver = 0;
topSpeed = 7;
lowSpeed = 2;

// for Player 1
p1_X_Dir = 0;
p1_Y_Dir = -1;
p1_Speed = 3;
p1_X = 243;
p1_Y =590;
p1_lose = 0;
p1_baseScale=1;

//________________________________________________________________________

// Main Game Loop

this.onEnterFrame = function() {
   
    if (gameOver == 0) {
        p1_Old_X = p1_X;
        p1_Old_Y = p1_Y;
        //__________________________________________________________
        // Player_1 Keyboard Input
       
        if (Key.isDown(Key.RIGHT)) {
           
            if(p1_X_Dir != -1){
               
                p1_X_Dir = 1;
                p1_Y_Dir = 0;
               
                if(p1_Speed < topSpeed){
                    p1_Speed += .5;
                }
            }
            else {
                if(p1_Speed > lowSpeed){
                    p1_Speed -= .5;
                }
            }
        }
   
        if (Key.isDown(Key.LEFT)) {
            if(p1_X_Dir != 1){
                p1_X_Dir = -1;
                p1_Y_Dir = 0;
                if(p1_Speed < topSpeed){
                    p1_Speed += .5;
                }
            }
            else {
                if(p1_Speed > lowSpeed){
                    p1_Speed -= .5;
                }
            }
        }
       
        if (Key.isDown(Key.UP)) {
            if(p1_Y_Dir != 1) {
                p1_X_Dir = 0;
                p1_Y_Dir = -1;
                if(p1_Speed < topSpeed){
                    p1_Speed += .5
                }
            }
            else {
                if(p1_Speed > lowSpeed){
                    p1_Speed -= .5
                }
            }
        }   
       
        if (Key.isDown(Key.DOWN)) {
            if(p1_Y_Dir != -1) {
                p1_X_Dir = 0;
                p1_Y_Dir = 1;
                if(p1_Speed < topSpeed){
                    p1_Speed += .5;
                }
            }
            else {
                if(p1_Speed > lowSpeed){
                    p1_Speed -= .5;
                }
            }
        }
        //__________________________________________________________
        // Update Player_1 Location
        p1_X += (p1_Speed * p1_X_Dir);
        p1_Y += (p1_Speed * p1_Y_Dir);
       
       
       
        //__________________________________________________________   
        // Collision Detection
        pixelColor = myBmp.getPixel(p1_X, p1_Y);
        //trace("0x"+pixelColor.toString(16)); //outputs : 0×00000000
        //trace(pixelColor);
        if (pixelColor == 65535) {
            p1_lose = 1;
            gameOver = 1;
            gotoAndPlay(3);
        }
       
                //___Add front array of detectors based on direction
       
       
       
        //__________________________________________________________
        // Place and Scale Player 1
        _root.Player_1_mc._x = p1_X;
        _root.Player_1_mc._y = p1_Y;   
       
        _root.Player_1_mc._xscale = p1_baseScale + (p1_Speed * 23);
        _root.Player_1_mc._yscale = p1_baseScale + (p1_Speed * 23);
       
       
       
        //__________________________________________________________
        // Draw the Line for Player 1
        if (p1_Y_Dir == -1) {
            p1Width = 7;
            p1Height = p1_Old_Y – p1_Y + 1;
            topleft_X = p1_X – 3;
            topleft_Y = p1_Y;
            myRect = new Rectangle(topleft_X,topleft_Y,p1Width,p1Height);
                //The first two parameters are the x/y coordinates of the top left-hand corner of the rectangle.
                //The last two parameters specify the dimensions of the rectangle (width and height).
            myBmp.fillRect(myRect,0xFF00FFFF);
        }
       
            if (p1_Y_Dir == 1) {
            p1Width = 7;
            p1Height = p1_Y – p1_Old_Y + 1;
            topleft_X = p1_X – 3;
            topleft_Y = p1_Old_Y;
            myRect = new Rectangle(topleft_X,topleft_Y,p1Width,p1Height);
                //The first two parameters are the x/y coordinates of the top left-hand corner of the rectangle.
                //The last two parameters specify the dimensions of the rectangle (width and height).
            myBmp.fillRect(myRect,0xFF00FFFF);
        }
       
        if (p1_X_Dir == -1) {
            p1Height = 7;
            p1Width = p1_Old_X – p1_X + 1;
            topleft_X = p1_X;
            topleft_Y = p1_Y – 3;
            myRect = new Rectangle(topleft_X,topleft_Y,p1Width,p1Height);
            myBmp.fillRect(myRect,0xFF00FFFF);   
        }
       
        if (p1_X_Dir == 1) {
            p1Height = 7;
            p1Width = p1_X – p1_Old_X + 1;
            topleft_X = p1_Old_X;
            topleft_Y = p1_Y – 3;
            myRect = new Rectangle(topleft_X,topleft_Y,p1Width,p1Height);
            myBmp.fillRect(myRect,0xFF00FFFF)   
        }
       
    //________________________________________________________________________
       
       
    } // Closes "if(gameOver == 0)"
} // Closes "OnEnterFrame"
stop();

Curse you, Flash!

Why solve simple problems, when you can be stumped by hard ones? I appear to have out-clevered myself for the moment. I’m not finding any good way to test for collsions against the arbitrary line movie_clip I’m drawing as a trail.

I’ll paste the code after the jump, if anyone wants to take a peek. Perhaps a good night’s sleep will bring council.

Nothing shocking:

The green ball is Player_1_mc, the green line is Line_mc

Player_1_mc.gotoAndStop(10);

JUNK = 0;

badGoalSound = new Sound();
badGoalSound.attachSound("badGoal");

createEmptyMovieClip("Line_mc",1);
Line_mc.lineStyle(10,0×00FF00,100);

p1_X_Dir = 0;
p1_Y_Dir = -1;
p1_Speed = 3;
p1_X = 243;
p1_Y =590;

topSpeed = 10;
lowSpeed = 1;

baseScale=30;

Line_mc.moveTo(p1_X, p1_Y);

this.onEnterFrame = function() {

// Player_1 Keyboard Input

if (Key.isDown(Key.RIGHT)) {

if(p1_X_Dir != -1){

p1_X_Dir = 1;
p1_Y_Dir = 0;

if(p1_Speed < topSpeed){
p1_Speed += .5;
}
}
else {
if(p1_Speed > lowSpeed){
p1_Speed -= .5;
}
}
}

if (Key.isDown(Key.LEFT)) {
if(p1_X_Dir != 1){
p1_X_Dir = -1;
p1_Y_Dir = 0;
if(p1_Speed < topSpeed){
p1_Speed += .5;
}
}
else {
if(p1_Speed > lowSpeed){
p1_Speed -= .5;
}
}
}

if (Key.isDown(Key.UP)) {
if(p1_Y_Dir != 1) {
p1_X_Dir = 0;
p1_Y_Dir = -1;
if(p1_Speed < topSpeed){
p1_Speed += .5
}
}
else {
if(p1_Speed > lowSpeed){
p1_Speed -= .5
}
}
}

if (Key.isDown(Key.DOWN)) {
if(p1_Y_Dir != -1) {
p1_X_Dir = 0;
p1_Y_Dir = 1;
if(p1_Speed < topSpeed){
p1_Speed += .5;
}
}
else {
if(p1_Speed > lowSpeed){
p1_Speed -= .5;
}
}
}

// Update Player_1 Location
p1_X = p1_X + (p1_Speed * p1_X_Dir);
p1_Y = p1_Y + (p1_Speed * p1_Y_Dir);

// Place Player 1

temp_X = p1_X + (25 * p1_X_Dir);
temp_Y = p1_Y + (25 * p1_Y_Dir);

_root.Player_1_mc._x = temp_X;
_root.Player_1_mc._y = temp_Y;

_root.Player_1_mc._xscale = baseScale+(p1_Speed*11);
_root.Player_1_mc._yscale = baseScale+(p1_Speed*11);

JUNK += 1;
// Player 1 Collision Detection

// detect if edges of the player is colliding with the Maze Walls
if (_root.Player_1_mc.hitTest(getBounds(_root.Line_mc).xMax, _y, true)) {
trace("Hit xMax "+JUNK);
_root.badGoalSound.start(0,1);
}
if (_root.Player_1_mc.hitTest(getBounds(_root.Line_mc).xMin, _y, true)) {
trace("Hit xMin "+JUNK);
_root.badGoalSound.start(0,1);
}
if (_root.Player_1_mc.hitTest(_x, getBounds(_root.Line_mc).yMax, true)) {
trace("Hit yMax "+JUNK);
_root.badGoalSound.start(0,1);
}
if (_root.Player_1_mc.hitTest(_x, getBounds(_root.Line_mc).yMin, true)) {
trace("Hit yMin "+JUNK);
_root.badGoalSound.start(0,1);
}

// Draw the Line
Line_mc.lineTo(p1_X, p1_Y);

}