Achievement System
2015/01/16


Overview

This week involved two areas of project development. First, with additional team members, there is a need to review a lot of the project guidelines, review some of the choices in project direction, and also ensure that the project available on the repository is functional for all personnel. Beyond this, I also wanted to quickly continue developing the game's framework, and I decided that the first step would involve creating the Achievement System to assist the game's progression. Ideally, after creating the system, programming the information to save and test against would not take too much time, therefore allowing us to quickly design general Achievements and unlockables with future Micro-Games.

Ensuring Project Access

Early in the sprint, it became apparent that the project still had some restrictions in terms of access. While I previously made most of its features based on relative paths, the other programmer had some difficulty deploying to the device. After a bit of research into possible problems, we eventually realized that not all of the Air SDK files were properly committed. The only reason this eluded us for a bit, was simply because these files were never intentionally ignored. Furthermore, despite being available on the source laptop, the repository did not seem to even register them in terms of committing or removing. Removing the entire SDK, re-adding the SDK, and committing has resolved this issue, therefore allowing the project to easily be deployed from any computer station.

Statistics System

Before creating Achievements, I needed to first build a process for saving any / all information within the game. While I thought about a few different designs for this structure, eventually I decided to build Statistics based on a bucket structure. Essentially, the Statistics System can own any number of Statistics classes, and it grants access to any objects interested in either accessing data or incrementing values. Each Statistic represents an off-shoot of the base Statistics class, which basically serves as storage for any type of information required for that particular Statistics class.

For instance, a Statistics_MicroGame class exists, which basically can keep track of wins / losses for games. Inheriting this class, each Micro-Game can also keep track of any game-specific values or occurrences. Any object can then request desired Statistics objects, cast it to the expected type, and then access its functionality from anywhere within the game's code structure.

Achievements: Creation

Before creating the actual Achievement System, I had built a temporary structure for reading in visual Achievements for the Achievement Menu. The XML file essentially determined the title, description, and unlock state of the Achievement. However, this would also require writing functionality into the XML file. Instead of building a unique class for every possible Achievement, it becomes manageable to allow an Achievement to assert a Statistics item, return function, and test value. This then allows an Achievement to request a piece of saved information, then testing it against the test value. Furthermore, this can also be built to allow for multiple Achievement requirements, in case an Achievement needs to test more than one circumstance. In these instances, Achievements simply contain a vector containing all requirement tests.

Achievements: Resolution

Continuously during gameplay, Achievements can utilize request information to test the current Statistics value against the XML test value. When this value is matched or exceeded, the Achievement is then considered unlocked. However, in the event of multiple Achievement requirements, the Achievement is not unlocked until all test values are passed. For instance, an Achievement may require a player to win a game of LikeThePosts, while also liking 10 or more posts. In this case, the Achievement would first test for the game won, then it would test to see if the Statistics current iteration holds at least 10 posts liked. Statistics information can easily be added to each container, allowing any Micro-Game to keep track of as much information as required.

Achievements: Revealing

Due to the available Achievement Menu, simple unlocking only required changing the visual lock state, therefore displaying the trophy symbol. However, the process of displaying Achievements when immediately locked is a bit more challenging. In its simplest form, it primarily involves showing the Achievement for a moment, but due to the limited screen space on the smartphone, it also requires additional usability features to ensure it does not disrupt or distract from gameplay. For instance, having the Achievement display from the bottom could prevent some button presses in Micro-Games, so the implementation requires careful design to avoid limiting Micro-Game gameplay. Another issue relates to situations where multiple Achievements may be unlocked. While infrequent, this may occur, and requires a method to effectively display all unlocked Achievements.

To resolve the first issue, at the current moment I've managed to display the Achievements briefly over the top UI. When unlocked, Achievements essentially take a snap-shot of their unlocked images, sending the image reference to the Achievement Revealer. This will then position the Achievement image above the screen, allowing it to descend, hover for a moment, and then retract upwards once more. Although it does cover the UI for a moment, this is far better than allowing it to cover possible interaction space. Furthermore, it will be possible to resize and offset the Achievement, therefore allowing to primarily covering the score section, as it is the least relevant component when compared to the time and descriptor sections. Achievements are also placed in a queue, therefore allowing the process of revealing to repeat for each Achievement unlocked.

Conclusion

With a base for the Achievement and Statistics System in place, it will now be possible to begin programming many of the save features required for Achievements and progression details. The next sprint will likely focus on building a process for saving and loading information on the device, as well as creating additional Statistics information to be utilize later for unlocking / purchasing new Micro-Games.