Level Select
Began working on improving the Level Select screen. First, I needed a method to convert the numeric ranks to a character or string. I really didn’t know where was the best place to put this method, so I included it as a static method in the LevelDefinition class, so that other classes won’t need a reference to a LevelDefinition object to get the string representing the rank (S, A, B, or C). And yes, you can spell three letter dirty words using the rank letters.
Next, I got the vertical scrolling working on the level select screen. Defined variables to track the number of levels displayed on the screen, the offset level (minimum level displayed), and the currently selected index. The selected level is the offset level plus the selected index, which is a derived value calculated in a method. In the screenshot below, the offset level is 3, the selected index is 4, so the selected level is 7. I may go back later and add another static method to convert the level numbers to more meaningful values, such as “1-1” for level 0, “1-2” for level 1, and “2-1” for level 10. If the user presses down and the currently selected index is the maximum number of levels displayed on the screen, then the level offset is increased by one (unless the maximum number of levels are already displayed). If the user presses up and the currently select index is zero, then the level offset is decreased by one (unless the level offset is already zero). Simple up and down arrows are displayed when the minimum level index can be increased or decrased, letting the player know that there are more levels to be displayed.
Saving Data
I was able to get simple saving done (just strings) a few days ago, but this really didn’t actually save any of the game data. So I went back and created a method in the PlayerRecords class which serializes all of the record data. Basically, it just writes out one line for each level. The line first contains a Y/N value indicating if the level was completed, then three pipe delimited values containing the integer value for the ranks achieved for that level. Conversely, I created a parse data method which takes a string acquired by my file load method, and uses splits to read data out of each line and out of each pipe delimited value. These values are then stored into the data arrays. I also created a reset method, which clears all data by writing an empty string to the save data file, and then loads that data file.
Clearing Data
I also wanted to give the player the ability to delete all their records, in case they want to start fresh. This was accomplished by calling the reset method when the Back button was pressed on the Level Select screen. However, this made it too easy for the player to press Back and wipe all their data. The player could have just wanted to go back to the title screen and didn’t know which button to press. Therefore, I created a mini-state within the level select class which prompts the user to confirm if they really want to delete all the records. The default is (obviously) “no”, so the user has to consciously press up to change the value to “yes” and then press the confirm button. The one thing that confused me was that the selected index for the “yes” value was zero, since it was the choice on top and “no” has a value of one. This goes completely against my programming instincts, where one is a positive or true value, and zero is a negative or false value. The one exception being the return values from main in a C program, where zero is success and a positive value is an error return code. This functionality could have been extracted out into its own Confirmation Dialog class, but I didn’t feel like taking the time to do the required setup to get that working, since it would not fit my standard Screen display model. So instead, there is just a boolean in the Level Select class which determines if it should display the confirmation screen and process the events on the confirmation screen. It’s too bad that I can’t use my menu code that I wrote in Ruby for TetraCity, because it is a very solid menu’ing system that I wrote.
So now it looks like I am almost completely done with the core functionality of the entire game. The only thing that I know that needs to be changed is that when the user replays a level, a rank should only be overwritten if the user actually gets a better rank than the one currently achieved. It should also let the player know if they have beaten one of their previous ranks. Currently, the rank data for the level will be overwritten regardless. I could add an options menu to change the sound volume and button layout, but I think there is very little value in doing that compared to the actual benefit of having those options. If the sound is too loud, then that is the reason why television remote controls have volume controls. Nobody ever really looks at credits screens, so I don’t see the point in making one. None of the classic games ever had credit screens, aside from the credits that play at the end of the game.
The final two main tasks that remain to be completed are the improved graphics and finishing designing the remaining levels. Each level requires the array data to be generated in Mappy, and then I have to manually add the rank requirement data for each stage. Finally, I could add an ending screen which displays once the player completes all levels.
