Reflection & Lessons Learned

This is a list of ideas and lessons that we learned about innovating in 3D user interfaces. It derived from reflecting upon the process of coming up and developing our own design (VIGOR), as well the designs of fellow students in the class. It also encompasses philosophies and perspectives that we came across in our readings and discussions.

• Innovating in design, in general, has greatly to do with emotional impact; most novel designs pocess some kind of attribute(s) that makes you express awe (the 'wow' factor)
• One significant catalyst for emotional impact is fun (or joy); making things fun improves the user experience in everyday activities (the fun theory), but can also mobilize innovation by means of making users be part of a new 'cool' way of doing things (through identity, accomplishment, and sensation)
• Designing for innovation is not trivial!
• One way to innovate is observe things from a totally different angle than the one people have been doing so far; e.g., use a device with a different way than the one originally intended (kinect fusion), or develop new ways of interacting with conventional interfaces/artifacts (transform the iPad into a slingshot)
• Innovation in 3DUIs can stem from two disparate approaches: coming up with new technologies to support improved ways of performing tasks (google glasses), or using existing technolgies in new ways for the same purpose (MRI scanner with kinect)
• Another distinction is the application area; 3DI techniques for scanning medical data sets can bring novelty in a specific work domain, while manipulating water virtually can be seen as a more artistic and entertaining kind of novelty
• It is potentially easier to design novel 3DUIs by insterting ambiguity in the initial concept and let the design process and actual usage define the outcome; this can be afforded in artistic/entertaining experiences (like VIGOR) but not when designing tools for efficient task performance (e.g., data set manipulation)
• Let your imagination totally free during the brainstorming/ideation sessions (a'la IDEO); constraining your ideas based on what you know or existing/similar uses of technology will not get you too novel outcomes (VIGOR started as a vague, day dreaming idea)
• As specific 3DUI technologies proliferate it is much more difficult to come up with innovative uses for them, simply because too many people have invested in the exact same thing before you! (...either for research puproses or simply for fun)
• Another approach to innovation is combine technologies in ways nobody else has thought before, which explains why it is actually difficult when technologies have been out for long periods of time
• Yet another one, is to foster collaborative 3DUI techniques in activities which were thought to be solitary up to now; examples being VIGOR as a full body gaming interface for remotely-located players, and Microsoft's Livespace for performing co-located collaborative tasks in real space

 

Design implementation & issues

The design of VIGOR is on the right track and I have made quite some progress since the storyboard post, three weeks ago. Most of the game play is developed and although it is still not for two players, it is quite enjoyable and energetic to shoot your avatar and try to avoid the bullet (ball) at the same time! I have also added some sounds to make it more fun. A list of the things I have added and tested so far is included below:

• Head tracking of the player which takes into account the proportion of the virtual space width and the available physical space for moving.
• Shooting using a kick move (works with both feet)
• Shooting through the window when the opponent is frozen, for picking up the bonuses (currenty not there) 
• Zooming in and out of the avatar when it is hit
•  A blue haze revealing that the hit player is frozen
• Adjusting the ball speed according to the distance between the player's hands at the time of the kick (power indicator included)
• Indicators showing the body width of the player
• The ball being shot from the opponent's avatar towards the player
• A working score counter (it should be "P1 vs P2" in the final version)

Although the kick move is rather fun and a good metaphor for shooting against your opponent, I wanted something even more vigorous! (to fully justify the name of the game). For this reason I just implemented a "power kick" move, which demands from the player to make a combined gesture with the feet, as a result of which the power of the move is duplicated. The move is very similar to the Karate Kid "crane kick", where the player has to lift one foot high and then kick with the opposite foot while jumping in the air.

The "crane kick" from the Karate Kid movie

 

Sciripting has also been adapted so that the game is ready to be transfered to a second computer and played with two players. However, testing with two machines remains to be done to make sure that it can sustain an enjoyable experience. The main problem is that I am using the OpenNI framework, which is not compatible with the Kinect drivers being installed in most of the available PCs. Once this is resolved I will be able to try the competitive experience offered by VIGOR. I have also changed both virtual environments in order to make them more appropriate for this type of game. After including the bonuses and testing picking them up I may end up using different ones, but for the moment they suffice.

A demo of the current stage of VIGOR is provided in the video.

One of the issues which is visible in the video, is that there are instances where the balls collide, because the players are basically exactly opposite each other (since there is only one player). What is also not implemented is the window to appear exactly on the opponent's avatar position and dimensions. In this version the window appears roughly where the avatar (box) is and in a predefined size. I did not spend any time on this intentionally, because I would like to make the whole avatar as a window in the opponent’s world using the world’s render as a texture of the avatar. This demands quite some implementation time and I currently wanted to focus on the game play aspects.

Finally, another issue which is sometimes apparent is that the indicators of the player’s size do not directly correspond to the avatar’s size. This is rather difficult to implement and depending on the movement and size of the player there can be cases where the ball seems not to cross the indicators’ boundaries, although the avatar is actually hit, or vice versa (both cases can be seen in 0:25-0:31 of the video). This side effect is more obvious when the player has increased his size; although the ball appears to move way off his position (in the first person view), it can appear to collide with his avatar (in the view of his opponent). I don’t know if this will be as obvious in two-player mode, but I currently have no solution.