Category: Writings

Posted on

It’s Time for a Change

Bust Condition Handled

Added code to detect if an LED has busted, which makes the game transition to the GAMEOVER state.  Added a GameOverScreen class to handle the display of the game over state.  Need to determine if I should give a warning to the player if the wire connected to the light is higher than its bust value, and allow the player to put a resistor there before the light has filled to avoid losing the stage.  Currently, once the light starts filling it is locked to that value, which doesn’t give the player a chance to fix their mistake.

Will add a meter to the lower right corner to display the Elex flow value of the currently selected cell.

Time Variables Added

I was able to get the current game time using the TotalGameTime.TotalMilliseconds property of the GameTime object that is passed to the update method.  However, I had to update all the update methods of all classes that extend Screen to accept GameTime as a parameter.  Created three new instance variables to the GameLevel class for holding the level start time, the current time, and the end time.  The end time is now displayed on the game win screen.

Level Definition

Created LevelDefinition class to hold the definition of the layout of each level along with the requirements for each piece/time/luminosity rank.  Created arrays of size 3 for holding each grade threshold.  Index 0 is for the S rank, index 1 is for A rank, 2 is for B rank, and all greater values are assigned C rank.

Fixed the getPieceCount method that returns the Pieces Used end level statistic to not count the LED and battery pieces, but only wires and resistors.

Added methods to the LevelDefinition class to take a piece count, luminosity value, or time and it will return the grade rank for each of those values.  The grade ranks are now displayed on the game win screen.  Using yellow for S, blue for A, green for B, and red for C.

Just thought I would reiterate the fact that I’m trying to make a fun game that is as scientifically accurate as possible, instead of trying to make a scientific simulation as fun as possible.

Posted on

Batteries not Included

http://www.youtube.com/watch?v=GUvDc-xiLC4

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.

Posted on

Winner Winner Chicken Dinner

Win State Added

Each time a piece is filled, the checkWinner method is called which loops through the board array, and returns true if all of the GamePieceLight objects are filled.  Learned that “is” is the equivalent of “instanceof” in Java, which I use to determine if the piece at a given cell is a GamePieceLight type.  Created method to return the number of pieces on the board.  The fewer pieces used, the higher the score.  Created method to return the luminosity of all lights on the board, which is the sum of  the Elex values of all the GamePieceLight objects in the board array.  The higher the value, the more points.  A perfect bonus is awarded if the luminosity value is sum of all the bust values of all the lights.  Added bust instance variable to the GamePieceLight object and added a getter method.  Created drawWinner method which displays the end of level statistics, which the player is graded upon.  I think I’ll just use the classic S, A, B, C leveling system for now, and I will need to set point values for each grade in each level.  The drawWinner method is only called if the hasWon variable is true.  Later, I will also add the level time as a third statistic which the player can earn points.  However, this may not be a good stat since time is somewhat related to the pieces used.

When the user has completed the level, a confirm button press will create a new GameLevel object instance, which will start a new level.  For now, it is just the same level, but in the future the level layouts will be different, and the GameLevel constructor will probably take an ID parameter that determines which level will be loaded.

For the first test, I set the bust values for all the lights to 8, which is the same value as the starting wire.  Therefore, I got a perfect score for just connecting all the lights without any resistors.  Next, I used a few resistors to lower the overall luminosity value.  It correctly returned the sum of the luminosity of all the lights which was 20 (6 for the first two lights, and 4 for the lower two lights), so I didn’t get a perfect luminosity score this time which required 32.

Luminosity and Bust values displayed

Added the bust numbers to the lights in red when the light is not filled.  When the light has filled, the number changes to its luminosity value and is displayed in blue.