Previously I built a system for allowing ease of access to Statistics information, therefore allowing Achievements to easily be created that would request test values for unlocking. This iteration, I my primary task involved taking the concept of the Statistics system and permanently saving the information changed over the course of gameplay. After major events, application exit, or during set intervals, the game would need to be able to save all information to a file on the mobile device. Beyond creating these features, I also wanted to spend some time improving the current visual aspects of the Achievement system, and in particular, I wanted to add feedback to convey progress toward player goals.
While there are many ways to save information within ActionScript, given the simplicity of Statistics information being applied, I chose to work within the SharedObject environment. In ActionScript, a SharedObject allows for any type of data to be set and store to a SharedObject, therefore allowing the potential for custom classes and lists to be saved during gameplay.
When the SharedObject file is called, if it does not exist, the application will create a new SharedObject for use. While not containing the information required to load, the loading procedure can then check to see if any of the variables required are available, therefore loading all data that is possible. This is important, since it means that development can easily allow for newly created information, without wiping previously saved data. In other words, if a tester were to unlock an Achievement, even with a later build, the Achievement information will still be stored, even when new saved information is added.
During the Loading process, which begins after everything is initialized, the game grabs the SharedObject file and attempts to load all applicable variables. If these variables are not set, it then sets the SharedObject with the starting, or default values. After the loading process ends, the game then saves. This ensures that after a new game has begun, the game immediately will create a new game file and save it, allowing for it to be utilized during future sessions.
Since setting the SharedObject data only influences the local version at runtime, the flush function must be called to actually save to the SharedObject file. This call must be done sparingly, as the saving process can cause brief moments of performance issues. Therefore, this is only done in three instances. First, whenever a major event occurs, such as an Achievement unlock or crucial progress, the game is then saved. Furthermore, exiting or deactivating the game will also serve to save information. Finally, every 10 seconds, the Statistics information is updated and saved to the file. In most cases, the exiting of the game exists as the most meaningful save points, but it is worth saving consistently in order to prevent substantial loss if a crash or unexpected exit were to occur.
When the SharedObject is saved, before flushing to the actual file, the Statistics system is also called to update its set information. It is expected that all saved information external to the Statistics system will set its data and call the save function when required. However, since the Statistics system is always actively updating and changing its contents, it only sets its data when the save function is called to prevent excessive saving for Statistics. For instance, if the Statistics is constantly incrementing the time spent playing the game, this information is only saved to the file during the major events, exit situations, or time intervals as mentioned previously.
With extra time available to develop some features further, I decided to go about improving how Achievements are currently displayed to the user. Aside from adding the currency value in anticipation of a later mechanic, I also focused on creating the Achievement Bar. Each Achievement can have any number of Achievement Requirements, but generally most Achievements will only have one. With each Achievement Requirement, there is a goal required to hit before it is completed. By adding an Achievement Bar to each Achievement Requirement, it is possible to visually display progress toward the end goal. This displays a bar showing the percent progress, as well as a text display to represent the actual number. So, if a player has won 5 out of 10 games to earn an Achievement, the bar will be at 50% with the text "5 / 10".
As noted, since an Achievement can have more than one requirement, it is possible to have more than one bar. While the functionality is available to have multiple bars, the Achievements need to be slightly redesigned to scale in size in order for them to all be visualized on the screen. This will likely wait until a later polish point, or when Achievements have an urgent need for multiple requirements.
With permanent saving / loading finished, along with a few improvements to the Achievements, next week I intend to take a brief break from the back-end and develop 2 more Micro-Games. I should also have time to implement some more of the Achievements created by designers, since many of them can easily correspond to save data for the Micro-Games. The goal behind developing more Micro-Games primarily relates to providing more content for QA and the Art team to work on, since at the current moment there have been no recent major front-end developments.