System Architecture Design

Our goal is to integrate Motion Input with Action and Adventure games by create accessibility consoles for games using the Visual C++ MFC Framework. We will be referring to our MFC Application User Interface as MFC.

Our System Architecture is explained as follows:

As each game has its unique key bindings, our team first created .json files for each game. These files contains an array called “poses”, which has information about the key bindings of each virtual button as well as its position, skin (appearance) and landmark (which bodypoint,i.e. hands or elbows, to use to trigger it). It also contains gestures and speech commands. Each game has multiple JSON files. The file used depends on the method of control selected by the user. For instance, for Rocket League, there are rocket_league_steering.json and rocket_league_joystick.json among others.



Upon launch of the MFC Application, two files are modified: "configMFC" and the respective ".json," according to the user's customization. Display and speech settings are written to configMFC. Depending on the method of control chosen by the user, e.g. steering, the value of the “mode” key changes to the corresponding JSON file. The "mode.json" file is responsible for the body points used. The “landmark” values are changed according to the user’s preference. Subsequently, the modified "configMFC" file is duplicated into "config.json" as a safety measure, given the the Motion Input system greatly relies on config.json. Finally, Motion Input is launched with the user's customised settings. This process is shown in a diagram below:


Sequence Diagram

The following diagram illustrates in more detail what happens when our MFC applications are used.



1. The user launches our MFC application.

2. From config.json, our MFC retrieves information such as which mode (game) JSON was last in use and display settings.

3. From the mode json, our MFC retrieves settings such as last used bodypoints.

4. The settings retrieved are selected by default on the MFC.

5. User may further customise settings or change settings, including driving method of control (for driving games) or position of on-screen triggers (left or right).

6. When the user clicks launch, the current settings are written into the mode JSON file as well as the configMFC JSON file.

7. configMFC is copied into config.json.

8. Motion Input is launched with the new settings.

Design Goals

Our main consideration for developing our new system architectures and design are as follows:

Extendability and Modularity:

Each game has JSON files corresponding to each method of control. New methods of control can be added easily by constructing a new JSON file. Changes in any of these files would not affect the others.

Our general driving and general 2D side scroller MFCs allows new games to be added to the drop down menu just by adding JSON files in the modes directory.

Single Responsibility Principle:

Each JSON file is responsible for only one game and one method of control.

Our General MFCs are responsible for only one type of games, namely driving or 2D side scroller, to avoid confusion.

Our game-specific MFCs are responsible for one game only.

User-friendly:

Our MFCs retrieve the user's previous settings, making the process of launching Motion Input much more convenient.

We simplified user choices by using radio buttons for different options in our MFCs ensures clarity.

The help and information buttons on our MFCs provide explanation for each option, guiding first-time users.

Configurability:

Non-technical users can configure Motion Input easily through our intuitive MFCs.

Position of buttons, gestures and speech commands can be edited or added in the JSON files.