Team Status Report 2/15

This week we have been doing more parts selection and research as well as designing the schematics for the module-arduino connections, CAD designs for modules and control panels, and making progress on working on the game. We have also been working on the design presentation.

The answers to week-specific questions are included at the end of the report.

Significant Risks

One significant risk to our project is managing the latency of the controls. If the latency of the signal between the modules, Arduino, and Unity game is too high, the experience will not be enjoyable for the user. This risk is being managed by researching various ways to reduce latency. For example, we are using electronic components that will not require a handshake to communicate with the Arduino (potentiometers, buttons, encoders). We’re also exploring software solutions, such as using interrupts to detect button presses instead of polling, which allows us to react to a button press immediately instead of having to wait. A contingency plan is to slightly alter the gameplay to allow for higher latency without degrading the gameplay experience. For instance, we could slow down the movement speed of the submarine or the enemies to give players more time to react.

Design Changes

After receiving feedback from our proposal presentation, we changed our metric for our game enjoyability to 80% survey ratings instead of 85%. This was because 85% would require too many responses (already at least 20) to get statistically significant results. This does mean our game does not need to be as good to pass this metric, but we plan on mitigating this by continuing to reiterate our game design based on feedback to improve it.

Another requirement change is we loosened our latency requirements. We made this change since we believed our game would still be enjoyable since the initial standards were more for high-end gaming. This gives us more slack in the timings with the Arduino. To mitigate the risks toward the enjoyability of the game, we plan on adding more optimizations to the Arduino code.

We changed the module design from having separate data lines for each module which would also serve as identification to having shared binary identifier lines and shared data lines. This change was made to reduce the number of pins we had on our module. It also gives the Arduino more information about when a module has been inserted.

Schedule has not changed. Pictures are in individual reports.

A was written by: Alan
B was written by: Angela
C was written by: John

Part A: considerations of public health, safety or welfare

While there aren’t too many considerations toward public health that our project is meeting since it isn’t oriented toward that aspect, a portable and easy to set up game can provide a lot of assistance toward the mental health of the users. Games are a common way for people to destress especially those who have more cumbersome work in their lives.

Moreover, our game is a multiplayer arcade-style game, and hence our product provides the additional mental health benefits that come with the company of another person. Especially in an increasingly online world, isolation and its detriments to people’s mental health is becoming more and more of an issue in adults and teens. Having a product to bond with another person while cooperating toward a common goal combats this.

Part B: considerations of social factors

Aquamods is not particularly motivated by social factors. Because it is a multiplayer game that people play together in person, it can be said that there is some social benefit involved. We haven’t identified any significant concerns related to any cultural, social, political, economic groups. Because the controller modules are all controlled using simple interactions, the controllers are accessible for all ages and those with limited motor control.

Part C: considerations of economic factors

It’s important for our game to be affordable since we are trying to replicate a part of the arcade experience. This is a key element of our game — having tactile controls that many at-home video game consoles do not provide. The commute to an arcade plus the costs of the games themselves can be prohibitive. Our game also allows users to play as many rounds as they’d like after one upfront cost, as opposed to the arcade model which requires payment for each round.

Leave a Reply

Your email address will not be published. Required fields are marked *