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.
BenchmarkingDue 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.
PurposeFor 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
- Project Objective
- To make this game user preference agnostic from the perspective of preferred game consoles, since it was deemed more reasonable that the patients using this training tool would have access to a middle-of-the-road PC and mobile development was deemed out of scope due to the number of potential user platforms we would need to consider. The game also needed to account for the degrees of freedom (DoFs) of the user's prosthesis and be reasonably modular enough to add and remove DoFs as needed or to manage game difficulty as the customer mentioned that patients have had particular difficulty managing multiple simultaneous DoFs (around 4 can be hard).
- Project Objective
- Functional Decomposition
- Case Western Reserve University
- Cleveland Veterans Association Medical Center
- Physical Therapists / Orthopedic Specialists
- Friends and associates
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:
- Quick to test
- Quick to run
- Don't need many peripherals
- Range of motion capability and # of DoFs usable
- User wants to play often
- Low Asset Size (audio, artwork, software, stored data...)
- User Experience is comprehensible and intuitive for the target audience (30-50 year old single arm amputees)
- User Interface is simple and straightforward to use
- Can be implemented in the allotted time frame
- Low / no cost requirement
- Easy to parallelize
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 DecompositionThe following diagram displays a systems-level breakdown of potential game-required functionality.
PurposeThe 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 consideredTo 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:
- Sh'mup / Action
Feasibility Analysis of Concepts Considered
PurposeDue 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: SkeletonTesting 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.
- Analogs to movements may be easy to identify / may feel more natural depending on implementation
- Difficult produce enough DoFs that are comprehensible and usable for this application
- Must create some sort of wheel physics, or use pre-built wheel physics, or "Fake" it
- May need to add additional mechanics, complicating the racing component, or creating design clutter and risking confusing the player
- Need to create tracks for each race (need a variety to keep it feeling new) / one race (boring) or create a procedural track generation system (most of these in modern racing games are not popular)
- Not hard to make base components
- Design is clean and straightforward
- May be difficult to integrate arm velocity control
- Similarly to the racing game, this may require miscellaneous mechanics to handle other DoFs due to the need to handle as many of these as possible
Sh'mup / Action
- Relative ease of level creation
- Effective if motion is mostly automatic
- Easy difficulty scaling (refer: Touhou series or other "bullet hell" games)
- Many of the Patients enjoy CoD so they may be more likely to enjoy this due to the excitement typically associated with the genre
- May require fast reflexes for high difficulties
- May require high complexity of actions, similar to platformer and racing games
- To increase difficulty may require complex AI maneuvering or motion patterns, thus increasing overhead
- Extreme ease of adding DoFs
- Repetitive actions conducive to PT-like actions
- The systems required for a rhythm game are relatively straightforward and mostly consistent between games -- Notably this means, to avoid copyright disputes, the design presentation of the game must be carefully considered to prevent too much overlap with existing games
- Unity has built-in rhythm analysis tools
- May be easy to create analogous-looking/feeling control interfaces in-game to the behaviors outside the game
- Replayable gameplay, player would want to return to certain songs to try and improve their previous score
- Relative ease of Level creation
- Level creation will either require design of a complex audio analysis subsystem which has high potential for bugs and inaccuracies and may have limited difficulty scalability, however this can be assuaged by managing the speed of songs and number of DoFs used or alternatively making the game music entirely procedural instead of using music analysis
- Level creation, if not automated, may require manual level generation which will be very time consuming but not significant when compared to the design debt the other genres will incur
- May require allowing custom songs to prevent boredom or creating reasonably variable preset procedural pieces
- Requires music or sound effects to be of base functionality
- Beat Detection algorithms are notoriously inaccurate
- Allowing the use of custom songs requires either
preloading (load before start) or asynchronous
loading (loading while playing). The former takes a
long time, the latter can experience issues in the
- Frame rate drop (music continues to play because of OS behavior)
- Reduction in accuracy due to limited parallel processing time without noticeable graphics slowdown
- POTENTIAL SOLUTION: Make a separate application for beat processing from the game that generates beatmaps. Online or desktop.
- May require complex movements resulting of combinations of DoFs making solving the puzzles potentially able to account for many types of motion even in simpler puzzles (it could depend on implementation)
- Does not require speed (or it could depending on implementation) to work
- Could have game modes that require speed, eg a timed mode
- Complexity of Actions may result in difficulty to perform actions
- According to Matt's prior feedback, many of the amputees enjoy CoD so they probably prefer something more active
- Simple to Implement and add to
- Easy to make player want to keep coming back in their free time
- Player engagement is very easy to measure
- Most game additions will be easy to manage and there will be a low barrier to testing
- Must be balanced appropriately to prevent boredom, extreme unfairness in difficulty, or overt easiness of gameplay
- Hallmark to idle games are low user interaction to high in-game outputs which may not encourage active participation without inclusion of complex player engagement management systems, thus increasing development overhead
- Replayability depends on implementation and addition of DoFs may complicate gameplay unnecessarily
Morphological Chart and Concept Selection
Game Morphological Chart
Core Functionality Morphological Chart
Details of Morphological Charts
Inputs and Source
Project ObjectivesThe basic requirements we had to meet for this project were to build a system with the following properties:
- Game is simple to set up
- Game is take-home-capable
- Doesn't require advanced equipment or knowledge
- Runs on a middle-of-the-road PC)
- Rich Playability
- This is a non-functional requirement, much in line with the suggestions presented by Fan.
- Responds to improved performance w/ increased difficulty and allows a maximum performance of 80% subject to the performance metrics used
- Data logging with communication to a secure server of at least a day's worth of data
- Wireless Interface (this is partially handled for us
through the Hub)
- Interface was pre-defined as bluetooth low energy
Engineering Requirements and Decomposition of FunctionsFunctional Decomposition
Outputs and Destination
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