P19002: Game Based Prosthetic Hand Trainer
/public/

Systems Design

Table of Contents

Team Vision for System-Level Design Phase

Due to the major amount of concern the team had with the documentational risk caused by the extremely decouple-able components of the systems and subsystems of this project, the primary goal the team had set for this phase was to break down the many parts into their core components to further clarify our basic systems level design for this project. Due to the inherently game-specific requirements for software systems needed, it was necessary to decouple the core engineering requirements from the user experience requirements of this project. Namely, the choice of what sort of game we would make was decoupled from how the individual subsystem implementations would be selected. The design of the individual subsystems was delegated to the detailed design phase to make time to finalize the type of game we would focus on initially to allow us to have a concept which can be further clarified in future phases.

To do this, the team focused first on identifying good ideas within different game genres that we could use to identify high potential topics to focus on to constrain our design space and allow more efficient use of our time. Following this, the morphological chart was divided into game and core morph charts to account for the above circumstances and the Pugh concept selection focused on game concept selection as we took it to be one of the design elements preventing further clarifications of our design's system-level requirements.

Benchmarking

Due to the relative novelty of this sort of technology, in particular in the intended setting, it was difficult to identify reasonably equivalent technologies. It seemed better to compare individual components and implementations with other games' subsystems, including some simple "games" often used in typical physical therapy, at the detailed design phase. As such, to provide a point of comparison for our design improving on the existing circumstances, the virtual reality pose matching simulation was used as the datum upon which other designs were compared. Assumptions were made regarding the expected behaviors and requirements of the VR system as compared to other concepts due to minimal information on the design and physical application of the VR benchmark system.

Purpose

For the purpose of narrowing down reasonable solutions to the customer's request, we collected information on various genres and identified their pros and cons. We neglected other game design types to constrain our design due to the sheer number of possible game concepts. In doing so, we reduced our design space significantly.

The current "best case solution" used by the customer was an in-lab, virtual reality, pose matching simulation system. Virtual reality today still requires very high end PCs or specific mobile or console systems. This system is also only available in the lab and not usable outside of the lab. To assuage this issue, the customer requested a game which could be taken home, engage the user, track their progress, and allow them access to virtual therapy when they need or want it rather than having to wait to go to the lab to practice using their prostheses.

Inputs and Source

In seeking out more information on our target audience, we found that there were several VA Medical centers nearby, some of which having amputee clinics. We plan to reach out to these groups in the near future for user feedback and perspectives. We have also been connecting with individuals with a vested interest in amputee quality of life who may be able to serve as a third party for communicating with game-interested amputees nearby.

Output and Destination

The following were used as criteria for selection of methods of implementation of the project:

We would also like to add agreement of project sponsor to this list; that is, we'd like the sponsor to approve of our selected solution. Since games are hard to judge before completion of core functionality, it was deemed more important that base functionality be met but sponsor support for the concept in mind would be preferable if possible.

Functional Decomposition

The following diagram displays a systems-level breakdown of potential game-required functionality.
Functional Decomposition Diagram

Functional Decomposition Diagram

Concept Development

Purpose

The goal of this stage was to generate new concept options or combinations that can potentially exceed the benchmark concepts. This section covers our ideation on genre and game concept selection. Core functionality has been delegated to future detailed design due to the nature of the design needed.

Genres considered

To constrain our design space, some varied genres were selected to allow more directed design of game concepts. The general consensus was that automation of motion would reduce potential accumulated numerical errors from user action error and prevent the game becoming unplayable.

The genres considered were:

Feasibility Analysis of Concepts Considered

Purpose

Due to the restricted nature of many of the base functionality components associated with latency requirements and other quantitative measures, as well as the need to have a prototype before playtesting can be performed, most of the analysis of performance has been relegated to detailed design and to the iterative development process as we implement game concepts and test them.
Usability Test Plan: Skeleton
Testing many of the Engineering requirements will be fairly straightforward and doable with a few minutes of extra work. The usability, on the other hand, will require playtesting or usability testing, without provided bias, to identify quirks or issues in our user interface design and presentation. In the game industry, it is typical that this is performed via survey, post-experience of the system in question. This can be made more efficient by dividing irrelevant systems for parallel usability testing such as general UI as opposed to game interaction controls.

Genre Pro/Con

Racing
Platforming
Sh'mup / Action
Rhythm
Puzzle
Idle

Morphological Chart and Concept Selection

Game Morphological Chart

Game Morphological Chart

Game Morphological Chart

Core Functionality Morphological Chart

Core Functionality Morphological Chart

Core Functionality Morphological Chart

Purpose

Details of Morphological Charts

Potential Performance Metrics Considered

Potential Performance Metrics Considered

The goal of this step of the systems-level design was to establish concepts to compare and contrast on their quality of solution to the customer's problem. This was done via two morphological charts used slightly differently than originally intended. The first chart created was the game morph chart, which describes some more game-specific (note: NOT genre-specific, detailed design) components which served as a basis for discussion of implemented solution ideas in the game space. Due to the inherent decouple-ability of the components of the software, it was unnecessary to compare combinations of the solutions presented as we felt this was more of a detailed design aspect due to each component having different inherent requirements and design decisions associated with its implementations. The second morphological chart created was the core component morph chart. Notably, this chart was also easily decouple-able and hence the solution space was likewise far too broad to do single combinations of solutions in a sensible or reasonable manner. This was also deemed an inappropriate step at the systems level design phase. Regardless, both documents served to help clarify what our potential solution space was for each topic of interest. There were also a few items from which it was deemed possible that some or several solutions may be simultaneously chosen for any given implementation due to the nature of the project as being driven by player performance which depends on robust performance metrics.

Inputs and Source

Project Objectives
The basic requirements we had to meet for this project were to build a system with the following properties:
Engineering Requirements and Decomposition of Functions
Engineering Requirements Matrix

Engineering Requirements Matrix

Refer: Functional Decomposition

Outputs and Destination

Concept Selection

Game Type Pugh Analytical Concept Clarification and Selection

Game Type Pugh Analytical Concept Clarification and Selection

Systems Architecture

Software Architectural Breakdown

Software Architectural Breakdown

Risk Assessment

We are in need of notes regarding the PT process and the current VR training system's use process and user experiences with the tool to inform future design decisions. To ensure we are accounting for the maximal patient benefit, it is of the utmost importance that we be informed on the current patient recovery / training process so as to best inform the required therapeutic / training elements to include in the game. This is considered a high priority risk with a dependence on our client to get us this information. In the event of inability to acquire this information, we will endeavor to communicate with nearby amputee centers regarding typical recovery processes and lifetimes. Our living risk management document can be found here: LINK

Design Review Materials

For this current stage all required materials may be found on this page.

Plans for next phase

From an interpersonal perspective, for our team to be at its best, we want to further work on our team dynamics but we also want to further dig into each of the individual topics of our design (that is, all of the smaller subsystems delegated to detailed design). By our next phase, we would like to have more detailed analysis of the individual components specific to our game designs of interest for continuation. We would also like to establish a running timeline of expected deadlines for functionality of certain component or system designs. The first step in doing this will be delegating individual subsystem designs amongst the team.

Home | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Customer Handoff & Final Project Documentation