Software Design Concerns

Assuming start with the Unity Application Design and adjust as needed to support Boccia. This design resolves the MindTV problems we had (sharing data through a model, peristence).

Outstanding items

User interface technology

One detail that still needs to be resolved is how the user interface of the Boccia application will be implemented (buttons, menus, etc, not the 3D ramp visualization). The Unity’s UI Toolkit is better suited to user interfaces, but there is a learning curve. The older Unity UI is much more clunky to work with, but is probably more familiar to the average Unity developer.

• Talking with Eli Kinney-Lang, we think using Unity UI is a better choice. This plays to the strengths of the team we have.

User interface design for Bessy integration

Bessy Unity interacts with GameObject components called SPOs. The SPO emits events that can be hooked to other GameObject components, ex: a “manager” component. This design can be used pretty much as is if we’re to use Unity UI for the user interface, or at least the UI elements that control the Boccia ramp.

The existing Bessy Unity design is coupled to user interface concerns, and perhaps it shouldn’t be. The BCIController → SPO communication could be simplified to just events with IDs. That way any object could be an “SPO”, and receive events. See: BCI Essentials - BCI System.

• We’re going to use Unity UI, so this is less of an issue. We can probably use Bessy Unity as is.

Physical ramp integration

This seems pretty straightforward. The old Boccia application has a CommandController class that can be pulled over (https://github.com/kirtonBCIlab/bci-boccia). This controller can interface with the Model like any other peripheral function, ie: receive model change events, call model functions to change state.

To better prepare for two way comms, it might be better to have the model rely on a RampController object. RampController provides methods to control the ramp, properties for the state of the ramp and a changed event to update the model. Use two specializations: SimulatedRamp and a HardwareRamp. Both implement the same interface, but the SimulatedRamp just pretends to rotate (etc) whereas the HardwareRamp communicates to/from the real ramp.

Data model

This isn’t a problem, it just needs to be specced out once we’re sure about what the UI needs. Spike here: Data model