Doing My Part

August 22, 2012

I really haven’t done any development for Resistor in over a month, so I decided to go ahead and put it into the Peer Review process on the Microsoft Creator’s Club site.  I see it as my way of doing my part in adding to the fine collection of interactive video entertainment titles in the XBox Indie Games marketplace.

With over 400 entries into the Dream Build Play competition, I don’t think I have a chance at being one of the finalists.  If the competition was based purely on uniqueness I think my game would fare better.  However as in real life, looks do matter and my game is about as plain as it gets.

Overall, I would be thrilled if my game could make $100 on the marketplace, which would equal the original investment that I made for the Creator’s Club membership.  Unfortunately, I’ve heard that most XBLIGs don’t make anything, so my goal is probably a bit of a stretch.

Below are the changes I made to the game after putting it through playtest a few weeks ago.

Tutorial System

Tutorial tips were added to teach new players the rules of the games.  These tips should not display as long as the player is doing well in the game.  The tutorial tip system keeps track of which tutorial tips the player has seen, and it doesn’t display a tip that the player has already seen.  However, once the player quits the game the tip flags are reset.  A tip is displayed if the player falls to the B rank in any of the three categories.  Also, if the player doesn’t use the appropriate resistor and gets a Game Over, then a tip will display when the level is started again stating that resistors should be used to reduce the flow value.

More Graphical Improvements

Made the spinning light sprite display while the LEDs are filling, using the scale parameter.

The rank letters at the end of the stage now zoom into position.

Changed the A, B, and C rank colors to use lighter shades of blue, green, and red.  The status icons in the lower right portion of the screen now change with their respective rank values.  I also modified the real time rank value of the luminosity category, so that it calculates the rank based upon the maximum possible luminosity of activated LEDs (instead of all LEDs).  This way, the player starts out with an S rank in luminosity and the rank is only lowered if they connect a wire with a lower flow needed by the LED.

Audio Changes

Used Audacity to make the ding sound when an LED is activated lower based on the difference between the maximum flow value and the current flow value.  The rank grades at the end of the stages use these modified sounds as well.

Week 7 Video Update

May 22, 2012

Short Update video

Level Editing Done

Finished the last ten stages of the game, which use the 10 battery with a maximum resistor of 9.  Went back and fixed the level design issues that I found during playtesting yesterday.  I still need to set the rank values for the last 30 stages.

The level 10 battery caused an issue, because it used block ID “20” in the array.  However, I had defined everything between 20 and 29 as LEDs.  I modified the battery range to use IDs 10 through 20, but the battery showed up as 0, because I was using modulo (%) 10 to get the battery value.  I went ahead and just wrote a special case for this to fix it for now.

Trailer Video Remake

I wasn’t happy with the audio in the trailer video, so I recaptured and re-edited the audio tonight.  However, I kept most of the video clips and edits made last night.  I don’t want to spoil my cheesy indie game song, so I’m keeping it under wraps until the contest is over.

Simple Change Casues Larger Problem

May 13, 2012

Week 6 update video.

 Pause Problem

Added a pause screen to the game, which I thought was going to be a simple change.  I created a new class that extended the Screen class, implemented the draw and confirm button methods, so that it just returns back to the game when the confirm button is pressed.  However, when the level ends it uses the time that the level was finished minus the time that the level was started to get the value for the time rank category.  With the pause screen implemented, the time calculation for rank does not exclude the time while the game was paused.  Therefore, I will have to come up with some method of tracking the time when the game was paused, and subtracting that off the game time.  Alternatively, I could re-write all the time based code and just keep a variable that tracks the number of updates in the game level screen since the level was started (since the updates on the level screen won’t be called while the pause screen is active).  I think it is too late for that, plus it depends that each update is really 1/60th of a second which may not be the case, so I’ll just have to keep track of the amount of time that the game was paused, and pass that value to the game level screen class after the pause is complete so it can be subtracted off the total time.  What a pain.

I also had to create a new variable in the main update loop to track the previous screen, because coming from every other state (title screen, level select, game win, game over), going to the GAMELOOP state just required the game level screen to be loaded and set to active.  However, I do not want the level to be loaded if the user is just continuing from a pause.

I created a new method in the PauseScreen class which returns the total time (in milliseconds) spent on the pause screen.  This value is then passed to the addPauseTime method that I created in the GameLevelScreen.  One positive thing from doing this is that I found that the total time was being derived in multiple locations in the GameLevelScreen class.  Therefore, I removed that extra code and then used my getTime method in its place.  I just had to subtract off the pause time, which is now stored in an instance variable.

Added two options “Resume” and “Quit” to the pause screen.  Resume goes back to the level screen and quit goes back to the main menu.  This may be a little misleading, if the player expects quit to completely close the game.  I may have to think about rewording that later.  I was able to reuse much of the display and logic code from my delete records screen.  Also, I was finally able to remove the Back button control from the level select screen, since the player can now exit to the title screen from the pause menu.

Added Effects

Made minor tweaks to the delete records subscreen, to correctly place the selector image.

Also updated the drawPieceSelection method in the GameLevelScreen to give more spacing between the selectable pieces.  Created a new background image for the selectable pieces, using another portion of one of my computer card photos.  By default, the background image uses green as the color parameter, but if it is the selected piece, then it uses yellow and is vertically offset by 8 pixels.  This gives the player a color based and location based change to signify the currently selected piece.

Other Updates

Removed the ability to select Quit on the main menu by pressing the Back button, and changed it to the Cancel button.  Now, the only function that the Back button serves is to delete the records.  I think having this rarely used button only assigned to a critical function is good.  This way, the user won’t get confused between the roles of the Back button and the Cancel button.  This also re-enforces the concept that the Cancel button (and only that button) backs out of a menu.

Added spoon sound effect when moving between levels on the level select screen.  Added the plop sound effect when the user select a level on the level select screen.

I tried putting the star graphic for the star rank in multiple places on the game win screen.  First I placed it at the bottom of the ranks, but it looked like it could have been just for the time rank.  Then I put it under the “Complete” text, but it looked odd there as well.  It also didn’t look very good to the right of the “Complete” text.  Since I didn’t like how it looked in any of those places, I decided to put two stars on the screen which circle around the text in a rectangular pattern.  It also gives more liveliness to a pretty much “dead” screen.

The Game Over screen has also be updated to use the improved graphics, basically by copying most of the code from the pause screen.  It’s easy to forget about updating the Game Over screen, since I actually rarely ever see it.

Found that I could use the Rectangle object in place of the Vector2 object to place a sprite on the  screen as well as size it.  This is perfect for my cooldown overlay, which makes the cooldown overlay size proportional to the cooldown duration left.  That means that overlay shrinks (from bottom to top) as the cooldown period continues.  I’m not sure if the Rectangle scales or crops the sprite, since I’m just using a white block with a black transparent color as the overlay.  This may be sometime I look into if I try to get the animated flow working.

Added 10 more levels to the game, bringing the current total to 60 levels.


May 1, 2012

(Gray video distortion fixed.  Thanks to tip from SHADEE.)

Multiple Wire Problem

Noticed a problem that doesn’t happen too often, but when it does it is really annoying.  This is when you place a wire (or resistor) next to two filled wires with different flow values.  For instance, if I place a wire where the blue square is in the first image below, then what flow value should the new wire get?  Should it be a 3 from the left wire or a 5 from the right wire?  Remember, this is my puzzle/arcadey game rules, and not a real simulation so I get to make up the rules.  Currently, it just uses the value of the first check in the if/elseif/else block.  However, this is ambiguous to the player, because the player can’t determine what the value of the wire placed will be.  That’s unless they’re clever enough to figure out that the cells are evaluated in a clockwise manner starting at the top.  So currently the new wire would get a value of 5 from the right wire.  However, if the wire were placed in the blue square in the second image, then the new wire would get a value of 3.  This was confusing me as I play tested the game, so I’m sure it would also confuse other players as well.


Therefore, in the checkStartFilling method in the GameLevelScreen class, I added a loop that calculates the highest value of all the adjacent cells, and uses that highest value for the new wire.  In the two images below, now placing a wire in the blue square will set the new wire’s value to 5 in both cases, since 5 is greater than 1.  It’s not realistic, but a least the player can clearly anticipate what the value will be now.


Connection Problem

This logically fixed the problem, but the display was still misleading, because it would make a complete loop with two different flow values in the loop.


To fix this problem, I updated the draw method in the GamePiece class to only make connections to wires with the same flow value.   The resistor wires are a little tricky, because it’s difficult to determine which wires carried the flow in and which ones carried the flow out.  Another visual distortion happened when two wires with different values were placed next to each other that only had one joining wire each.  Those appeared to connect since the default image for a wire with only one connection spanned all the way across the cell horizontally.  Therefore, I made wire images specifically for only one connection (N, E, S, W) on each side and an image for a no connection wire ( O ) to resolve this issue.  These new images provide a few pixels for a break padding, so that those wires don’t appear to be connected to pieces that they are not connected.  Now as shown the in the screen shot below, with the updated code and images the user can clearly see the flow through each of the wires, and there is no doubt that the value of the wire in the blue square is now 5.

Game Win Screen Updated

Moved the game win display code to the game win screen, to make it consistent with the other screens.  To to this, I had to pass the piece count, luminosity, and time values to the Game Win screen.  Additionally, I had to pass a reference to the level definition object, so that the rank values can be calculated.  I also added a win delay on the Game Level screen, so that there is a one second pause between the time when the last LED is activated and when the Game Win screen is displayed.

More Level Design

Created twenty new levels (21 to 40).  I purposely designed some of the levels to force the player to use the higher level resistors (2, 3, and 4).  I increase the highest level battery used by one for each ten levels.  One flaw that I’m making in level design is making it so that every tile must have a piece to clear the stage.  Technically, this is fine but the user will always get an S rank in pieces used.  Therefore, I should always include a few tiles that don’t have to be used, so that there is a chance for lower piece ranks.


During play testing, I noticed that one level didn’t have any tiles and only objects.  This was due to me exporting the wrong layer as the tile layer.  Going back and exporting the correct layer resolved this problem.


High Level Resistors

The player now starts out with only one selectable resistor (value 1).  Every 10 levels, the maximum selectable resistor increases by one.  This prevents the player from using a high level resistor to lower the initial wire to zero, which would allow the player to quickly complete the level.

Week 3 Wrap-Up

April 24, 2012

(The capture format was set to FLV in XSplit (instead of MP4) with the highest recording quality (20), but there is still some initial distortion in the video after it was loaded to YouTube)

Touch Up Work in Audacity

Touched up the sound effects in Audacity, to give them the appropriate lengths to be used in the game.  For the buzzer, I trimmed down the hair clipper sound effect to 0.25 seconds.  Not sure why, but I wasn’t able to find a crop function in Audacity.  Therefore, I just had to select the portion of the clip I want to use, copy, then paste it in a new Audacity window.  Next I started looking for a sound to use for the main menu.  The buzzers and rings were too harsh of a sound, so I loaded up my shaken Pepto Bismol sound effect.  After cropping out everything except for one shake of the bottle, I realized that this makes a great menu selection sound.  It actually sounds like muddy boots on a wooden walkway.  For the wire filling sound, I slimmed down the running water clip.  The original sound is a little harsh, so I raised the pitch by 265.  The ice sounds were a little flat, so I increased the speed by 200.  It now sounded like an old fashioned money changer.  With this new sound, I added 2 seconds of silence at the end, and then applied the echo effect (delay 0.5 seconds, decay 0.5).  The spoons sounded good without any modification except for cropping out the rest of the noise.  I’ll use this as either a menu sound or a rank display sound.  The spoon hitting the glass made a good sound, but there was a lot of background static noise in the sound capture.  I used Audacity’s noise removal tool to fix it, but it seems to have raised the pitch of the sound as well.  It still sounded okay, so I’ll probably use that as the sound when an LED is lit.  The CO meter made a nice beeping sound, but it was really loud so I used the normalize effect.  I’m not sure where I will use this sound, but I’ll go ahead and import it into the project for now.  This gives me a total of eight sound effects, which should be enough to get me started.


Apparently, the volume of the MediaPlayer object uses a value between 0 and 1, and I incorrectly assumed that it was 0 to 100.  For some reason, the sound when it is played on the PC is much louder than it is on the XBox.  Maybe the XBox (or my television) has sound normalization so it isn’t loud like on the PC.  Setting the MediaPlayer volume to 0.1 makes it sound about right on the PC, which I believe is one tenth of the volume.  I will have to test it on the XBox later to see if that makes it too low to hear on the console.  If it does, then I may have to write some platform specific code to handle the differences between the PC and console.

Ran into a bit of an issue with playing sound effects.  In order to play a sound effect, the current screen must have a handle to the MediaPlayer object, which is only available in the main ResistorGame class.  I don’t want to have to pass a MediaPlayer object to each function on each screen that may want to play a sound effect.  I think I’ll make the sound effects like the screen transition, where the screen will implement a public method which will report whether or not the screen needs a sound effect played.  Then the Resistor game class will query that method on each update, and then play any sound effect that is requested to be played.  I usually don’t write code this way, but I think it may make things cleaner in the end, especially if I decide to write a media handler class.  I created a method called getRequestedSoundEffect in the Screen class and added a protected instance variable called iSoundEffect.  If the ResistorGame calls that method and it returns a value greater than -1, then it will play the sound effect at that index in the sound effect array.  Thefore, any of the subclassed Screen just have to set the iSoundEffect variable to any of the sound effect constants defined in the ResistorGame class.  Amazingly, this worked perfectly the first time that I tested it.  I also discovered that MediaPlayer is not required for playing SoundEffect objects (Songs objects only), but it was good that I implemented it this way, otherwise I would have the same problem with passing the sound effect array around to all of the screens.  Just calling the Play method on the SoundEffect object itself will play the sound.  One drawback is that only one sound effect can be played for each update call, otherwise the previous sound effect(s) ID assigned to the iSoundEffect variable will be lost.  This may be a good thing, because there shouldn’t be too many sounds playing at the same time.  Once scenario that I can imagine is if two LEDs are lit at exactly the same time.  Just playing the sound effect once should be sufficient.

Using Audacity and a short tutorial from eHow, I was able to record my voice for the title screen which I gave a repeating robotic sound.  First, I used the Repeat Effect on the start of the audio clip.  Then I used the Delay Effect with Decay=10, Delay=0.01, and Echos=20.  I repeated that effect about 6 times.  I also made audio clips for “level complete”, “game over”, “S”, “A”, “B”, “C” and applied the same effects.


Level Selection Modification

I may have messed up by making the LevelDefinition instance a member of the GameLevel class instead of the ResistorGame class.  The ResistorGame class needs to pass the maximum number of levels to the LevelSelectScreen class.  The maximum number of levels is defined in the LevelDefinition object, so it has to get a reference of that object from GameLevelScreen which is a little messy.  I may have to rework this later.

Sound Effects Added to Game

After updating the game code, I now have sound effects for menu movement, menu selection, wire begins filling, light filled, and light busted.  I had to add an additional variable to keep track of light filled, since this property was never actually tracked.  I added that check to the game win check, since it was already looping through the lights on the board, so if the number of lit lights is greater than the number of lit lights on the previous check, then the lit sound effect is played.  I was happy with all the sound effects, except for the electricity one (originally water running from the faucet).  It still sounded to static-like, and it started to give me a headache after awhile.  Therefore, I replaced it with the phaser sound that I made (also from the water running) which has a much smoother sound.  I also had the Pepto Bismol sound (now named SE_PLOP in the constants) play on each menu movement and the spoon sound (SE_SPOON) played on the selection.  This didn’t sound right because the SE_PLOP was longer than SE_SPOON, so I just switched out the occurrences of those two sounds, which makes it sound much better.  The lit light and light busted sound effects sound great.  I may need some delay or an animation when a light is busted, because the light busted sound effect plays through the game over screen.

Special Cases

While playing the game, I noticed a special case that may need to be handled.  If a wire is placed next to two (or more) filled wires (or other pieces), I believe it just takes the Elex value of the first one in the if/elseif statement.  I should calculate the highest of all the neighbors, and assign the new wire the highest value of all the adjacent pieces.

Another thing that had been bothering me is that I thought that the time statistic was proportional to the pieces used statistic, which would make it somewhat redundant.  However, through testing I found that it is possible to get a S rank in time and a C rank in pieces by quickly spamming wire pieces.  This is a good thing, which prevents someone from getting the best possible grade by quickly spamming pieces.  The inverse is also true, where someone can get an S rank in pieces but a C rank in time.  Just take a long time laying down the pieces in the shortest path.


Batteries not Included

April 15, 2012

Fill Adjacent Modified

I slightly modified the method for calculating when to start filling adjacent pieces.  Before, when a piece went from unfilled to filled, then it would check to see if it had any unfilled neighbors, and begin filling those.  Now, on every update it loops through all unfilled pieces, sees if those have any filled neighbors, and then begins filling if it has a filled neighbor.  This fixes the problem of not filling a wire if it is placed to a neighbor that has already been filled.  A piece will now begin filling instantly if it is placed next to a filled wire.

Since it is now impossible for the flow to ever stop, then only end game conditions now are when 1) all lights are filled or 2)  one of the lights bust.  Limiting the number of end game conditions to two outcomes is a good thing in my opinion.

Batteries Added

Created a GamePieceBattery class, which replaces the need to manually start filling the first wire from the level startup code.  Batteries automatically start filling without being connected to a filled piece.  Batteries also have a constant Elex value, and they do not take the Elex value from surrounding wires.  Could let the player have a limited number of batteries (just one for the earlier stages) and let the player place the battery on the board.  There could also be only special  cells where batteries can be placed on the board.  One thing to think about is if a wire is already filled and a battery is placed next to it with a higher Elex value, then does the wire take the new Elex value of the battery or start refilling?  Removed all starting cell variables from the GameLevel class, since it is now handled by the battery.  Also removed the level fill wait value, since the battery will automatically filling on its own.

Win State

Added a STATE_GAMEWIN state to the main ResistorGame class, so all of the end level logic, display, and music can be handled in that state.  Much easier than making a bunch of special cases in the STATE_GAMELOOP state.  Created a simple victory fanfare theme, which is played after the player completes a stage.  Got bit by not calling SpriteBatch.begin()/end() again.  Need to find a way to run in debug mode under Windows, so I don’t have to spend as much time trying to figure out the cause of game crashes.  I’ve also added a winning victory fanfare melody, but I’m not as happy with it as my title theme or level theme.  It needs some work, or it needs to be scrapped all together.

Screen Abstract Class

Decided to start working on the title screen, to give the player a way to gracefully exit the game without having to press the default Back button.  I realized that the title screen will be using the same button press handlers and drawing methods as the GameLevel class, so I created a Screen abstract class which defines all of the button press and drawing methods as abstract methods.  The GameLevel class has been changed to GameLevelScreen which now subclasses Screen, and I added the override keyword to all the implemented methods.

I’m going to try a new approach for passing controls between screens in the game.  In Java games that I’ve written in the past, I would have to pass a reference of the main class to the specific screen class.  This was really messy, so this time I’m going to make the screen class report the next screen to display through a getter method, eliminating the need to pass and keep track of a reference of ResistorGame in the TitleScreen and GameLevelScreen classes.  I added a protected variable in the Screen class to keep track of the next screen and a method called getNextState.  This method returns -1 to stay on the same screen or a positive integer to move to a different screen, which are the same states defined in the ResistorGame class.  For instance, when the confirm button is pressed on the title screen, it sets the next state variable to the constant for the GAMELOOP state, and then the next call to update in the ResistorGame class will call the getNextState on the TitleScreen object and then appropriately set the state to make the GameLevelScreen the active screen.  By doing this, I was able to take the state logic mess out of the ResistorGame class and I now just have a currentScreen object of type Screen that holds a reference to the current Screen object, so the button press and display methods are just called on currentScreen, and through polymorphism the appropriate implementation of those methods are called based on the subclass.  If I spent some extra time on it, I could probably eliminate the state variable out of the ResistorGame class entirely, and just rely solely on the class type of the currentScreen object.

The title screen has been modified to display three options: New Game, Level Select, and Quit.  The Back button has now been disabled, and the user must select Quit from the main menu to quit the game.

The Level Select currently just allows the user to select a stage level between 1 and 9 using up and down button presses.  For now it doesn’t actually change levels since there is only one level defined.

Creamy Filling

April 8, 2012

(The video distortion clears up around 0:14)

Pause Problem

Noticed a problem that when the direction pad was pressed, sometimes the cursor would not move until the pad was pressed multiple times.  Increased the PAUSE_FRAMES to 360 (6 seconds at 60 fps) to make this obvious to help with debugging the problem.  The PAUSE_FRAMES constant is the number of frames to wait before moving the cursor again, if the directional button his held down.  The pause value should be set back to zero after a direction button is released, because the cursor should be moved immediately when the button is first pressed down.  As I mentioned in my previous post, the pause value is necessary to keep the cursor from zipping across the screen (moving one cell for each frame).

Used this article to add text to the game, which allowed me to print out the pause value.  Found that I needed to check if the velocity was non-zero before doing the bounds checking for moving the cursor.  The velocity should be non-zero if the cursor is moving.  An x velocity of -1 means the cursor is moving left and 1 means the cursor is moving right.  A y velocity of -1 means the cursor is moving up and -1 means the cursor is moving down.  When the pause value hits zero, then the velocities are added to the cursor’s row and column values.  The problem was that it was doing the bounds checking even if the velocity was zero, then moving the cursor using a zero velocity value, and then setting the pause value back to the PAUSE_FRAMES value.  Therefore, the pause value was continually being set back to the maximum value.  Fixing that problem, along with setting the pause value to zero on direction button released got the cursor working properly.  Set PAUSE_FRAMES value back to 10, so that it doesn’t wait 6 seconds to move the cursor when a direction button is held down.

Filling the Wires

Added a variable in the GameLevel class to track how many frames to wait until filling the first piece on the board.   Also added variables to define the start cell (where the flow begins) and end cell (must be connected to win).

Created new images for filled wires and resistors, which will be overlayed on top of the objects on the game board.  Hopefully, I can specify just a portion of the sprite to blit on top of the existing piece, so I can give the appearance of the piece filling, using the piece’s fill value.  I made these overlays white, so that I can programmatically change the color using the color parameter of the SpriteBatch draw method.  For now, I am just displaying the I-wire as the default piece, and I overlay the I-wire fill using the yellow parameter to designate a filled wire.  The starting piece is currently set to row 0 column 5.  I could change the starting location for each level, or make the starting location random.


I changed the SpriteFont variable to an array of SpriteFonts, so that multiple fonts can be easily defined and used.  Currently, I’m passing the SpriteBatch object, textures (sprite) array, and font array to each object that needs to draw itself.  It may have been simpler to just have those defined as public variables (or use getter methods) so that any object that needs to draw can obtain it from the main ResistorGame object.  However, then every object that needs to draw would need a reference to the ResistorGame object, so it may be more efficient to just create a GameContent object which holds all of the textures and fonts, which could be passed to each drawable object.

After I got the filling to work for the first piece, I had another decision to make.  Once a piece has been filled, should the piece call beginFill on its neighbors?  In order to do that, then the current piece would need a reference to all of the adjacent (neighbor) pieces.  Alternatively, the GameLevel could check for all pieces that have been filled, and then start filling the neighbors of those pieces.  In that case, the GameLevel would need to keep track of the filled/unfilled status of each piece before calling update.  That sounded like the simplest solution, so that is the approach that I took.  For testing purposes now, a piece will fill all of its neighbors (north, south, east, west).  I will start checking for the actual output side variables soon.  I created a fillAdjacentPieces method in the GameLevel class, which takes the current piece’s row and column as paramters, and begins filling the adjacent pieces.  Each piece now displays its fill value in green and Elex value in blue in the cell.  A check has also been added to ensure that a piece is not being added to a cell that is already occupied (not null).


After doing testing with the current setup, the game seemed really fun (to me at least) just laying the wires and seeing them fill.  The queue of pieces and rotating may be too complex, since this is supposed to be an educational game.  I’m now thinking that the player should just have a generic wire, and the wire will shape and split ifself as needed, based upon its neighbors (adjacent cells).  Think of how the roads in SimCity would “fix” their shape based on the layout of the road peices, so that the player didn’t have to worry about using curve or intersection pieces of road.  Just giving the player the ability to cycle through a wire and the available resistors may be the best way to implement this.  If it seems too simple in the end, then I can always add a piece queue or rotation after.  The action button or shoulder button can be used for selecting the component to place.

Changing Wire Images

Decided that the GameLevel class should determine the wire image to use for each piece, since it can find the adjacent cells for a specified cell.  Created wire images for each case.  I can rotate the I, T, and L wire images later for efficiency if needed, but for now each rotation is a separate image.  Created methods for accessing the piece to the north, south, east, and west of a specified cell, which handles all of the array bounds checking.  Using those methods, I created a method for returning the image ID that should be used for the piece at a specified cell based on the adjacent pieces.  This image ID is passed to the draw method of the piece.  Therefore, a piece never knows its image ID value because it is derived each time the board is drawn.  I did this because there are too many cases to handle to keep track of the adjacent cells in the GamePiece objects themselves.  I changed the color of the wire sprites to white, that way I could make them any color (including black) eliminating the need for separate filled and unfilled sprites.


Go With the Flow

Below are  flowcharts illustrating the main state transitions in the game.

The following flow chart shows the transitions in the main game loop.

Mobile Version

Due to the simplicity of the game, it may make a good mobile game.  I know I have more than enough screen real estate just at 640×480.  I’m not sure how difficult it would be to port the code to Andriod or iOS.  I know there is the capability to build a Windows Phone 7 app from the Visual C# Express IDE.

More GamePad Tweaks

Added code to handle the Start button press on the title screen, which currently just transitions to the game loop, just as the confirm button does.  I created a simple test on the title screen to display the X value of the left thumbstick.  This told me that it registers a float value between -1.0 and 0 when pressing the stick left, and between 0 and 1.0 when pressing the stick right.  I pressed the stick about half way left, and it displayed a value close to -0.5.  Therefore, I’m going to use 0.5 as a threshold for registering a directional press.  I know some of my older controllers will register a move when the stick is not moved, just because the controller is old.  When that happens, the controller is probably reporting a very small value (like 0.00001), but the game sees that as a non-zero value and will move whatever object is being controlled.  That’s why I believe there needs to be some threshold value defined, and not create an action until that threshold is passed.  Noticed that the Y axis is inverted from the standard screen coordinate system, so that pressing up on the stick actually returns a positive value and pressing down returns a negative value.