MOTION INPUT GAMING.

Problem in this MFC: As shown above, the UI for general gaming is very cluttered and naming of control options are not clear enough to be intuitive to any non-technical user (for example, HotKey Mapping). This might hinder users to correctly configure their games, hence resulting in them not running in the desired control settings.

Our solution: Ensure the layout and options of our MFC application are clear[1]. That is, there is sufficient space between each control options and that they are appropriately named.

A feature we will implement: there is an information button ¡ next to each option that details what it entails. We will include such information buttons in our user interfaces to support non-technical users.

Problem in this MFC: In order to add keybinds, a secondary dialog box is provided upon clicking the button "Configure Mapping" of Speech Hotkeys. This demands too much technical know how from users who have to figure the keybind of the game they want to play and then select their desired speech command. This is not at all feasible for users who would have to do this process for each game they want to play. Also, games provide a lot of controls which is why inputting each control is troublesome.

Our solution: All the speech keybinds for each game should be determined and stored by default in separate JSON files. The user should be able to choose bodypoints from a list through our user interface and not input each one of them manually.

Problem in this MFC: Similarly, "Configure Mapping" for Gesture/Pose Hotkeys can be confusing for users. Also, certain gestures may not work well with certain games. This means the user would have to spend a lot of time doing trial and error with different gestures before they figure out which gesture is compatible with the game.

Our solution: We will test out different gestures for different in-game actions to determine which ones to implement. This will be stored in a JSON file.[2]

A feature we will implement: We will implement both speech and gestures for in-game controls in addition to virtual buttons.

Problem in this MFC: To play the same game in different mode, the user has to choose the game from a dropdown. For example, if the user wants to play FIFA, there are two modes listed in load game dropdown: "fifa" and "fifa_standing". However, this makes the drop down repititve and quite long. "fifa_standing" is also a confusing name.

Our solution: We will have an option for users to choose between steering and joystick mode for driving games, but instead of having them in a drop-down menu, we would have them as "STEERING" and "JOYSTICK" radio buttons.[3]

Problem in this MFC: To load a new game that is not present in the dropdown, there is a button provided with which the user can provide the directory where the new game json is located. This is weak structuring of the game json files.

Our solution: For our General Driving Games and General 2D Side Scroller Games MFC applications, game JSON files will be in a pre-defined directory (data/modes/driving_games or data/modes/2d_side_scroller_games). Adding a new game would only require adding its corresponding JSON files into these folders. Then, the new game should automatically appear in the drop down.