Building an XNA Game Studio XBox360 Indie Game.

[page 0048] ~ X ~ Change:

Updates – Adobe Flash Player: Version 11.9.900.152 and Firefox 25.0.1 from 19.0.2

And the theme this month is CHANGE.

To find the change, “Two above else and second above last.”, really!

Reactionary AI.

This game will be a mile stone in that it is the start of my journey into Artificial Intelligents, for this game, actually, the next game or so.  So far, automation has been the mechanism that has moved the pieces about the chess board.  As the mouse pointer hovers over a chess piece, there is an opportunity to left click on that position and therefore the underlying chess piece icon.  This begins the process of automation that switches the game mode from view all chess piece statistics to view a singular chess piece statistic.  This change affords to the player a second point of view and the option to move the selected piece within this current modality.  This is done by simply pointing at a new position and right clicking on the chess board.  Automation takes care of the rest such as: moving the piece to a new tile, removing a piece of the opposing team and replacing that piece with the selected piece, ‘Evolving’ a Pawn to another previously taken piece once it reaches the other side of the chess board, or showing that that piece has put the King into check, just to name a few.  These processes are a result of automation and allows the game to be played more smoothly.  This alleviates the players who are taken away from the game mechanics and to raise their continuity within the game as they can become more concerned with the strategy used in the game of chess itself.  This also begins to lay the framework for reactionary artificial intelligents where rules of play can be followed by an algorithm of an opposing player, that being the games newly found AI.  As for now, it will come to no issue, seeing it is only but perceived, and as yet only a theory.  But this game does put to use enough Multiplicative Inverse, and some Logarithmic stuff.  And with that …

The Builds, the Saves.

BackUp_00.  Start this game with “Confection de Logic” as its base template.

BackUp_01.  The base template for this new game is essentially the full code page from the last game, “Confection de Logic”.  With that in mind the first order of the day will be code consolidation and optimization.  The reasoning behind this is that the scan speed of the chess pieces are slow.  Initially only one player would have their pieces scanned per turn which took roughly one second per piece.  Even for me this was an excruciatingly long time to wait so I could move another chess piece on the board.  Then I decided that there wasn’t enough valid information given in concern to both teams, being the white and black pieces, so I had both sides scanned each time the player relinquished their turn to the other player.  At one piece per second, because I was using the second() function to flag each piece to run its algorithm that would find the movement plot, any pieces that are protected by that piece and any piece that is in peril of being taken by that piece became a long time gone.  That algorithm needed to be run sixteen times per side which comes out to be thirty-two times per players turn.  After becoming very disheartened with all the waiting between turns I decided that using the millis() function, which gives an updated time in milliseconds since the start of the games namespace, would be a better choice.  This optimization took the time per turn from about 30 seconds to about 6 seconds per turn.

The need now is to bring down the run time of the full chess board scan down to below 6 seconds between player turns.  Essentially what happens is that there is a triple nested loop that calls the chess pieces from both players sides that are placed inside dual switch/case structures.  But inside these, are conditionals that require values of the increment portion from the nested for/loop structures.  Where this all happens is the first game state, that being the portion of the game that is instantiated when a player clicks on either button given the title Black or White which rests on either side of the <== Next Move ==> label on the top of the screen, and that state continues through the scan to the point were all the values of the full chess board scan shows all of the possible positions a piece can move, for all the pieces on the board, along with a qualifier that shows if a piece is protected or if it could be taken that turn.  That is the first game state.  The second game state is when a player selects a chess piece by left clicking on it.  At that point the chess board is cleared of all the eye candy clutter and reveals only the information of the selected piece which is highlighted.  What happens is that (green) hexes show where that piece may move because of its given type, that is: Rook horizontally and vertically; or Bishop diagonally remaining on its starting color, etc.  This movement plot emulates what is given in the first game state but in contrast it is the only movement plot shown on the board, i.e Ceteris Paribus.  The movement plot is terminated when it reaches a chess board boarder, an ally piece, or a foe piece.  At the point of meeting an ally, if certain conditions are met according to that type it may be considered protected, at which point a (cyan) hex surrounds the piece that had terminated the movement plot of the selected piece.  A coincident action also occurs if the termination piece is of the other team, or a foe piece.  At that point that piece is surrounded by a (red) hexagon showing that that piece may be taken.  After viewing the options of the selected piece the player may right click in a tile on the board moving the piece to that tile.  If the piece is occupied by an ally piece the selected piece is unable to move to that tile, if there is no piece on that tile the selected piece is simply moved to that tile, and if that tile is occupied by a piece of the other team, a foe piece, that piece is automatically taken from the board and the selected piece is moved to that tile.  That player then clicks on the title name of the opposing player and the first game state is repeated followed by the second game state until checkmate, stalemate or victory is assumed, thus ending that game of chess.  But as stated, the need is to speed up the down time in-between player turns, i.e. the full chess board piece scan.

Done.  The inter-turn scan is down to less than a second.  All 32 chess pieces are scanned through their respective algorithms with dramatically greater speed and still with equal accuracy.  Also the highlight around the piece as when it is selected to move has been removed while the scan progresses.

What was done here is that that portion of code needed to be turned almost inside out and two more void functions were built taking four arguments each.  Giving the for/loop increments as the arguments of those functions allowed the exchange of the previously hard coded variables in the switch/case structure more freedom to access the necessary routines.  First building the entire structure in long-hand, so to speak, made the code consolidation much easier, although now it is more complex.  But the scan speed has gone from 30 seconds to 6 seconds to 1 second, with each new implementation, for all 32 pieces.

BackUp_02.  The next thing to clean up is the problem of the shifting pieces.  When a piece is taken, it is moved off the board and out of play.  The way the full scan is set up, all of the pieces, those in play and those out of play, are registered.  But while doing so a check to see if a pawn could be traded in for another piece was also flagged, and during that scan a pawn might shift a space downward in the out of play dungeon area when it was checked against itself.  It didn’t do anything to affect the game but the effect was that something on the board would move that actually had no reason to.  It just looked sloppy when it happened and could also allow for misinterpretation when actually nothing was going on.  Done.

There seems to  be something quite wrong with the movement plot of the King in the first game state, the state where all of the moves are drawn to the screen.  The plot of the King is shown radiating out like the plot of the Queen, while the Kings movement is only to be one tile horizontally, vertically or diagonally.  Hmm.  The two void functions TestKing(…) and PlotKing() are used in the first game state and the second game state respectfully.  I’ve checked the last game build, “Confection de Logic”, and that didn’t occur there.  So this must have come about because of the newly introduced algorithms that have sped up the scan.  And yes, while rebuilding the void functions and their call structures, the King and Queen positions got switched, so like in Dr. Seuss’ Fox and Socks, the Moose was drinking Goose Juice and the Goose was drinking Moose Juice.  Just switched there positions and all is well and back to normal.  That was some long searching and work to find this simple fix.

BackUp_03 thru BackUp_15.  Yikes!  The game has a name, “X ~ Change”.  And with that, numeration and valuation will assimilate all of the pieces movement plots along with the terminus functions of those plots that show protection and or peril for each piece each turn of the game.  The first thing to do is to tally up the movement plots.  A movement plot is found by taking each piece on the board and from their capacity of directional movement that turn, count each tile that can be moved to, for each piece.  At the games start only the Pawns and the Knights are able to move.  The Pawn, on the first move, is able to move two tiles forward which, for 8 pieces becomes a total of 16 tiles.  Also on the first move, the 2 Knights are able to move to 2 tiles each, for a total of 4 tiles.  When added together the total comes out to be 20 tiles total that can be moved to from the starting positions of the chess pieces.  The next valuation also comes from the movement plot of the pieces which pertains to how many pieces are protected by other pieces of the same team.  Initially, because of the tight placement of all of the teams pieces on either side of the chess board, the total comes out to be 14 tiles.  This is because the 2 Rooks have no protection from any of the other allied pieces on the board in the games starting positions.  Finally, the last valuation is that of the opposing forces pieces to be in peril because of a pieces terminus in concern to their movement plot whereby it would be, or have the capacity to be, taken by a piece on the allied side.  At the start of the game there is no allied piece that has the capacity to take an opponents piece off the board, and so, the count begins with 0, no piece is in peril on either side of the chess board at the start of the game.

*  A “Movement Plot” can be counted more than once per tile, but per turn, it is counted once for each and every piece that can move to that tile.  “Protected” pieces are only counted once as are also pieces in “Peril” no matter how many pieces protect or are able to take an opposing piece.

Now that those numerations have values it is possible to begin the fun that comes from the theme of the month, CHANGE.  The first thing to do is to change the given numbers, that being: movement plot 20, protected 14 and peril 0.  I tried to come up with something that would show the correct rundown of what was going on under the hood using each instance of a turn in either of the teams side bars, and this is what I came up with.  These three numbers are all multiplied together.  The problem of showing what goes on in code and what is seen in the side bar became a little more tricky and I ended up kinda getting it drawn somewhat respectfully.  This is how it goes.  If at some point in time one or more of the numbers is Zero (0), and seeing that they are being multiplied and didn’t want the result to be zero, I used a set of if() statements that would first check to find a zero in any of those positions and if so use a different function found in the next switch/case derived from the value given to set the following switch/case.  The result was, although the read out on the side bar always says, multiplied by (X), the code behind it never multiplies by zero.  Instead of leaving on the screen a zero followed by a multiplies sign after it 0 x, the number zero is just kept from being written to the screen.  This seems to be the simplest way to express what is going on under the hood and still provide to the players just how the numbers are being attained.  Something else could be put in place of the empty space but the game speed, in switching back and forth between the two players, should make what is seen from the chess board in comparison to the side bar apparent with little to no problem.

Those are the first three lines in the side bar.  The next line, the fourth line, takes the total given from the first three lines and divides that number by the number of pieces from that team still on the chess board.  That total is seen in green.  But if you look at the result it is given as a decimal.  What happens behind the seen is the total on the screen is actually the reciprocal (1/x) of the result which is given on the fifth line.  These first five lines come directly from the pieces on the board, where these pieces can move, which pieces are safe because they are protected and can not be taken without retribution and which of the opponents pieces could possibly be taken from play on the chess board.  All of these numbers change with each move of a piece for every turn.

The values on the sixth line has two values.  Although there are two values, they both equate to the same value.  The first value is attained from the time it takes for that player to make a move and switch to the next player.  On the time line above the top of the chess board two more objects have been added.  They look like stick people without arms or legs, just a long body and a head where the body is the color of the team, white or black, and the head comes from the sub color, being purple or orange.  When a players turn begins, so does that timer on the time line.  To give an idea about the utility of the time line, it has six different functions that can be read from it.  The top most number in light gray gives the overall time since the start of the game.  The number directly below is another timer that shows the distance in time from either side of the red central tick mark to the current players end time.  This number changes color starting the game as gray in its centered position of time 00:00.  Then, for example when the white team is active it ticks towards the white teams side, which is to the right.  Conversely, when the black team is active the timer moves to the left.  There are 7 thirty second blocks for a total of 210 seconds or 3 minutes and 30 seconds of time on either side or a total of 7 minutes on the full time line.  The next two time keepers are positioned on the far ends of this time line.  These times keep track of the total time each player has used to come up with their winning game plan, move the pieces and click the button to select the other players team to become active.  Now, we get back to the little stick figures and the side bar values.  When a players turn commences the stick figure always begins at zero and counts off one per second.  At the end of the turn the stick figure is placed at the end point on the timeline using the length of time as the measure of the distance moved.  That time is shown as the first number in line 6.  That number is then equated to another number by again taking its reciprocal (1/x), so the two numbers are the same but second number is the reciprocal of the first.  The seventh line is where the number of pieces and the attributes of the players remaining pieces and the time taken to move one piece where it changes the strategy on the chess board are combined to form a numeric value.  This value is given to a log() function where that value always starts out large, decreasing at an increasing rate, and become smaller until it meets the zero crossing where it decreases at a decreasing rate. This is drawn out for every second the player takes to make a decision to move a piece on the board.  But, both teams start with equal pieces and placement of those pieces, and with each move the dynamics change, and provide a range of opportunities to …

Hmm.  As all of this has been going on, I’ve also been working on a chart, placed underneath the chess board.  This graph is shown in a rectangle and is updated to show the current players ability to grow, or lose, their GDP, Gross Domestic Product, or possibly GNP (I don’t really know, it’s a game “For Pete’s Sake!“) for each turn of the game.  This is shown as an oddball type of a Production–possibility frontier, kinda, sort a, or something like that in nature.  So anyway, what it does is for the given instance, of a turn, the values taken from the metrics of all the pieces on the chess board, which are boiled down to one value, and turns that into a function that can be drawn as a graph and read simply and easily during the players turn.  At the start of a turn, the graph takes the metrics and draws out the full curve in gray.  Then, as the players turn ticks by while figuring out the best move, the graph updates with the actual value that will be awarded once the player has moved and has relinquished the turn back to the other player.  Instead of looking at the numbers change, the graph provides the most consolidated venue to show the most pertinent information at a glance.  One other feature within the graph are two red lines, one horizontal and one vertical.  Both do the same thing, that is, showing where positive gains turn into negative losses.

BackUp_16 thru BackUp_19.  So what comes next is, from what I have noticed, while moving the pieces about the board is that the update calls to the In Protection and In Peril functions are not reflected accurately when a piece is moved, then when it is put back, to then have a different piece moved before the end of the turn.  Although in a proper game of chess, once a piece is moved and then the hand is taken from that piece it is said to have been set in stone and is not to be moved any further that turn.  But, to reflect a more proper adaptation that would allow such behavior, and for the sake of utilizing the remunerations that could be achieved by glancing at the graph at the bottom of the chess board, I am now looking into the affordance that will allow such behavior, i.e. moving a piece, looking at the bar graph to see if it is a viable option, then moving it back to try a different piece, and so on.  In doing so, I’ve gone through the code and have added many different flags and function calls to get an understanding of the logical flow of the game.  With every change, the previous code has the possibility to influence another aspect of the game that was not initially intended.  That’s the nature of computer programming.  But in having done this with many trial and error attempts, I think I am getting closer to a solution that will update the statistics of the pieces on the chess board with each piece move within that players turn.  Thus far, the only full update was given as the players switched turns.  This was good enough when a simple number was totaled and a given value was accumulated, but in hindsight it may have not been the most correct value that accurately reflected the positioning of those pieces for that turn, and therefore the correct rate of accrual for that turn.  With that in mind and because of the capacity to scan the chess pieces on the board more quickly than previously, the possibility to get the true metrics from the board for that turn to be expressed on the graph seems to be a succinct possibility.

Looking at what has been added and where it begins as a flag, SetCPP, which stands for the incorporation of the function ClearProtectedPerilous(); placed, where that flag is set to true to be able to call that function once.  That flag in void mouseReleased() opens the gate to that function any time that the mouseReleased function is called.  Also as a stipulation to the ClearProtectedPerilous function being called in mouseReleased an && (AND) qualifier is added to an if() statement to combine the validity of the mouse pointer to be in the area of the chess board itself along with the action of the mouse coming from a right mouse click.  These two conditions must be met to trigger the action of another full scan of the chess board pieces.  Per usual, this came about by first just having the function called no matter what, which happened to happen at any mouse click anywhere in the playing field from any of the mouse buttons used.  It was interesting, but very messy and, as for being functional to game play, became annoying very quickly, thus the “fix”.  Ham-fisted numbskullery is the mother of invention, but “Luck is the Residue of Design.”

To continue in game play, test runs begin to show that although this now assumes promise, it is still running into stumbling blocks that, from what I would guess will become a myriad of subsequent “fixes”.  Nothing can be done with one flail swoop that will complete this directive without test upon test.  And so, I must see where this will lead from the game play itself and from all the tweaks that are involved as the objective of finding the chess piece moves are illuminated substantively whereby they are seen upon the graph for each piece whenever dislocated by movement.

The capacity for “dislocated by movement” is an important factor here because a right click can happen anywhere on the chess board which will set off the scan.  Seemingly this does nothing detrimental to the game itself.  But it is nonessential here because the normalcy of game play within the actions needed to go from a piece relocation, which is further observed through its rewritten graphic statistical representation, where the newly formulated calculi expresses the recompense and remuneration of that move, stays the same and is therefore redundant and is again nonessential.  Finding how this all may be alleviated is what comes next.  First off I will need to know which is the selected piece, get the position of that piece and then store that position so it can be checked against when/if the right click will set off that scan.  If it is different from the original position, then the full piece scan should run once to repopulate the values used to draw the graph within the chart.  Easier said than done.

Denial of illusivety is what has become at task.  Capture of the position, validation of relocation and probably something else or more will be needed to get this to happen.  Let’s start with the capture part.  It’s a players turn, the timer is ticking, the graph is drawn and the values of “positive returns” are diminishing.  A player selects a piece to move, ding, ding, ding.  This is where the capture commences, but where in the code is it?  I need to make my game screen sloppy with extraneous coordinate pairs of indices and labels once again.  OK, I think I have something with CaptureI and CaptureJ that are set in the left mouse down set of reestablishment variables block.  But once the right click occurs the scan initiates and those variables are reassigned and become useless for the intended purpose.  I need to give them over to other dedicated variables byValue to keep them resident and be able to use them for validation later on.  But this needs to be done once in a different block of code so they are not rewritten as the games code flow progresses with its many passes per second.  Hmm.  Oh yeah, this is a frightful mess.  Yup, nothing.  Still working on it, but, the graph is now color coded where when the total GDP for that turn is above zero the chart lines are green and when below zero the lines are red.  Also in the side bars the values that are used to derive these colors have the same color scheme.  Well, that’s just beautiful.  I give up, but not surrender.  It’s time to run back a few Back Ups and start where things were working better than they are right now.  The biggest problem is that although I can get it to scan the board after a piece move I can’t get the player switch buttons at the top of the game to do what they were intended to do, that is switch to the other players team pieces.  It’s a mono on nobody.  It’s an only one person can play one team and can’t do anything else game.  Wee, oh what fun.  Now which Back Up was the one that is the last best Back Up to start with.  Back in a moment.  But first to save this mess.

BackUp_20 thru BackUp_??  It looks like BackUp_16 is where the Research and Development started all these test progressions.  So now to open another sketch and load some of the other back ups out of archive to dig out some of that R&D.  Not all is lost, some of that worked, I think, kinda sort a, a little bit.  Things are movin’ slow right now, like, real slow.  I had better play this version through a couple of times to make sure this one isn’t just hanging in there by a thread.  The graph color upgrade and other value coloring is getting dropped into place and saved in BackUp_20, more to follow.

Hmm, good morning.  And I have lost my stream of thought and think I’ll need to start again from BackUp_20, maybe.  Yep, I’m still learning how to build it forward and to still have a system that will step back to a point of consolidated stability while being able to collect the few trinkets that would have otherwise been lost as R&D while building and testing obscures the consistency of the program as it moves further into complexity.

Well, it’s kinda fun figuring out how it doesn’t work.  But, what I’ve got here, again, is a game that has two major modes.  The first mode is where all of the possibilities of movement and their consequences are shown.  The second mode shows the repercussions that occur for a single piece as that one piece is shown in isolation.  The situation that is of concern is when, within a players turn, a piece is moved to another tile to see how it affects the statistics given in the side bar of that player.  Until the player switches the turn over to the opposition, any piece can be moved multiple times about the chess board but only one piece can be moved to a valid position per that turn.  The only exceptions are when a Pawn is traded for another piece or when the King and the Rook use the “Castle” maneuver.  So when one piece moves, the “Evolution” or the “Castle” moves are performed which is considered one valid move and the turn may pass to the next player.  Then when the player is satisfied with the strategy found within the given time frame, the player selects the turn advance button at the top of the playing field.  This runs through the function that relinquishes the turn to the next player where it resets some values and clears the way for the next player.  OK, simple enough, sure.

Now to define just what problems become apparent as this process is set into play.  Where to start.  The game begins with the splash screen where the only options are to select either the Black or the White team buttons to acknowledge who goes first.  From there, that screen is exited and the chess board is shown with the pieces in their starting positions.  The pieces are scanned to reveal their contribution to the battle plan.  Those contributions are tallied and totaled in the side bar and finally these statistics are shown in a bar graph below the chess board.  As the first player sees this screen being drawn out for the first turn of the game, a set of timers begin to count out various aspects that afford to the player delineations of time used.  These timers mark out, total game time, total cumulative turn time for either player, a count up count down per turn time and accompanying bar on the time line, a single turn time which is reset at each start of a players turn and is seen in the side bar where, this time is also drawn from that single turn time as it is combined with the chess board statistics to be revealed in a chart given as a dynamic bar graph.

There seems to be a multitude of complexity within this basic set of actions.  What I need to do is to separate when calls to the screen are instantiated per logic cycle in comparison to the logic that updates the actions of the player.  A call to draw the screen when the logic that performs these other functions have not yet been completed at best just cause the screen to flicker and at worst revaluates the variables which give false readings or change the logic flow to the point of inoperability.  All of these problematic instances have happened within the building of this game as it has continued to grow in intricacy.  As if you couldn’t tell.

Enough of this administrative banter, but it has actually let me see where I’m not.  To get where I’m going how do I slice and dice this code.  More R&D, more scrolling up and down, more side notes and searches, more cut and paste, more comment/uncomment, more logical in/exclusions, more building and documentation, lest I forget.  So where am I?

That last excursion in speeding up the piece scan, from 30 seconds to 1 second, involved separating the logic from the draw code.  And with that, I think I’ll be needing to do the same again and continue to separate the last parts of value update code from the remaining perpetually scanned draw code.  With each cycle, from what I can gather, the code page is read from top to bottom.  The game starts by initializing the global variables, then jumps into the setup() function to instantiate the variables with their initial values.  After that the code is read again and again from within the draw() function.  I would guess that it has come to the point in building this game that I do that again because I’m sure that I have no idea of what is actually going on in there as of late.  With that, the first order of business is to start at the top and cut out all of the commented out trial and error code, then save that as BackUp_21, done.  This will be my next waypoint if I should ever need to retreat from my continuing expansion, which I probably will.

The code page is clean of extraneous detritus.  Next on the list is to give a visual “hand check” to get a grasp of what is called from where.  And in doing so, of course, I have added a couple of more visual cues.  While play testing this game, and looking at the bar graph, the time given to have a positive collection of GDP was given by looking at the left side of a vertical red line that marked where the zero crossing occurred.  The left side bars on the graph are shown in green while those to the right of the zero line are shown in red.  But where is zero placed on this graph?  It moves from turn to turn and also from any update from a piece movement during that turn.  How long do I have before there are negative returns?  Is there a value I could see on the chart that would let me know just when that would happen?  Of course there is.  And so there is now a numeric value set in the top middle of the chart that counts down to zero.  When that number reaches zero the value disappears, because it isn’t needed any longer.  But if a piece is moved so that its positioning moves that zero crossing reappears and continues to count down to zero again.  In that way, not necessarily will the best or most strategic move be made but, it will give a better idea as to when a positive return could be made.  Also there have been added two markers placed on the top and bottom of the outline of the chart.  It was the best place to put them because of the scarcity of the limited space left to be populated in the game screen that could possibly make some sense from the statistics drawn from the game values.  These markers start on the left side of the graph and as the final totals from either teams side bars accrue, these markers make there way across the charts outlines on the top and bottom from the right as a small reminder of who is ahead in respects to that GDP part of the game.  Nothing much, a little bit of indiscernible clutter, if you don’t really know what it is for or what it means.

So anyway, back to the logic flow.  Or, I could save BackUp_22, because I have added a scenario where when one of those little stick figures gets pushed back to the end of the timeline, the opposing team achieves Victory.  This comes about from the up/down count timer that uses the white and black bars at the top of the game screen.  There are three minutes and thirty seconds on either side of the zero mark on the top timeline.  So, for instance, when it is the Black teams turn, that team uses time to get the strategy together, move the piece and then switch to the other player.  While all that is happening the bar lengthens, to the Black teams detriment, and moves closer to the left side of the timeline end point, being three minutes and thirty seconds.  If that bar moves all the way to the end, time is up and the opponent is victorious, the game timer stops and the game is over, but also visa versa.  Yes, I’m still looking for a way to update the statistics with each piece move, sure, I’m gettin’ there, eventually.

Maybe getting the chess board to not draw any of the movement plots, InPeril nor InProtection icons to the screen would be another way to find out how to get the value update logic separated from the draw calls, just so I can get another idea of how this might be done.  To figure this out I’ll start another mini project within this game to see when pieces are called to move.  As it stands, a chess piece is left clicked to be selected as the piece to move.  When that one piece is selected only that piece has its move statistics shown on the chess board.  When the mouse is right clicked on a tile that has an ally piece nothing happens.  If that tile has an enemy piece on it that piece is taken from the board and the ally piece replaces that piece on the tile.  When no piece is present that piece is simply moved to that tile.  Simple enough, on the outside.  On the inside there are some boolean flags that need to be switched so that the other statistics are not drawn to the screen.  At this point I will need to start some R&D searches so I can have a start tile and an end tile with their positions accessible for that one piece.  The problem so far is that the function used to get that information to the draw method is volatile, meaning that it changes frequently and rapidly, it is not stable.  If I capture a value from that function, which is the starting position of that selected piece and then right click to move it, the function that initially gave that value is the same function that revalues that value to have it move to its new position.  Hmm.

Save BackUp_24, this save changed the middle count timer under the total game timer.  With this change that timer now reflects the bars start position and length as it counts down to zero as it gets closer to either end of the timeline.  3 : 30 is the middle of the timer and 0 : 0 is at either end of the timeline making it easier to understand just what the white and black bars are representing.  When that timer reaches zero, (0 : 0), the other team achieves Victory, but not necessarily CheckMate nor StaleMate.  Another change is to move the Accrual Markers to the middle of the bar graph chart, top and bottom, from being on the far left.  The starting position allows for a positive and negative movement of these markers seeing that both + and – values are used when coming up with a total accrual of the given statistics.

Save BackUp_25, this save moves the turn counters, those that are incremented each time a player finishes a turn and gives it over to the other player, from the inside of the top of the far ends of the timeline, to the outside middle of the ‘current piece’/’taken piece’ rectangle in the upper left and right corners of the game screen.  The next update/improvement is found in the chart portion of the bar graph in the center bottom just below the chess board.  The scenario goes like this, a players turn starts and a bar graph from the current statistics are drawn in the chart.  The width of the chart is 200 pixels, so there is only enough room for two hundred ticks of the timer, seeing that the count ticks off once per second.  Three minutes and thirty seconds comes out to be 210 seconds, but that is from the middle of the top timeline, which would leave 10 seconds that would move out of the charts rectangle as an over-run.  Also the total time from one side to the other would be 420 seconds, and that would run past the game screen completely.  So this save adds the logic for what is needed to keep the graph inside the chart.  As the timer ticks away, at some point there is the possibility of the count to reach the middle of the graph. At that point the graph begins to move to the left along with the zero crossing so that the full range of the graph can be viewed.  With that upgrade it can continue to be referenced quickly as the player looks for the best move for that turn.  Now back to finding how to update turn statistics with each move within the turn.

Or I could do a little more work with the bar graph.  What has come to mind is, as a players time is used and as the timeline bar above the chess board moves closer to the current players last seconds of move time, the bar graph on the bottom of the chess board draws out the values across the entire chart.  This looks nice but it doesn’t reveal to the player what is actually coming their way, that is, the other players victory because too much time has been used for strategy and movement.  As it stands, the bar graph moves to the left to keep a good portion of the graph visible, but there are only so many seconds that need to be shown from the bar graph that are pertinent to the actual amount of time left to be played in the game.  At some point in time there are only so many seconds left, and so, only so many increments need to be shown by drawing that many bars on the graph.  If the whole graph is filled, the cut off point, that is, when the game ends, is not given to the player or represented in actual bars remaining in the bottom chart, therefore the coming end is not clear.  This is what the next puzzle will be that I’ll be working on next.  To cut the length of the bar graph short will take some interesting mechanics within the for/loop that draws the bar graph to the screen.

Save BackUp_26, and this is what I’m getting this little game to do.  But I have need to expedite this process, not in the actual building of the game but in the testing of this game.  Each time I make a change to see just what will happen with each little tweak, I need to run the game to the point on the timeline and the corresponding bar graph to see just what has happened.  As noted, it’s a seven minute timeline from end to end, and so three minutes and thirty seconds on either side of the center.  Now guess what happens when I need to figure out what happens at the ends of the timeline or at the finish of the bar graph, that’s right, tick, tick, tick … and tick, tick, tick … and tick, tick, tick until it gets to where I need to see how things turn out from the change in the game.  Well, what I have added to this save are two things that speed up this process, and they are… uhm, well, …  The first thing is to add a pause to the timer of the game to stop the game in its tracks.  All I need to do now is click the middle mouse button and the game will pause until I click the center mouse button again.  I can see just how the variables change with each increment of a second, in the game screen, at least, but not within the code page it self, C’est La Vie, C’est La Guerre : such is life, such is war.  The second adaptation that has become enormously helpful is adding the capacity to speed up the time from a one second increment to where it can run as fast as the CPU can run the games logic cycle.  I can now zip through three minutes and thirty seconds of one second increments in about five seconds, yippy zippy.  This should speed up the testing for each change I make to the code as I try to get the bar graph to match up with the timeline with all of their interconnecting markers.  All I need to do now is add some visual cues to the game screen so I will know what mode I have the game running in.  OK, now for the Easter Eggs, to get the timer to speed up, left click in the upper left or right text boxes, the ones that are either white or black that say Pawn takes King or something like that.  A double << or >> will appear on the top of the screen in green while in zippy mode.  Also the pause button comes from the center mouse click and will stop the game timer.  An icon seen as ||, will also appear on the top of the screen, denoting that the game is paused.  Clicking again will set the game back into normal play mode.  Now back to figuring everything else out.

Save BackUp_27 and BackUp_28, was a lot of hackin’ through the forest, but the graph is working rather well.  That little bit of extra work figuring out how to pause and speed up the game, hmm, and also how to have the side bar statistics be removed from the game screen so I could get a whole slew of other pertinent variable values and their labels out, and, and, and…  But at any rate the bar graph at the bottom of the game screen is done.  It works, and it is synchronized with the timeline at the top of the game screen.  Right now it is saved with all the messy trial and error code that was a bunch of, how about this, but what happens when this player runs it to the other side of zero and then the positive counter is now negative but minus a negative is not actually subtracted but added as a larger negative value, but not, and so on and so forth.  I guess I’ll need to tidy up the code and straighten out all of the curly braces, that’s the fun part, anyway.  But back to it and more testing, perpetual incremental testing.

Save BackUp_29 thru BackUp_33, YES, I have finally got that pesky in-turn update to work for each move of a piece.  With each piece, of the current player, as it is moved about the chess board, the side bar statistics are changed to reflect the updated values.  That was a ton of everything that it takes to get it done.  I am way happy now, I only thought I could get it to do the things that it does so well, but now it does.  Yippy!  Also the bar graph draws out those statistics for each move.  And the best part is that it takes about a second of down time to get it to show the updated data from the complete chess board scan.  Ah that my Laurels are Hardy, “Well, here’s another nice mess you’ve gotten me into!“, but thankfully out of.  And like so much of joy, not that it is so short lived, but to take it onward into the last of the tweaks to come.  And with that …

Save BackUp_34 thru BackUp_38, hmm, if the fast forward mode is selected and there is a right click of the mouse while in fast forward, the bar graph is zeroed out as it is drawn to the chart below the chess board.  Again, this does nothing to change the game but it does look sloppy.  So what I’ll be looking to accomplish next is to match up the thirty second intervals in the top timeline with the tick marks that appear at every thirtieth bar in the bar graph.  And I think that will be just about it for this game build, maybe.   Or, instead of that I’ll add a small help file on the intro screen.  Keyboard keys 1, 2, 3 and 4 are set to be show/hide switches that are for the Statistics Side Bars, Full Board Movement Plots, In Protection and In Peril visual cues.  These can now be toggled on and off individually, starting the game in the off position.  Also, when a Pawn reaches the opposing teams back line and can Evolve into a new chess piece the Statistics Side Bars are hidden to allow access to the redeemable pieces that have previously been taken.

Just added some fade in stuff so the screen is more conducive to game flow and the timing used during board updates as the players move their pieces and switch off between turns. The keyboard keys 0 thru 9 all have new functionality switching different parts of the game screen icons on and off.  I have further enhanced the fade in and out so that with the in-turn statistics updates the player shouldn’t be able to click on something that isn’t ready to be clicked on and will mark that it is ready for play by fully fading back into view.

Almost done, but naught to be as yet, and so, one more time to this proverbial well.  To top this game off I will try to get a starting position and a finishing position placed on the chess board for the selected piece that moves that turn, plus an icon representation of that piece.  Much more easily said than done.  As mentioned, the volatility of the variable values is a major sticking point.  With every click of the mouse, a scan ensues that looks to find that piece and set some flags.  Then from that to draw a different aspect of the game board for when that piece moves to a new position while also taking into account other ancillary actions that may occur because of that move.  The first thing I’ll need are two variables, a coordinate pair (X, Y), that are set once and are not overwritten after the piece is left clicked.  Once registered that set of variables will be the positional representation of that piece until it is moved or deselected for another piece.  If that piece remains selected the game does not let the player switch turns, so that variable should be safe to use for this purpose.

Save BackUp_39 thru BackUp_46, and that is that.  A little bit more of code clean up and a couple of other things.  Another one done.

The Game is Complete.

Play the Game Here.

X ~ Change.

Until then, G’day.

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