Transitions and Playlist
2014/11/04


Overview

This week was pretty interesting from the development perspective. The sprint began with the intentions to focus primarily on developing the Playlist, as we believed it to be a core aspect of our game. However, time moved forward, we began to question that motive. The core of our game should simply be the gameplay, and the wrapper should not necessarily be required to prove our concept. This doesn't mean the Playlist is in any way being scrapped, but rather, it has become a side-project in favor of some more meaningful investigations into the aesthetics of the gameplay.

A Change to the Menu System

While we intended to fully implement an App Hub menu, we found upon discussion that it was crammed with a lot of content and interactions. It became obvious that the App Hub basis was restricting our ability to effectively design and demonstrate the game's features. While the Hub was familiar, it was ultimately based on the iPhone home screen App selection. This screen was never meant to translate into a more user-driven game environment, and therefore we decided to drop the idea in favor of a more iterative approach.

Our menus needed to be easy to access and understand. Navigation needed to be simple, concentrating on getting the player to desired game sections in order to limit access to undesired buttons. The App hub did not offer this simplicity, but would have forced all forms of selection on a single screen. Creating a playlist would have been very complex, possibly requiring an extensive instruction piece to demonstrate how toggle-buttons worked with the available Apps.

The menu system we envision is still in development, but the amount of freedom in the ways we can iterate on it is important when compared to the limitations of the App Hub menu system. At the current time, we've taken inspiration from other mobile devices to provide simple button navigation. The playlist section also represents a more concise experience that lists all the Micro-Games in a scrolling list, therefore allowing the user to interact with the items and their options, as well as move them up and down the list. A top overlay bar will eventually allow the player to shuffle, play, and interact with the games in any other way we want to implement.

A Change to the Transitions

While thinking about adjustments to the Hub screen, we also reexamined how Micro-Games were selected during gameplay. When watching testers, it was evident that the selection screen did not properly convey the game flow. While the game would highlight an app and begin the game, many testers would attempt to tap games in order to play them. Furthermore, most testers could not easily follow the highlight selection icon, so it was never clear how games were being chosen, rather that they were just abruptly starting.

We took some inspiration from the manner in which the iPhone actually does application swapping. When double-tapping the home button, it is possible to bring up a horizontal list of all running applications. Each application conveys its icon on the bottom, and above it provides a snapshot on the running application.

With this in mind, we decided the transition the selection piece to represent a similar formula. At the start of any game mode, the player will be greeted with a queue of icons and splash screens that will flow to the left, therefore representing the game's progression. Each icon and splash will stop in the middle, pausing for a moment, then expanding to cover the entire screen. After the game is completed, the queue adjusts again, bringing the next Micro-Game into the center. The previous and upcoming Micro-Games can also be seen to the left and right of the central Micro-Game. This provides a foundation for the player to know where they are in the ongoing queue of games. It shows their recent experience, as well as a hint toward their upcoming challenge.

We have not tested this latest version, but will be bringing it back to QA soon in order to survey for possible improvements to continue clarifying the game's flow.

Corruption Problems

Unfortunately, a small chunk of time was dedicated toward some deployment concerns that seemed to spontaneously occur during the sprint. Due to this, I dedicated additional time toward development to compensate for the issue, so this bug was not necessarily a huge hindrance toward development. Still, it required several hours to fix.

The issue related to a seemingly corrupted deployment file. Essentially, while the project was completely fine, something related to the SDKs or certification procedures prevented further deployment to the devices. This issue occurred less than a day following previous successful ventures, so the likely cause would relate to SDK or Tools problem. This is beneficial to acknowledge, since it means that the issue was not caused by project development, but a native part of AIR or flex. While multiple resolution methods were implemented, this was eventually only resolved by reinstalling FlashDevelop and reinstalling various relating SDKs. If anything, this did provide an opportunity to increase the AIR deployment from 3.5 to 14.0.

Playlist Development

Due to our change in project development, I did not spend nearly as much time on the playlist feature as originally intended. However, I did begin creating some of the core systems to ensure that future design is even easier. Within the playlist section, the user can now access a scrolling list of current Micro Games. Each Micro-Game also allows for a one-shot play of the game, which is great for testing and presenting individual Micro-Games. While I will be focusing in other areas during the upcoming sprints, I will still be spending a small amount of time during the final iterations to provide a few more important details to the playlist section.

Conclusion

That basically summarizes the slight change in direction this sprint, as well as some of the areas of development covered. With only a few sprints remaining, we have discussed the necessity to focus on getting the project prepared for presentation. We intend to utilize video and polish art to ensure that the navigation and gameplay currently available is aesthetically appealing. This may mean that code development will be kept to a minimal during the final sprints, in which case I may spend a bit more time polishing some of the areas of functionality and adding additional life to the achievements, playlist, and button animations.