Tech Week!
2014/10/21


Overview

So, while I did want to begin crafting a lot of the actual Hub / menu content, I decided that it'd probably be best if I spent a Sprint just simply looking at final pieces of tech that might be required for some of the Micro-Games. This was primarily to determine an initial investigation into the viability of options such as phone vibration and phone tilting. While further research and development will likely be done at a later time, since the Hub layout will likely take one or two Sprints, it would be best to get tech research completed so the rest of the team might be able to design Micro-Games with those factors in mind.

Implementing Vibration

Getting phone vibration implemented ended up being a larger challenge than I initial expected. Once completed, the actual function call is extremely simple, but connecting the ActionScript code with the iOS was another matter entirely. I needed to research the Adobe Native Extension, and then follow some extensive guides discussing the adaptation of batch, xml, and import procedures in order to properly install the Native Extension. This process, due to the number of times I restarted and tackled it from various perspectives, took several hours to complete.

However, once completed, the actual result is relatively simple. When a vibration is desired, a simple function is called, and the phone follows expectations. While simple, this process was worthwhile, since it provided us with the knowledge of some limitations that will need to be factored into Micro-Game design. iOS does not allow developers to change the length or intensity of any given vibration, and it is primarily determined by the smartphone. This simply means that we cannot utilize vibration in any particularly creative ways, such as trying to create patterns for feedback. Still, we can call it once to create a 1-2 second vibration, and it is possible to continuously call it for reoccurring vibration pieces.

Answer the Call

Utilizing the vibration component, I added one of our designed Micro-Games surrounding the idea of answering a particular person's call. Unlike other games, this one is not time-based, as the routes of failure involve answering the wrong call or missing the designated caller. Once in game, the player will encounter several occurring calls from various people over about an 8-second time period. These calls will continue for a set duration and disappear. The player can decline calls to remove them from the screen earlier, allowing them to focus on finding the indicated caller.

Once a caller appears on the screen, the phone will begin vibrating. Each caller will also exhibit their own ring sound, thus populating the game with a number of amusing ringing sounds to distract the player in their search. Overall, the game's content is relatively simple, but does show a simple and effective use of the vibration mechanic. It will also be possible to use the vibration mechanic in other ways, but we just need to be careful knowing the limitations and the possible exhaustion that could occur if we utilize it too much, as most players will only enjoy it if it is used sparingly.

Implementing the Accelerometer

Oddly enough, this was essentially already built within the code. Aside from researching how it is called and manipulated, this did not take long to set-up. However, opposite of the vibration mechanic, this one ended up being much more challenging to utilize in a game context. Acquiring the information regarding the accelerometer's value is easy, but actually utilizing them for intricate details is difficult.

Move the Object

I decided to create a game around tilting the screen to move an object. The basic idea of the game would be time-based, and failure to reach the end of the puzzle within the time would create a loss state. At first, it seemed simple enough to develop, as it would just involve bare minimum movement mechanics, but then I soon realized that there was much more to deal with along the way.

Movement with the object using the accelerometer is no doubt the biggest issue. While the values acquired are correct, they do not translate well to the tilting game. This is related to how the accelerometer stabilizes and effectively defines differences in tilting. After play-testing movement, it became obvious that it was working properly, but the responsiveness of the tilt mechanic was not up to par with player expectations.

Another issue was somewhat unrelated to the tilting, but represents the reality of collisions within the game. Moving an object through a maze area is unfortunately treading into the area of game physics. And, given the nature of the simplicity of Micro-Games, this process should not take up a large amount of time to create. If we were making a game entirely about this one mechanic, we could spend a lot of time polishing, but because of its limited nature, it is best to avoid spending too much time developing. With that noted, I did spend a decent amount of time trying to perfect some tile-based collisions, which mostly works, but is not entirely reliable given the addition of the tilt mechanic.

The conclusion from this experiment is the reality that the accelerometer is available; we just need to utilize it sparingly. For simple games that involve a quick motion or slight movement, this feature would probably work best. However, the tilting game potentially requires too much response from the moving object, and while we can leave it within the game for now, we may want to remove it until next semester. A lot of the accelerometer work can be done properly by examining how other mobile games have implemented and polished the feature, but that's ultimately another task for later down the road, as other aspects take priority.

Conclusion

This week has been primarily about researching technology relating to the vibration of smartphones and the physical movement of the phone. I also polished some of the other games, added some self-created music, and even added art assets wherever available. With this information in hand, we can think more about how to design games around these limitations. I should also now be able to move forward with the creation of the Hub system for the next few Sprints, which will allow us to bring all of the Micro-Games together in an even more meaningful way.