High fidelity prototype - part 1

Last week we started the development of a high fidelity prototype version of the software for the Beat Seeker project.

We are currently encountering problems regarding the way in which Unity3D works with an android device's accelerometer and gyroscope.

The primary problem involves the fact that the accelerometer data is itself not usable for its originally intended application in the design. The one way to overcome this would be to figure out an algorithm to separate intentional directional input from the user and false input that results from rebound on the sensor from previous movement. Even with this algorithm there would be the possibility that the user input could be interpreted by the application inaccurately, which could negatively impact the user's experience by frustrating them. Another way to overcome the issue that actually came to light during a discussion about ways to enable some physically disabled users to use the app; the design of the game mechanics could be modified to use only the tilt controls of the device to allow the user to simply aim at the place that the beat is coming from. This would make the game more easily playable for any users that do not have full use of their arms, and could potentially improve the user experience of all other users as well as they could still play the game by being physically active in aiming the device but they would also have the option to sit down and play the game using the fine motor controls of their hands if they get tired.

We will be attempting to produce gameplay prototypes of both for next week so that we can user test them both to decide which one to use for the final prototype.

Low Fidelity Prototype Testing

This week we planned and acted out a low fidelity prototype for the user gameplay interaction. One person takes the part of the player whilst the other uses a phone playing sounds to be the target that the player seeks out.

In the feedback from this prototype we received 3 positive comments:

• Seems original and creative
• Game mechanics are pretty intuitive
• Potentially addictive

and 4 constructive criticisms:

• It requires good headphones to play the game easier
• Likely to appeal mainly to a very niche market, difficult to make appeal to a wider audience
• Seems difficult to locate target by audio alone, perhaps too difficult (may require balancing with increased target size, etc.)
• Potentially addictive

In a higher fidelity prototype we would probably be making a software demo capable of the basic features of the game: tracking the player's score, using the accelerometer to seek out the target. The player would also ideally use headphones for this in order for us to accurately test how well positions of virtual objects emitting sound can be represented with such equipment; this would allow us to adjust the difficulty of the game and the size of the target accordingly. However, as it stands this low fidelity prototype is still useful as a proof of concept and gets the idea across well.

Literature Review

Bibliography:

Cairns, P., Li, J., Wang, W. and Nordin, A.I. 2014. The influence of controllers on immersion in mobile games. Proceedings of the 32nd annual ACM conference on Human factors in computing systems - CHI '14. (2014).

Caramiaux, B., Altavilla, A., Pobiner, S.G. and Tanaka, A. 2015. Form Follows Sound. Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems - CHI '15. (2015).

Edwards, A.D.N. 1989. Soundtrack: An Auditory Interface for Blind Users. SIGCHI Bull. ACM SIGCHI Bulletin. 21, 1 (Jan. 1989), 124.

Hincapié-Ramos, J.D., Guo, X., Moghadasian, P. and Irani, P. 2014. Consumed endurance. Proceedings of the 32nd annual ACM conference on Human factors in computing systems - CHI '14. (2014).

Mereu, S.W. and Kazman, R. 1997. Audio enhanced 3D interfaces for visually impaired users. SIGCAPH Comput. Phys. Handicap. ACM SIGCAPH Computers and the Physically Handicapped. 57 (Jan. 1997), 10–15.

Game Description

The project we will be designing is as follows: 

Player can move their hand in 3D space using the accelerometer and gyroscope in the phone. The player must seek out where music is coming from by listening to it and feeling for the haptic feedback it produces. The music will change based on the player’s hand’s proximity to the object it is coming from. The player will have a limited time to seek out the music each time, this time is refreshed every time the player successfully touches the spot that the music is coming from. When the player finds the spot that the music is coming from in time their score will increase, else if the time runs out then the game will end.

Due to the fact that the game does not use any visual elements it means that visually impaired people will be able to play it.

Currently we are working on a document that specifies:

1. A description of the application

2. A list of Stakeholders

3. A list of Personas

4. A list of Scenarios (state how we have determined who the user group is)

5. Alist of Tasks (what the user’s goal is when it comes to our application)

6. A List of requirements

7. A List of user experience and usability goals (as well as an explanation of why they are relevant)