This Sprint involved a huge leap forward in tech, primarily relating to the addition of a new Micro-Game, polish bits, sound, and game mode components. I would have enjoyed focusing specifically on the creation of at least one more Micro-Game, but other project demands centering around documentation, disciplinary interviews, and sound / menu requirements had me busy designing the back-end managers to govern state flow.
This game actually only took a few hours to design mechanics, create prototype art assets, and implement into the current codebase. After the previous course meeting, I took a few hours to build the entire game, making it possible to also bring to the QA session the same night. My reason behind pushing the new Micro Game forward was to further populate the current list, as simply cycling through a minimal amount does not allow for too much gameplay.
The game has a very simple mechanic, which basically involves requesting the player to set-up toppings depending on what they visualize on the displayed pizza. The game begins by taking a range of potential topping amounts. It then randomizes the topping type and placement on the pizza. Topping placement refers particularly to whether the topping in on the left, right, or full part of the pizza. The player then must tap the icons next to the topping grid to confirm which toppings are visible, and where they are on the pizza. A submit button allows them to validate it before time runs out.
Overall, the game was received with a lot of interest by QA testers. After learning the basics, the game provided another simple Micro-Game that fit in terms of complexity with the others. The only issues our team will need to further examine is how to initially teach the player the mechanics, as well as how to distinguish all of the toppings. Testers mostly commented that they were not aware that the toppings could be selected more than once to alter placement, but after a few amends relating to the UI display and art, this became a lot more apparent. Still, we'll need to look further in order to clarify the details of the game even more.
This really just represents a minor category, but through feedback, I've been adjusting values in various locations to improve the interactivity of the Micro-Games. Scrolling and tapping should be even more accurate. The filter game will now swipe faster, and any images released before swiping will automatically align back to the center. Overall, these various touches to the code have improved the game's quality quite a bit.
I was not sure how difficult it would be to implement sound, although this mainly related to the uncertainty of unpredictable problems that may have occurred on the mobile device. However, the actual process was relatively easy, and I built a simple sound system around it. Any instance within the game can add IDs and embedded sound links to the Sound Handler. The Sound Handler will then create a new form of the sound and place it into a dictionary. Future PlaySound() calls will then cause the sound to play, and once the instance closes, it can remove all of its sounds. This allows the game to only load and utilize sound components when it needs to, therefore limiting the amount of content loaded at any given time.
These represent the most extensive project for this Sprint. The original prototype was well developed, but only designed to cycle through the games indefinitely. Therefore, I needed to continue building around this Handler in order to generate a flow of states leading to and from gameplay. Therefore, I created a State Handler, beginning on a Menu State. The Menu State currently just offers two buttons, and these buttons lead to two other states, Stock Mode State and Goal Mode State. The State Handler enables a system that allows any object to request a State change. The State Handler notifies the active State to Leave(), sets the new State, and then calls the Begin(). This allows any State to theoretically move to any other State. Both the Stock and Goal Mode States are relatively similar. Each one has an instruction piece and a begin button. The Goal Mode State offers gameplay surrounding the idea of allowing the player to climb to a peak. The player selects one of the displayed Goal Score amounts, and must player games to reach that Goal Score. If they lose a game, their score drops back to 0. Therefore, this is a very challenging form of gameplay. The Stock Mode has an easier type of game flow, allowing the player to choose a Goal Score and Stock Amount. The Stock Amount represents the amount of lives the player begins with. Subsequent losses reduce the lives amount, and upon reaching 0, the player loses the game.
Currently both of these modes simply lead back to the Main Menu regardless of whether the player is victorious or not. Sound effects provide confirmation feedback, but this Sprint I wanted to focus on the overall structure, as the actual specifics for feedback-related content are still under design development. Ideally, the player will be represented with a report screen, but the actual report values are still being considered.
The actual development process for these systems took quite a while. This is primarily due to the amount of back-end design required to make future additions even easier. For instance, while implementing the first mode took several hours, implementing the second mode probably took a maximum of one hour. This development was also hindered by the design of a Swipe Button, which is basically a button the player swipes off the screen to activate. This was only difficult due to the amount of complexity required to ensure that it felt comfortable to utilize. This means that after swiping, the button still drifts for a short while, and it also will either align back to its original spot, or continue off the screen is close enough.
Aside from these programming development bits, I also spent a bit more time working on other parts of the project. Aside from consistently writing meeting notes, I also ran a QA session and wrote up the QA Plan Documentation as well. I met with Dean Lawson and Peter Wehr toward the end of the Sprint duration in order to discuss the overall project direction. In the next Sprint I intend to continue creating at least two more Micro-Games while our current iteration is being tested at QA, therefore providing us with more material to test the overall gameplay going forward.