Category: Team Status Reports

The biggest risk to our project is probably we need to get the game play testable soon so that we can get feedback and iterate upon it. The next playtesting night is this Tuesday 6-8 so we want the game playable by then.

No changes have been made to the overall design.

Photos are in individual status reports. We’ve made some good additions to the game. We also have working prototypes of the controllers.

For the enjoyment of the game requirement, we have made a survey and plan on giving it to playtesters at the hunt playtesting night. We have already met the cost requirement and we have calculated the cost of parts in our design report. We will add timers to our code to detect the more quantitative timing requirements.

Since Alan got the modules 3D printed, it seems most of our stresses are gone now. John is working on the wiring before interim demo. If this does not work, that would, as of now, the most significant risk to our interim demo seeming functional to any staff members. But we are working on it now, so hopefully it should be fine by demo time. The game is on progress, Angela has all the basic enemies finished. We just need to get end-to-end integration tested and ready for presentation.

No real big changes were made, we did end up making the module taller than I believe our design reqs stated. This was mostly for our own ease of assembly when putting electronics inside. I think we can justify this as a limitation of this being not a professional product where we would likely have the tools to assemble this easier.

Schedule is still the same.

Pictures are in individual status reports.

Again, our most significant risk is probably the module design. It’s been making progress, but it’s still behind schedule and Alan has been busy with other classes 🙁 We still have the protoboard demo that John made as a contingency.

We haven’t made any design changes to the system. We discussed how the encoder will be represented in the controller for a bit, but we did not really get around to implementing that yet.

Photos of individual accomplishments on the various aspects of our project can be seen in the individual status reports!

The most significant risk we have identified right now is the design of the modules. We’re a bit late schedule-wise with it, and it is quite essential to the enjoyability and feel of our game. Alan’s been a bit slow with the CAD designing, but we have some models already printed. We are working on getting those finalized quickly, so we will have a prototype for the demo. In the meantime, we are able to model the functionality of the reconfigurable controller from the mock protoboard that john designed. Which I guess can serve as a contingency for our interim demo, but that is very not ideal. We also have some prototype designs for the modules printed out, but they still need refining.

No changes were made to the overall system. We have slightly altered the design of the modules to have a better grip. I guess we also made decisions to have an attachable cap in order to make it easier to iterate on the module design without having to glue things together and then unglue them.

No changes have been made to the schedule.

Photo of newly designed and printed module and holder:

This week we wrote the design report.

We successfully simulated a game controller in Unity using the Arduino. We also received the rest of our electronic components and confirmed that they work as expected. We also made significant progress with game programming.

Design Changes

We have to make a slight design change with regard to pin assignments. Since only digital pins can be used for interrupts, we need an additional digital data pin. This is because we want to be able to use interrupts for reading encoder updates. We were originally planning on using one analog GPIO pin and one digital GPIO pin, and treating the analog pin as digital when we needed two digital pins for the encoder. We will now have two dedicated digital GPIO data pins and one analog data pin. This is not a significant change because we have the available pins that we need and our pogo pins have a spare pin available.

Significant Risks

The only risk we can think of at this time is the latency being higher than expected, but we will test this as soon as possible.

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

Part A: Consideration of Global Factors

In general, the game we are designing is meant to be played at home with your friends physically next to you and hence lives in a very local space. But the general concepts that our project pushes toward have broader themes. In a more global context, our project contributes to the idea of more physical-oriented alternative controllers. Video games are a phenomenon that exist globally but many people are used to the same controller designs. Our project spreads more awareness of the possibility of controllers that can be uniquely created to enhance the experience of a specific game.

Part B: Consideration of cultural factors

Our product has a cultural aspect in encouraging players to play a cooperative game in person. The game is accessible to a wide age range considering that the modules have very simple controls such as buttons and sliders, so that young children and elderly people can both easily play the game.

Part C: Consideration of environmental factors

Our solution uses a microcontroller and the users’ personal computer, which use less energy than a large arcade machine. This efficiency is good for the environment since current power production often uses fossil fuels and other non-renewable resources.

Our design also uses easily repairable, open-sourced design, so users do not need to purchase a complete new set if something breaks. This reduces E-waste.

This week we made progress on implementing game mechanics and created a GitHub for / started experimenting with Arduino code using the joystick library. There have been no significant design changes or schedule updates.

Significant Risks

The documentation of the Arduino joystick library is not quite through enough for us to be able to exactly predict how it will interact with Unity. We will need to do a bit of experimentation and iteration to make sure that the interfacing between the two parts goes smoothly. Now that we have the Arduinos, we have begun experimenting with the joystick library and next week we will try to nail down the integration with Unity.

We’ve set up a Github for the Unity project and begun work on basic game mechanics. We have also done some preliminary research into electronics selection for modules and put in some parts orders.

Significant Risks

The most significant risk we see to our progress at this time is the complexity of the connections between the modules and the game panel. For our game to be enjoyable, it’s critical that switching the modules is fast, seamless, and reliable. This risk is being managed by handling this aspect of the project early on. As a team, we are discussing various ways to make solid electrical connections between the modules and the game panel. We are also looking at different ways to communicate between the modules and the panel. We are leaning toward mostly passive designs to keep the modules simple and minimize latency. A contingency plan we have is to focus on the simpler modules first and make sure that the MVP of our game works with them before moving on to more complex modules.

Significant Changes

We have not made any noteworthy changes to our overall system design but have made some changes to our module electronics. For example, we’ve decided to use an encoder instead of a potentiometer for one of our modules because it allows the users to freely spin the dial/wheel. This was necessary because it more closely aligns with our game design and how we’d like to control the submarine. It also allows the users to switch the module without it maintaining its state, since encoders do not output absolute position but rather direction and velocity. This will be slightly more expensive but still well within our budget so cost is not a significant concern. This is not a significant enough change to update our schedule.