Building an XNA Game Studio XBox360 Indie Game.

[page 0044] ~ The Movement Plot:

The Grace Period: 96 hours.

I think it’s ninety-six hours of grace period, that’s what my clock says, including sleep.  Enough said.

Back to PlotPawn().

To keep the pieces from moving outside of the movement plot design, I’ll need an array that will hold the positions that that piece can move to.  At times, a piece may not be able to move because it is blocked by an allied piece.  It may also be blocked by the opposition, or possibly the chess board boarders themselves.  In any case, when a piece is selected an array of viable tile positions needs to be filled so that when moved it may be checked against it.  This could make the draw calls in concern to the highlighted tiles more easily accessible because they would be decoupled from the draw function.  The furthest a piece can move from its current position is seven spaces because the board is an eight by eight matrix of tiles and the piece itself occupies one.  So the array would need to be at least eight units in length, 0 thru 7.  But it looks like its time for some more underpinning by building an 8×8 array that will hold who is where on the board.  The question now is how do I do this using only numeric values.  What would make the most sense and what type of parser do I want to build so the code can decode it in a usable manner.  0 has been set as black and 1 has been set as the white side.  So the start of the numeric sequence will either be a zero or a one.  The second number in the sequence would be the chess piece type, Pawn, Rook and so forth.  The pawn will be a zero with another zero thru seven following after because there are eight pawns to a side.  So a pawn, in the 64 tile array would be, for the black side, 000 for the first pawn, 001 for the second up to 007 for the last pawn.  A Rook – 1, Knight – 2, Bishop – 3, Queen – 4 and the King – 5 will be the rest of the second numerals in the sequence.  The last numeral, the third numeral, because there are two rooks, knights and bishops will be either a zero or a one, while the queen and king will both be a zero.  With little to no forethought of a pawn making it to the last row and being exchanged for another piece, I’ll just leave it to fate and hope for the best when that time arises.  So where does this get me, and why.

Move a Piece Already.

Yeah, these pieces don’t move at all.  They are stuck.  There is no mechanism that will change their position.  And this gets me back to the array of viable options.  Another run through.  I click on a pawn and it is highlighted in cyan.    MouseIsDownLeft is a replacement for MouseIsDown because I’ll be using a right click of the mouse to move a piece through a different boolean, MouseIsDownRight.  At least that’s the idea.  And again, but how.  Ah that wacky wonderful world of mathematics, pointy-clicky happy land of “This doesn’t work, but how about this”, probably research and development for lack of a better name.  So the pawn moves, not quite correctly but it does stay on the board, cool.  It’s starting to work a little better, more consistent, but still a little loose in concern to the placement on the board.  Another problem here is that the piece doesn’t un-highlight after the right click move to the new position, although the placement in the new position does look good.  One more boolean flag, but what is its name, probably InitiateMove, sure.  And where to put it, directly under UpdateMove = false; and also in if(MouseIsDownLeft == true), just because.  R&D is the sledgehammer, ductape, tweezers, glue and thread place with sparkles, Crêpe paper and crayons.  Weirdness, I need some sleep.

That helps.

Wakey wakey eggs and bakey, that and some coffee, a vitamin and a couple of aspirin and I’m back on top of my game, literally.  I must have been working in my sleep last night, I mean, before I fell into bed.  I have a pawn that, when left clicked is highlighted and when the mouse is moved to another tile and then right clicked the piece is moved to that tile and unhilghlighted.  If the mouse is still on the highlighted piece when the right mouse button is clicked the piece is simply unhighlighted.  Pretty good for not remembering all too well that I had gotten all that done last night.  This is where things start to get tricky so I’ll make another backup copy and start moving this along and testing the permutations to come.   The first thing I should deal with is that when the pawn is left clicked there is a possibility that it will jump the the last tile that was the position of the last right click.  That was a simple fix, all I needed to do was insure that, in the left mouse down function, BoardTileX and Y are also set to the same value of the currently selected chess piece.

More Pawn Plotting.

I have the white pawns movement plot set, all eight pawns can move through the left/right mouse click procedure.  The black pawns are next, done.  All the pawns on the board can move, but that switch/case structure is really long now.  I think its time for save #04.  And to be truthful all the pawns can move anywhere on the board, they don’t follow any rules at all, if it’s a tile on the board they can end up there in one move.  Moving a piece on top of another piece is also possible, but because of the order of the draw function the white piece is always underneath any of the other pieces.  Also it is not removed from the playing field when covered.  So, the first thing to do will be to insure that the pawns have a predefined movement plot.  It’s willy-nilly right now and this is chess, not finger painting.  I’ll need to come up with some, “Stay in between the lines” kind of rules for the pawn pieces.  I had already built the graphics part of the movement plot of a pawn just to see what it would look like on the board.  It is two tiles in front of the piece circumscribed by a square outline in green, because on the pawns first move it is able to move two tiles forward.  And then two diagonal outlines in red off to the sides of the one tile in front, because those are the two attack positions and the tiles that the pawn would land on if that situation were to occur.  It is only a lesson in graphics and has no way, at the present, to influence a restricted movement plot on the pawn.  Also after the first move of the pawn, the same function portrays two tile spaces in front of the piece, it has no variation or way of changing that format.  The red diagonal tile outlines are also always present, even when there is not an opposing piece in that tile.  Is seems like working through all these conundrums with the pawns will lay the foundation for all the other chess pieces.

It’s Only a Model.

What does it take to keep a pawn inside of its predefined movement plot.  It’s time for another dry run to run through what would be seen when a player wants to move the pawn on the chess board.  Take the mouse and hover the pointer above the pawn that is to be moved.  Left click the mouse button, the piece is highlighted in cyan.  This is the signal that the piece has been selected and now has focus.

But First My Focus Is . . .

I’m going to get the rest of the pieces set to move in that long switch/case structure and make it very long.  This way I’ll be able to have a free, yes free, upgrade to the game.  Well, its a long stretch to say game at this point but it will have more functionality than what is there right now.  It’s more than likely my attempt to salvage what PR that the game is giving off right now in its given state.  Time for another save #5 and a web game update, done.

Back to the Focus.

All the pieces move now, the next plan of action will be to get the outlines around their prospective moves. Or, I could start to formulate a way to have captured pieces removed from the board.  In either case there are two puzzles to solve.  In the first, the outlines show where the piece can move because the piece has that type of movement.  In the second the piece can also move to that position, but in doing so will result in the removal of the opponents piece.  I seem to have come to the heart of the matter, into the thick of it.  There are a lot of parts that need to be coordinated and orchestrated.  They will need to move one after another and that is what I’ll need to solve for this puzzle to become a game.

The Grace Period: 72 hours.

I have come upon two types of run throughs.  The first is from the point of view of the player while the second is from the point of view of the developer.  Looking at this chess game from the inside and the outside has given me an opportunity to realize complexities that, in the past, I had taken for granted.  Getting back to the former and the latter, which I had written about previously, the former game rules are observed by the players themselves while the latter requires that the rules are placed within the game code.  With the former, the chess board acts as a guide that aids the players in concern to a decoupled set of rules found through the chess pieces with the guidance of others one would play, or possibly some documentation.  The rules are what make up the game but are not given from the board or the pieces.  In the former, this computer game, as it stands right now the same is true.  With the former or the latter any piece can move anywhere on the board but because of this there comes into account the validity of those moves.  Restricting the pieces movement, and also taking into account the vast and varied possibilities of where a piece could move has lead me to the conclusion that the game, in concern to the constraint of a pieces movement, is complete.  I will leave it up to the players of the game to place the pieces where they deem fit.  Doing so will free me to solve the two last puzzles of this game.  The espionage that will expose the players move and the removal of a piece if it is taken.

Taking an Opponents Piece.

To take an opponents piece, one chess piece needs to land on a tile where another opposing players piece is currently situated.  To do this three things need to be known, where is the initial piece and where will it land with the third bit of information being, is there an opponents piece that occupies that tile so it can be removed from play upon the initial pieces arrival.  From this I’ll need to look at the variables in my code and prepare them for such an event.  But what are these variables?  Are they compatible, or more precisely are they comparable?  Are they in an array that is accessible or do they need to be reformulated?  These questions should be of help as I delve back into my code page to find, from either point of view, if a piece is to be removed when landed on.  As the opposing player the idea is to keep the piece “in safety” by not having it in a tile were the rules of engagement would allow it to be taken.  The next best option would be to have that piece in peril under the guard of another of the same house, i.e team, the white or black set of pieces.  Falling out of safety is what this part of the game build will cover.

Naming the Piece, Building the House.

So far I’ve been dealing with the abstract ideas and concepts that embody the game of chess.  I have the checkered tiled chess board, the two houses being the white and black sets of pieces and the icons of what those pieces have been known to represent.  Those who have some knowledge about the game of chess would corroborate that, by outward appearances, that this computer game resembles a standard setup of a game to be played as chess.  What I haven’t done as yet is to ‘name’ the house or the pieces therein.  I have no intrinsic relation that binds the icons on the board to the code in the program.  What I mostly see now is either what I’ve come up with that is my best representation of the game when it is run on the screen or a bunch of variables inside tiered structures in the project page of the API.  I do have some text clues of what a variables current values are which are printed to the screen and some comments in the code page.  But beyond that its all leaps of faith as I careen back and forth between these two states of this game build.  Ah, but I have incorrectly and blindly forgotten this blog itself, dummy me, as a third pillar.  So back in the code page I’ll need to change some of the variable name that were hastily constructed.  A new variable that contains “House” will represent either the white or black team set.  Also a string array of names for the pieces has also been added.  These will be used to direct the very large and ever growing switch/case and also be placed in that structure to allow the House and the Piece selected when left clicked on and thereby become ready to move.  I’ll also need to have those words placed on the screen so that another visual cue will aid the players as they move through the game.  Done, and now for another save, #6.

Back to Capturing an Opposing Piece.

Ok, that was too convoluted to explain, but I think it works.  What was needed were some variables, FoeFound, FoeX, FoeY, Set Captured and maybe a couple of more.  Then inside the right mouse button click routine there needed to be a for/loop to go through the array of either the black house of pieces or the white, which ever were the opposition of the selected piece.  Then once a piece had the same position of the piece that had just been moved I had a write to the screen that shows that both have the same position through a (X, Y) value with visual validation.  So far it seems to work although nothing further is done.  The next part is to do a little bit more testing and then probably get another array that will set that piece out of action and off to the sidelines.  But first a save, #7, done.  And it does provide the correct signal.  Now to take this a step further I’ll see if I can get it to tell me which piece of the opposing house has been captured by name.  Hmm, as it would seem I have built forward and hadn’t taken into account running the same algorithm backward.  To find the name I’ll need to build another array that will keep the names inside a structure that duplicates the structure of the position array.  Using a class to represent a consolidated unit of all these parts could well have been the way to go, but in this web java world it seems that that is somewhat out of my reach at this time.  So for convenient sake I’ll just use brute force to get this part done.  Or just go the simple route and build an if/else with a switch/case in the MouseIsDownRight if statement, simple enough.  And yet another save, #8, and some more testing.  Good as gold.  I’ll just tidy up the game screen and see if I can get the pieces off the board and over to the side.  Wow, that’s a lot of curly braceses.  When a piece is taken it moves off to the side.  It looks good enough to be the next free upgrade and is enough to make it into what some may call a game, if you know the rules of chess.  I have a few more hours left in my grace period so I’ll leave off here and continue on, after another save #9.

To be continued, . . . again.

Until then, G’day.

September 2, 2013 Posted by | 2013 [0019] to [00??], The Process | Leave a comment