BOUNCE AR

Game Design and Prototyping Process

by Gabe Turow, Miriam Melnick, Kevin Lin, Zhixiang Wu

Overview

Bounce is a 3-D puzzle game that challenges the player to beat a variety of levels that steadily progress in difficulty and complexity. Using a laser-wand, the player must cause the projectile-launching beam of the laser to bounce off of most or all of the panels in play, and then pass through the torus goal on each level, colliding with the target sphere located at the center of the torus. Players are given the capability to immerse themselves in the game through a sizeable game-board that the user can choose to physically navigate or functionally manipulate through a series of selections and wand-controlled gestures.

We developed our application under the Microsoft XNA framework with the Goblin XNA package. The application is targeted at Nokia Lumia 920 with some additional use of NyARToolKit marker arrays for optical tracking. The user will wear a Nokia Lumia 920 in a stereoscopic viewer attached to their head so both of their hands will be free. One NyARToolKit marker array is used as ground pattern, one is used as virtual hand, and another is used to display menu items. Watch this brief demo to understand the big picture for this project:

Cue Array

A toolbar array will control the trajectory of the projectile beam in the scene. The user is able to freely move this cue array around the scene and consequently the attached shooting wand. By flipping the wand around, the user is given access to an array of menu items in the menu array (see 2). By activating rotation or scaling mode in the menu array and then flipping the wand over to return to the cue array, the toolbar becomes a selection tool with which to select the scene by physically colliding the wand model with the objects in the scene. The cue array and the attached wand then becomes a means of control for rotation or scaling purposes.

Menu Array

The menu array is located on the back of the cue array and acts as a quick means of accessing functions in the scene. Attached to the menu array are four options to rotate or scale the scene, reset the current level to its original scaling and rotation or restart the game entirely.

Ground Array

The ground array defines the scene in which all of the game objects are placed, as well as the area within which the wand attached to the cue array is meant to function.

Selection and Manipulation

We used a “wand” for selection and manipulation. The wand itself shoots a constant stream of particles, which can collide with objects in the scene. In this way, we are using a pointing technique, which was inspired by the related ray cast and pick-to-select paradigm, which dates back to Roberts’ Lincoln Wand (1966). We have no “picking” in our implementation. It always occurs via a collision based on pointing the wand at a particular object. 

We started with the plan of using a two handed selection technique, where the left hand did the pointing and the right hand essentially did the “picking” or clutching, which shot the ball. 

We found that this was redundant to the function of the laser, and that we didn’t need both a ball and a laser. The laser bounces when it hits any object, so it managed to achieve a similar effect. 

As professor Feiner explained in his lecture, the advantages of pointing in this manner are that this allows easy selection/manipulation beyond the user’s reach, and this also requires less physical movement than the virtual hand, because you do not have to move your arms much to make a pointer intersect with the target object. A large drawback of this method is that it is hard to position objects except radially around the user, and it is also difficult to rotate objects other than around a point vector (Vickers, 1972).  Picking in this way allows selection/manipulation beyond the user’s reach and requires significantly less physical movement than the virtual hand.

WayFinding

We began our project by considering the use of an arrow that would track the movement of the ball so the player would always know where it was located. 

After trying to implement this version of Arrow Radar we realized that it would be clearer to simply have a cone in the center of the game-board that was always pointing at the ball. That way it wouldn’t take up a large part of your field of view and it would be easy to follow the action no matter what the player’s level of zoom. 

This is a simulation of an improved interaction technique that uses the cue to select items, and makes the wayfinding clearer: 

After discussing the issue with Carmine, we decided that the center cone was really unnecessary, because the player would always have full view of the playing area, and the cone would simply be pointing at something that would already be in view. If a ball bounced out of bounds, it wouldn’t matter, because the level would be reset anyway. Keeping track of it was rendered irrelevant in the process. Moreover, we decided to drop the ball concept altogether and use a laser instead (the reasons for that decision are explained below).  

The laser both functions to show the player what direction their wand is pointing, along with the intended trajectory of any ball launched from the wand. As a continuous laser beam, this simply allows the player to move the wand in an attempt to line up their shot, acting both as a wayfinding tool and as a main game mechanic for shot selection and completion of a level. When the wand is lined up correctly, the player will see the laser bounce between the panels, and through the goal hoop, thereby winning the level.

The borders on the ground plane act to help to show the depth of the playing area. This grid feature in and of itself greatly adds to a player’s sense of depth orientation and sense of position within 3-D space (Darken & Petersen, 2001).

Travel

I. Walk Around to Change Angle

The user can walk around the ground array while continuing to look at it. This allows them to walk around the game-board and see it from different angles.

II. Rotate and Zoom the Game-Board

In various situations, seeing from the point of view of the ball would be convenient, as when you sight down a pool cue or look at shot in golf from close to the ground. Instead of moving your body and head into position, which could be awkward at times, you could simply rotate the game-board. The system also allows scale (which is really “dolly” -- the camera moves forward toward the center of the level).

Rotation will be possible over the X, Y, and Z axes. See Kevin Lin’s video explanations below:

The user enters rotate mode through the menu system and this is initiated by selecting the axis of rotation from an array of virtual buttons and moving your cue marker to the right or left to modulate the speed of rotation. Moving to the right of center will increase the rotation speed relative to the distance from the center or null point. The object will rotate in the opposite direction if the player moves their cue left of center. Rotation and zoom buttons placed on an easily accessible menu array located on the opposite side of the cue array. The quick action of flipping the wand around will bring the menu array into view of the scene and a list of functions will appear on the array.  A reset button will also be present on the menu array to move back to the default rotation and zoom.     

Here is an example of an early scaling implementation (our game features isotropic scaling, unlike this demo that shows anisotropic scaling): 

Our current implementation of scaling follows nearly identically, with the only difference being that scaling occurs uniformly along all axes.

System Conformity to Heuristic Goals

Visibility of system status

The current game level is always displayed in the top left hand corner of the screen as each level begins. When a menu item is selected with the wand, the menu populates with a new list of options (a submenu) with the mode selected by the option displayed at the top of the list.

When a specific manipulation function has been selected, instructional text appears at the bottom of the screen in order to both indicate the selection of the mode as well as guide the user in carrying out the functionality. When contact occurs between the laser and the panels, the player will hear a collision sound - indicating that they are in fact pointed in the right direction and that they have made contact with a game object. When the player successfully lines up their shot with the laser, positioning the laser so that it bounces through the torus, the player will see a laser beam that passes between all of the game-level panels, and they will hear a sound indicating that they have solved the level. 

Winning a level will bring up a prompt in the form of a rotating box that tells the player that they have won and are moving onto the next level. The box will instruct the user to hit it in order to advance to the next level.

Match between system and the real world

To manipulate the scene, the player selects “Rotate” or “Scale” from the menu. These are generic, common terms that should not be confusing to the average player. Once a mode has been selected, the player is given the option to “save“ their transformation or “cancel” it. The menu also offers “Reset Level” and “Restart Game” -- the level reset brings the player back to the initial orientation and scale of the level. Restart game take the player back to the first level and starts the game over.  

The wand behaves like a laser pointer, in that the laser goes in the direction a player would expect - our system does not have gravity, so our physics is based only around the angle of incidence equaling the angle of reflection - we are used to seeing light reflected in this way. Once we decided to use simple collisions (angle of incidence = angle of reflection), we decided to forgo gravity. Following that decision, we decided that using a “ball” which would normally have weight and move in a parabolic fashion, didn’t make sense because it would be too difficult to aim. Instead, we used a laser beam which bounces with the simpler geometry we had in mind. 

Moreover, this system rewards the player who may already have been familiar with the games of pool or miniature golf - their intuitive sense of how a ball bounces off of an angular surface will be preserved. This is like a game of pool where the balls never slow down due to friction, and where you can see the entire trajectory as you line up your shot, rather than requiring the mental visualization of a typical analogue pool game.  

User control and freedom

When the menu is activated, the user is presented with options to reset the current level or to restart the entire game.  If the player has activated a submenu, which can be accessed by selecting Rotate, Scale, Reset Level, or Restart Game, they will be presented with a confirm option or a cancel option. This allows the player to easily undo any rotation or scale - any change the player did not intentionally make. Reset Level has the same effect as Reset Scale and Reset Rotate - it simply provides a quick way to reset both the scale and rotation and thus return to the initial configuration. Restart Game, when selected, offers the user a Confirm or Cancel option. 

Consistency and standards

Initially, we created icons to represent menu select, rotate, reset, and scale: 

Mock-up with onscreen icons. We decided that this would not work given that our stereoscopic viewer has limited screen space.

When we started implementing the menus, and integrated commands like Reset Level, and Restart Game, and we decided that switching to plain english commands made more sense, rather than creating icons for all of our operations or using a combination of text and icons. 

This decision was made in an effort to create a consistent user interface that would be simple to understand.

Error prevention

For menu selection, we use a technique where the player blocks a marker to indicate selection. When we started implementing this, we were updating the menu and checking for selection every frame (15-30 times per second). In this time frame, the player would select something in the main menu, then the system would activate the appropriate submenu, and the player would inadvertently select an item in the submenu. 1/15 of a second is too fast enough for a person to move their thumb out of the way.

To eliminate this error-prone condition where menu selections were made accidentally, we modified our selection technique. In the early version, the item was considered selected as soon as the system lost tracking of the appropriate marker. In the new version, the item is considered selected when the system loses tracking of one of the markers and then regains tracking of all four. This means that the player has had time to move their finger out of the way and the submenu is now available for selection. 

Our initial game design had the player lining up the shot with a laser sight and then, once satisfied with its placement, shooting a ball at the same angle. However, when the user performed the cue action that shot the ball, they almost always shifted their position and/or angle slightly. This meant that the user could successfully solve the level and then fail because of a small mechanical error. To prevent this error, we got rid of the ball entirely. Now the level is considered solved when the user successfully lines up the laser.

Recognition rather than recall

Our system uses one main menu. When the menu is active, the user sees four options: “Rotate”, “Scale”, “Reset Level”, and “Restart Game”. All of the user’s options are presented. In a submenu, the user does not need to remember any information. They can choose to save their transformation or discard it. At any time, the user can move the menu off-screen (by translating the cue out of the scene or by flipping it over). When the menu comes back on screen, it will always return to the main menu and display all options again.

Flexibility and efficiency of use

The instructions we give to a novice user will allow them to reset their transformations one at a time. To return to the initial configuration of the level, a novice would go to the main menu, select “Rotate”, and select “Reset”. The main menu would then appear again. The novice would then select “Scale” and “Reset”. These actions would successfully return the level to its initial state, but the process involves four selections and the use of two submenus. Alternatively, an advanced user could use “Reset Level” and select “Confirm”. This performs the same action using only two selections and one submenu.

The simplest way to exit the menu is to lower the wand so that it is out of the camera’s field of view. This same action can also be used to deactivate the laser when in “shoot” mode. A novice user could learn this one motion and use it in both modes. A more advanced user could exit the menu by flipping the wand over. This reduces the amount of time necessary to bring the menu back up again. This is in accordance with Fitts’ Law: the target area is the same but the distance to move is much smaller if the wand is still in the scene (Fitts, 1954). Flipping the wand would also have the effect of starting the laser pointer. If this was not desired, the user could turn the wand 90 degrees to either side. There are no markers on the sides of the wand, so this would cause both the laser and the menus to disappear. Another benefit of the flipping-the-wand method is that it allows the user to use their more fine-tuned wrist and hand muscles as opposed to their upper arm and shoulder muscles.