When a player first starts the game, they shouldn't be able to skip to the last level. They need to unlock each level sequentially and be able to go back to previous levels on future replays. This requires the game to save its state so that it can be persistent when the player closes and reloads the game. The data for a saved game needs to be stored in a text file in a location that unity provides. Storing in a text requires a protocol to write in a certain format so that when it reads the save file, it can upload the correct information. Instead of dealing with parsing and protocols, I decided to use my knowledge when I interned at Amazon.
At Amazon, I was working on a cloud computing service that required the service to constantly read and write from a NoSQL database. A queue needed to be stored in the database, so the queue had to be transformed into a format that could be easily sent across a network in packages and stored. The obvious solution was to serialize the queue. This allowed the queue to be easily stored and when I needed to read a queue from the database, I would get the data and be able to deserialize it into a queue data structure. No parsing or anything fancy on my end (except for some encrypting).
By having the save data be a struct with the most important items to be able to load a game state and save it, I could easily store which level had been beaten and which level was still locked. Since we only had 3 levels and weren't going to create any more, I made the decision to hard code levels as bools for speed sake. If given time to go back and redo the system (or my assumption on the levels are wrong), then in the struct, I would have a level dictionary that would store the level name as a key and if it had been unlocked as the value. The level name can be provided from outside the class so there is no hard-coding. Also more elements can be added to struct if there are other game states that we want to save. The game would save whenever a level was beaten without the player ever knowing or having to explicitly save or load a game.
After creating the saving system, I needed to revamp the level select menu. At Alpha, the level select menu was just a sub-menu that would display a list of level names that the player could choose. I got rid of the sub-menu and replaced the play button to go to the new level select menu instead of the first level. The level select now features 3 images, one for each level. The levels that are locked will have a lock symbol on it and the player can only choose unlocked levels. The system works well, but there is one flaw. Since the level menu is in its own .unity file (new level), the music stops when the player goes to the level select, and when the player goes back the music starts up again. This is considered part of the main menu, so the inconsistency is jarring. I either need to make the music persistent between the two scenes, finds a way to make the level menu interact with the regular menu system, or new music can be playing when selecting a level which may be fine. These are design decisions that can be addressed at a later time.
I am very interested to see how the semester goes and am excited to release what should be a great game.
