Space Game video on the way

The game uses WiiGlove P1.2 and the XNA game development framework.

As such we will not be able to comply with the test date of the 19th. I suggest a 2 week shift to the 3rd of March.

With that in mind I would opt for the 19^th to allow for a safe period (see how it behaves) to cover any possible issues that might arise with the integration of the electronics etc.

1. Merging of the games into a singular package for deployment.
   • Currently each is stand alone
2.  Definition of the Calibration interactions (game 3) to reflect a similar approach as used in WiiFit detailing. These interactions will also enable a wider range of users to utilize the games:�
   • Rotation capability of the user
   • Translation capability of the user
   • Pinch capability of the user
   • Users hand span
3. Definition of data capture requirements to reflect the above(2) in addition to those already defined.
   • It was also suggested that only duration of use needed to be captured rather than a full time stamp. Please could this point be clarified
4. Identification of additional data capture requirements to be implemented for the Falcon suite of games, reflecting those developed for the glove.
5. Expert user/tutor facilities for data extraction and review:
   • Investigate feasibility for user/tutor customizations e.g. speed
   • One click save system for data (tutor) extraction/convenience.
6. Definite need for Wiimote attachment stands.
7. Production of iterated 3D printed gloves for the first round of user feedback.
   • With the key functional/technological aspects of the  glove concept now tied down application of user input is required to ensure that the PDS is fit for purpose etc.

The final selection for the games to be developed are:

1. Archery concept
2. Spaceship concept
3. Calibration interaction
4. Bubble Grab

The following decisions were developed/tied down for the Spaceship Game:

1. Automatic increment of levels reflected by a speed increase.
2. Game over is triggered via registration of  a defined volume of collisions.
3. Severity of each collision event is to also be captured.
4. Collision does not pause the game and is indicated via a visual response.
5. The course is to be created randomly each time (no requirement for tutor defined courses)

The following decisions were developed/tied down for the Archery Game:

1. Target needs to be much bigger
2. Level increments are detailed via the increase of distance to the target
3. There is a need for an overall reduction of the targeting interference.

The following decisions were developed for the Calibration Interaction:

1. The Calibration Interaction is optionally available via a “Training” button which is to be included to the main menu.
2. Calibration data needs to be stored between sessions.
3. The user should have access to the data so that they can conduct personal review.
4. The user should have access to each of the individual training elements (list 1 pt 2 a-d) so that they are not forced to calibrate each aspect if not required.

Currently I have nearly finished the implementation of the Spaceship and Archery concepts as demoed last week and am in the process of merging the two together with the Calibration interaction as detailed in list 1.

Provision for the Bubble Grab game is also being dealt with as part of this process. This means that the first 3 games are on target for a January release to coincide with the installation of our 3D printer for rapid prototyping of the glove iterations.

Variables we need for analysis

1. Total time playing games = sum of all sessions
2. Distribution of sessions ie how closely they followed recommendation = plot of session frequency and length
3. We can also look into whether they were improving in their scores, using all games and progressing through levels but this may be descriptive rather than quantitative.

File shows the record for participant number 1 who was allocated to falcon (device 1) group. They logged on first when the therapist was there on 16 March 2010 and started playing first game at level 1. They did this for 4 minutes hitting with the hammer 14 times but getting a score of 12. They then went almost immediately into level 2 and spent 4 minutes on this getting a score of 11 but hitting hammer 17 times. Then they tried second game at level 1and spent 6 minutes getting score of 3 but pushed 5 times in all (2 of these were unsuccessful). They had a second go at this game at same level only spending 2 minutes but were more successful with a score of 4 from 5 push attempts.

Total play time = 16 minutes

The therapist then left but the participant logged on again at 12.10 playing the second game at level 1. They had four consecutive goes at that level before they quitted.

Total play time = 10 minutes

They didn’t switch on again that day but did the following day (17 March) starting to play the first game at level 1.

Might not need attempt variable : is it unnecessary and a bit confusing?

In this concept the Users hand represents a ship moving in 3D space. As the user moves their hand in the XY planes the ship responds accordingly. Rotation of the hand is also used to bank the ship. 

Movement in the Z plane or extension/contraction of the finger span can be used to control ship speed depending upon user ability.

Levels

The level consists of a defined course that the user has to navigate along. Each course has 10 obstacles that the user has to navigate through via XY movement and rotation of the hand. 

An obstacle consists of a block with a hole cut through it at a set rotation. Collision with an obstacle resets the ship to the position of the last obstacle navigated.

Score

Score is derived via the period taken to complete the course.

Data

The concept provides large volumes of available data, some of them are: 

• Movement in the XYZ planes
• Finger span
• Number of collisions
• Period taken
• Maximum rotation +/-
• Rotation Period

Feedback

The User has access to the time taken for each level and an overall time which can be used to derive a grade (Gold, Silver and Bronze).

Skill

This concept can have skill settings that define the distance apart and rotation angles needed to navigate through each obstacle. A health variable could be used that decrements upon each collision. 5 collisions results in a fail and the course is not completed.

This Concept document is available in .PDF format here.

The user has to move the hand in the X and Y plane to line up with a moving object. The user then has to grab the object via movement in the Z plane and a corresponding pinch action of the correct span to encase the object.

Levels

A level is described by a period taken to grab 9 objects at 3 different sizes (Small, Medium and Large) that float up from the bottom of the screen.

A missed object is re spawned and the user can try to grab it once more.

Score

Score is derived via the period taken to complete the course. And the number of missed balloon/bubbles/balls – objects

Data

The concept provides large volumes of available data, some of them are: 

• Maximum pinch span
• Minimum pinch span
• Movement in the XYZ planes
• Period taken
• Number of misses

Feedback

The User has access to the time taken for each level and the number of missed objects which can be used to derive a grade (Gold, Silver and Bronze).

Skill

Size parameters can be used to customise the application to a user. These can be changed over time to increase difficulty or be used to define level progression.

This Concept document is available in .PDF format here.

The user has to move the hand in the X and Y plane to line up with a peg. The user then has to move in the Z plane and use a pinching action to grab the peg. The user then has to move in the XY planes in order to reposition the peg in a desired location.

Placement is derived via the release of the pinch action.

Levels

The game consists of 2 levels each with a described task:

• Removing the pegs from the board
• Replacing the pegs in the board 

Level is incremented via the successful completion of the current level task. Incorrect placement of a peg resets it to its starting position.

Score

Score is detailed as the period taken to perform the level task.

Data

The concept provides large volumes of available data, some of them are:

• Order of placement
• Period for each level task
• Overall Period
• Total incorrect placements/peg drops 

Feedback

The User has access to their time for each level and an overall time which can be used to derive a grade (Gold, Silver, Bronze).

Skill

Good XY control is needed to successfully navigate pegs that are already in the board. Rotation could be included to increase difficulty of placement.

This Posting is also avaliable in PDF format here.

Description of User Movement

User moves hand forward and then uses a pinching action to load an arrow. Force is applied to the arrow either by moving the hand backwards or via the period the pinch is held depending upon the user’s ability.

Once primed, the arrow can be aimed at the target via movement in the X and Y planes. The arrow is fired via the releasing of the pinch.

Levels

There are 3 levels in total which increment via a distance of 5M.

Each level consists of 3 shots at the target at its described distance. Upon completion the level is incremented and the user target distance is incremented. This results in a combination of a greater force and finer movement needed as the levels progress.

Score

Performance is derived via location of the arrow on the target. A maximum score of 90 is available via 9 direct hits over 3 levels at 30 available points each. A minimum score for each level could be used to unlock the next level.

Data

The concept provides large volumes of available data, some of them are:

• Distance moved in the XYZ planes.
• Pinch period.
• Pinch distance.
• Shot period.
• Accuracy.
• User Score.

Feedback

The User has access to their score for each level and an overall score which can be used to derive an overall grade (Gold, Silver, Bronze).

Skill

Each shot could be expanded upon to include additional variables such as gravity and wind direction to both increase difficulty and add more of a game-play element to the concept.

This Posting is also avaliable in PDF format here.

A low cost rehabilitation glove using the capacity of the Infrared Receiver on Nintendo’s Wiimote to pick up the signal from four diodes placed at the patient’s fingertips. This compensates for the inability of previous low cost solutions to track fine motor skills. Four diodes per glove are used as it is only possible to track that number of separate Infrared Signals per Wiimote

If you all have any comments/ requirements please just send me a mail at my NTU address and ill look into them etc.